SANS Stormcast Wednesday, April 22nd, 2026: WAV Malware; GitHub OAUTH Phishing; Perforce Settings - SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)

Summary5 min read

Episode Overview

Podcast: SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
Host: Johannes B. Ullrich
Date: April 22, 2026
Main Theme:
A concise, expert breakdown of current cybersecurity threats and issues for developers and organizations, focusing on novel malware delivery via WAV audio files, emerging OAuth phishing techniques on GitHub, and newly-highlighted risky defaults in the Perforce version control system.

Key Discussion Points & Insights

1. Malware Delivered via WAV Audio Files

Malware Behavior
- Research by Didier Stevens (DDE) examined a malicious “audio” file delivered as a .wav.
- Contrary to classic steganography—where messages are hidden by subtly modifying existing, genuine audio—attackers used the audio data region to directly embed a malware payload:
  - The malware is an executable, first Base64 encoded, then XOR-encrypted.
  - The encrypted payload is inserted as the actual audio data in the WAV file.
Detection Characteristics
- The WAV file plays as “just noise”—there’s no attempt to make it seem like a natural recording.
- The simplicity of this approach means that while the audio doesn’t sound realistic, it can still bypass cursory reviews if checked superficially.
Extraction/Analysis
- On the target machine, malware reverses the XOR encryption, decodes Base64, and retrieves the executable payload for execution.
- Didier provides Python scripts to brute-force the XOR key—using the PE header in the payload as a known plaintext—and extract the executable for further analysis.
- Quoting host Johannes Ullrich:
  
  "The attacker here used a piece of malware, an executable and base64 encoded. It then used a simple XOR cipher in order to encrypt it and essentially used the resulting data as the audio data in a WAV file." ([01:00])
  
  "When you're listening to this particular audio file that DDE looked at, all you sort of hear is essentially noise…but probably good enough in order to fool some people into believing that this is actually an audio file." ([01:35])
- Full process and analysis: see Didier’s diary entry for April 22, 2026.

2. GitHub OAuth Phishing via Notifications

Emerging Attack Vector
- There are fresh concerns about how GitHub notifications can be weaponized to phish OAuth tokens from developers.
- Attackers create both a malicious repository and a GitHub application to request OAuth access.
- Attack Process:
  - Attacker mentions the target in a GitHub issue, triggering an immediate notification.
  - Due to a short delay (“a couple seconds”) before GitHub finalizes the notification content, the attacker can quickly modify the issue post-notification, tailoring it (e.g., to mimic a breach alert).
  - When the victim clicks from the notification, it leads to a legitimate GitHub page—not a spoofed phishing site.
  - The user is prompted to authorize the attacker's app via OAuth, often without realizing exactly what privileges they are granting or who created the app.
Technical & Usability Issues
- The time window for altering notifications is a subtle, potent “time of check, time of use” bug.
- Broader concern: OAuth is secure at the protocol level, but real-world user workflows often obscure which privileges are requested and by whom.
- Even technically skilled users may be unsure what access they're authorizing.
- Quoting Johannes Ullrich:
  
  "There's actually a delay in the notification being created and GitHub actually retrieving the necessary data from the actual issue…and it's long enough for the attacker to then modify the issue and make the issue appear more genuine." ([02:21])
  
  "This is not phishing in a sense where an attacker has to set up a fake GitHub clone or anything. Instead, the link in that GitHub notification will entice the victim to basically connect to the attacker's application, give the attacker OAuth privileges." ([03:16])
  
  "OAuth itself, cryptographically…is a very solid protocol, but it suffers often from usability issues where it's not really all that clear to…the user…what privileges you're actually assigning and who created the application." ([04:01])
Reference:
- Blog post by Morgan Robertson explores this vector and its implications.

3. Perforce Default Configuration Security (Supply Chain Risks)

Supply Chain Risks for Developers
- Robertson’s blog post points to insecure default configurations in Perforce, a commercial version control system.
- Concerns include:
  - Default accounts with excessive privileges.
  - Weak controls on reviewing users, synchronizing repositories, or resetting passwords.
  - Many issues are configuration-based, fixable with proper settings, not requiring code changes.
Impact
- Especially affects current Perforce users, since insecure defaults persist unless explicitly updated.
- Newest release fixes these defaults, but any organization using earlier versions should review and tighten configs accordingly.
Quoting Johannes Ullrich:

"Some of these default configurations are fairly classic, where it basically does establish some default accounts. It also makes it easy to review users on the system or do things like, for example, synchronize repositories…without sufficient checks or reset passwords." ([05:07])

"The latest version does have these issues fixed and does have more sensible defaults. However, if you are already using Perforce, then please take a look at the blog post and make sure that your particular install does use the correct configuration options." ([05:50])
Recommendation
- Review blog post and audit Perforce installations for risky defaults.

Notable Quotes & Memorable Moments

On WAV Malware Simplicity:

"When you're listening to this particular audio file, all you hear is essentially noise…probably good enough to fool some people into believing that this is actually an audio file." (Johannes Ullrich, [01:35])
On GitHub OAuth Phishing:

"This is not phishing where an attacker has to set up a fake GitHub clone…instead, the link in that GitHub notification will entice the victim to basically connect to the attacker's application, give the attacker OAuth privileges…" (Johannes Ullrich, [03:16])
On OAuth Usability:

