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

Podcast Logo
WAV Malware; GitHub OAUTH Phishing; Perforce Settings
00:00

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 MicroservicesSan DiegoMay 11th - May 16th 2026
Network Monitoring and Threat Detection In-DepthOnline | Arabian Standard TimeJun 20th - Jun 25th 2026
Network Monitoring and Threat Detection In-DepthRiyadhJun 20th - Jun 25th 2026
Application Security: Securing Web Apps, APIs, and MicroservicesWashingtonJul 13th - Jul 18th 2026
Application Security: Securing Web Apps, APIs, and MicroservicesOnline | British Summer TimeJul 27th - Aug 1st 2026
Application Security: Securing Web Apps, APIs, and MicroservicesLas VegasSep 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.