Handler on Duty: Jesse La Grew
Threat Level: green
Podcast Detail
SANS Stormcast Wednesday, April 22nd, 2026: WAV Malware; GitHub OAUTH Phishing; Perforce Settings
If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9902.mp3
My Next Class
Click HERE to learn more about classes Johannes is teaching for SANS
A .WAV With A Payload
https://isc.sans.edu/diary/A%20.WAV%20With%20A%20Payload/32910
The Phishy GitHub Issue Case
https://blog.atsika.ninja/posts/the-phishy-github-issue-case/
P4WNED: How Insecure Defaults in Perforce Expose Source Code Across the Internet
https://morganrobertson.net/p4wned/
| Application Security: Securing Web Apps, APIs, and Microservices | San Diego | May 11th - May 16th 2026 |
| Network Monitoring and Threat Detection In-Depth | Online | Arabian Standard Time | Jun 20th - Jun 25th 2026 |
| Network Monitoring and Threat Detection In-Depth | Riyadh | Jun 20th - Jun 25th 2026 |
| Application Security: Securing Web Apps, APIs, and Microservices | Washington | Jul 13th - Jul 18th 2026 |
| Application Security: Securing Web Apps, APIs, and Microservices | Online | British Summer Time | Jul 27th - Aug 1st 2026 |
| Application Security: Securing Web Apps, APIs, and Microservices | Las Vegas | Sep 21st - Sep 26th 2026 |
Podcast Transcript
Hello and welcome to the Wednesday, April 22, 2026 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ullrich, recording today from Amsterdam, Netherlands. And this episode is brought to you by the SANS.edu graduate certificate program in Purple Team Operations. Didier 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 Didier analyzed was created differently. 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. This is fairly simple and it works because particularly in 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 audio file that Didier 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, Didier has some Python scripts here to help you with this, including brute forcing the one byte XOR key using the known 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 at Sika, 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 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 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 it 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 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 the user. Even a little bit more specific user like a developer, it's often hard to tell what privileges you're actually assigning and who created the application and what application 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 software. 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. Bye. Bye. Bye. Bye. Bye. Bye. Thank you.