"Even a little bit more sophisticated user, like a developer, it's often hard to tell what privileges you're actually assigning and who created the application…" (Johannes Ullrich, [04:18])
On the Importance of Reviewing Defaults:

"If you are already using Perforce, then please take a look at the blog post and make sure that your particular install does use the correct configuration options." (Johannes Ullrich, [05:50])

Timestamps for Key Segments

[00:04] — Introduction and episode overview
[00:35] — Analysis of WAV file–based malware and extraction methods
[02:14] — GitHub OAuth phishing via notification manipulation
[04:35] — Discussion of OAuth usability and risks
[05:07] — Insecure defaults in Perforce and supply chain implications
[05:50] — Remediation advice for Perforce users

Takeaways

Attackers use creative approaches—like embedding malware in WAV files—that exploit overlooked file formats.
The combination of legitimate platforms (GitHub), subtle logic issues (notification delay), and usability flaws creates new phishing risks, even for sophisticated users.
Default, insecure configurations in developer tools (such as Perforce) can open serious security holes, emphasizing the importance of regular audits and staying up to date.

Recommendation to listeners:
Review Didier Steven’s analysis for malware detection strategies, be vigilant about OAuth authorization flows (especially on GitHub), and audit your supply chain tooling—like Perforce—to ensure secure configurations.

Loading summary

Transcript1 lines

[00:05]
A
Hello and welcome to the Wednesday, April 22, 2026 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ulrich, recording today from Amsterdam, Netherlands, and this episode is brought to you by the Sans Edu credited certificate program in Purple Team Operations. The VA today wrote up an interesting piece of malware that arrived as an audio file. In this particular case, we didn't have sort of classic steganography. Classic steganography usually takes an existing audio file that actually appears and actually is some music or some other recording, and then it slightly modulates the existing audio file in order to encode a message. This particular audio file that DDE analyzed was created differently. The attacker here used a piece of malware, AN executable and base 64 encoded. It then used a simple XOR cipher in order to encrypt it and essentially used the resulting data as the audio data in a WAV file. This is fairly simple and it works because in particular a WAV file, essentially any byte value will be represented by volume and with that as audio. Now, when you're listening to this particular, particular audio file that the DDA looked at, all you sort of hear essentially noise. So there isn't like, you know, any melody or anything like that, but probably good enough in order to fool some people into believing that this is actually an audio file. And then of course, the malware on the receiving system is reversing the encryption and encoding and extracting the actual executable. Of course, Didi has some Python scripts here to help you with this, including brute forcing the 1 byte XOR key using the non plain text, which in this case is the PE header of the file, and then essentially just extracting the executable for further analysis. If you want to learn more about this, then refer to Didier's diary from today, which walks you through this step by step process. And of course, supply chain issues are still in everybody's mind, or again in everybody's mind. And with that, well, attacks against developers. One vector how attacks against developers were often perpetrated is GitHub and in particular GitHub notifications. There's a new blog post now by, if I pronounce this correctly, who writes about how weaknesses in GitHub notifications can make it easier for attackers to actually fool developers and then obtain oauth tokens on the developer's behalf. The way this particular attack works is that the attacker will initially set up a GitHub repo repository. The attacker will then also set up a GitHub application and GitHub applications can use OAuth in order to authenticate users to the application and also use some of the privileges assigned to the user. The next step then is that the attacker will create an issue and mention the victim inside the issue. Now, this will trigger a notification for the victim, but that's where sort of a little twist comes in. There's actually a delay in the notification being created and GitHub actually retrieving the necessary data from the actual issue. And that delay is like a couple seconds, and it's long enough for the attacker to actually then modify the issue and make the issue appear more genuine and, well, something that the victim is more likely going to fall to. In this particular case, they make the issue kind of look like a notification of a breach of the developer's repository. When the developer then clicks on the link and tries to check what the notification is all about, they will be sent to a legitimate GitHub page. So this is not phishing in a sense where an attacker has to set up a fake GitHub clone or anything like this instead. The link then in that GitHub notification will entice the victim to basically connect to the attacker's application, give the attacker OAuth privileges, which can then be abused by the attacker. I think in addition, sort of to that little time of check, time of use issue here, where notifications can be modified after they're being triggered. The other problem here is of a classic OAuth issue. OAuth itself, cryptographically, technically a very solid protocol, suffers often from usability issues where it's not really all that clear to, to the user. Even a little bit more sophisticated user, like a developer, it's often hard to tell what privileges you're actually assigning and who created the application and, well, what applications actually is that you are providing here with privileges. And I think that really contributes almost more here to the problem than the fact that you can tailor these notifications a little bit better than you could without that time of check, time of use problem. And the blog post by Morgan Robertson does reveal some insecure default configuration options that you will find in Perforce. Perforce is software that's used for version control, so essentially by software developers. Again, we do have attacks here possibly against software developers. And supply chain Perforce sort of follows the freemium model, where some of the functionality you get in a free version, but fundamentally it is commercial software. Now, some of these default configurations are fairly classic where it basically does establish some default accounts. It also makes it easy to review users on the system or do things like, for example, synchronize repositories and such without sufficient checks or reset passwords. All of this is really just a configuration option, so it's not that they had to like rewrite the software, sort of fix it. The latest version does have these issues fixed and does have more sensible defaults. However, if you are already using Perforce, then please take a look at the blog post and make sure that your particular install does use the correct configuration options. Well, and this is it for today. So thanks for listening, thanks for liking, thanks for subscribing and talk to you again tomorrow. Bye.