Podcast Detail

SANS Stormcast Tuesday, June 9th, 2026: Azure Repos Infected; Checkpoint VPN 0-Day; Verizon VoLTE missing IPSec integrity prot.

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/9964.mp3

Podcast Logo
Azure Repos Infected; Checkpoint VPN 0-Day; Verizon VoLTE missing IPSec integrity prot.
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack
https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-again-azure-functions-action-and-72-other-repositories-disabled-after-supply-chain-attack-targeting-ai-coding-agents

Active Exploitation of Check Point VPN Authentication Bypass (CVE-2026-50751)
https://blog.checkpoint.com/security/check-point-releases-important-hotfix-for-vulnerabilities-in-deprecated-ikev1-vpn-protocol/

Missing IPsec Integrity Protection for IMS SIP Signaling in Verizon VoLTE Deployments
https://kb.cert.org/vuls/id/615987

My Upcoming Classes
https://www.sans.org/profiles/dr-johannes-ullrich

Podcast Transcript

 Hello and welcome to the Tuesday June 9th, 2026 edition
 of the SANS Internet Storm Center's Stormcast. My name is
 Johannes Ullrich, recorded today from Jacksonville,
 Florida. This episode is brought to you by the SANS.edu
 undergraduate certificate program in cybersecurity
 fundamentals. For a couple of weeks now, I keep saying that
 you should assume compromise when it comes to your supply
 chain. The latest example here is the compromise of several
 Azure related Microsoft GitHub repositories. Don't know what
 you want to call this particular warm. It's all the
 same kind of over again after, of course, some of these chat
 -tol-o-warms and such were made public. We've seen many,
 many variants spring up. Step Security has a good write-up
 on what they're calling Miasma warm and that's the one that
 hit these Microsoft repositories. It hit a total
 of 72 repositories. But remember, they're not just
 stealing credentials. They're also then actively attempting
 to spread into anybody using code from these affected
 repositories. Microsoft acted quite quickly here and
 disabled the repositories. They didn't really even know
 why they disabled it. So there was a lot of confusion among
 developers who depended on some of the GitHub actions
 here, which actually was part of the problems. And as a
 result, their CI CD pipelines failed. Good thing if your CI
 CD pipeline fails in this case, because that means,
 well, you were not infected by this particular warm. So,
 yeah, don't complain too much about Microsoft disabling it.
 It was the right quick response in order to prevent
 further harm from being done. Of course, they probably
 should have done a little bit more ahead of time with
 hardened configurations and the like. But read the write
 -up from Step Security if you're in that space, because
 they have a lot of good things here about how all of this
 happened. There's actually a couple different blogs that
 they wrote about this particular event. The one I'll
 link to is the one that specifically talks to the
 Microsoft repositories. And Checkpoint, an Uprise VPN
 vendor I haven't actually talked much about lately, and
 that's a good thing for Checkpoint. But, well, .com is
 over now and Checkpoint this weekend did release a patch
 for its Checkpoint VPN. This patch is active or this
 vulnerability is actively being exploited right now. You
 must patch this as fast as possible. It's being exploited
 by ransomware. So it's not just the selected targets or
 so that are being affected here like in some state
 -sponsored attacks. Anybody who is running Checkpoint VPN
 must patch quickly. The problem here is that
 certificates are not validated correctly by Checkpoint VPN.
 So an attacker is able to basically create a fake
 certificate and log in without further credentials. So
 definitely make sure you patch quickly. And CertCC came out
 with an interesting note last week that Verizon apparently
 failed to implement some basic IPsec protections for its
 voice over LTE traffic. Voice over LTE, well, it's really
 voice over IP. So it uses protocols like SIP, which by
 themselves do not provide any confidentiality or integrity.
 So you must add an additional layer here. Usually IPsec, at
 least that's the recommended layer by the standard bodies
 for voice over LTE. Operating systems on modern phones also
 support that via carrier profiles. But, well, Verizon
 apparently didn't properly deploy it. And as a result,
 any signaling across Verizon's network for voice over LTE was
 vulnerable to interception or at least to be tampered with.
 Well, nothing really you can do other than be aware that
 this stuff happens with carriers. So best practice
 anything leaving your device should be considered on a
 hostile network. And we all have heard in the past about
 Volt, Typhoon and such compromising carrier networks.
 So make sure you add your own integrity protection and
 encryption for any links traversing a public network.
 Well, that's it for today. Just a quick note about our
 honeypots. I'm hopefully in the final stages has been a
 long path for a major upgrade to our honeypot software. One
 of the big additions will be Velociraptor, which will allow
 us to sort of more dynamically retrieve logs from the
 honeypots. If you want to do a little help with a little sort
 of preview for us here, I will post to the Slack a couple
 links in the next couple days. You can sort of manually
 deploy this on your honeypot if you are interested. That's
 it. Well, that's it for today. Thanks for listening and talk
 to you again tomorrow. Bye. Bye. Bye. Bye. Bye. Bye.