Podcast Detail

SANS Stormcast Thursday, April 16th, 2026: AI Credential Scans; Microsoft Update Issues; RDP Warnings; GitHub Action Vulns;

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

Podcast Logo
AI Credential Scans; Microsoft Update Issues; RDP Warnings; GitHub Action Vulns;
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS
Network Monitoring and Threat Detection In-DepthAmsterdamApr 20th - Apr 25th 2026
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 Thursday, April 16, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Stockheim, Germany. This episode is brought to you by
 the SANS.edu graduate Certificate Program in Purple
 Team Operations. Configuration files containing secrets are a
 common target for attackers today. Typically, attackers
 are scanning web servers for commonly used configuration
 files like .env. Guy noted in his honeypot logs that
 attackers are now more and more scanning for files
 associated with AI tools. For example, attackers are
 scanning for files associated with OpenClaw, Claude and
 OpenAI. Just like any configuration files, these
 files should not be kept in your document root. Attackers
 will usually use the credentials contained in these
 files to steal tokens, which can lead to rather large
 invoices from these AI vendors. So make sure that
 first of all, the secrets are properly protected. But in
 addition, we'll set up the right billing alerts and
 limits for your particular AI tools. So that way, you're at
 least being alerted and hopefully are limiting the
 damage that's done in case some of these secrets will
 eventually lead. And then we got some postscripts to
 yesterday's Microsoft Patch Tuesday. Microsoft states that
 some devices with an unrecommended BitLocker Group
 Policy Configuration might require to enter their
 BitLocker Recovery Key on the first restart after installing
 this update. So what Microsoft is saying here is that you may
 have to enter your BitLocker Key, which of course a lot of
 people don't necessarily have to do.
 Microsoft is also offering some advice on how to adjust
 your configuration prior to the update to avoid this
 problem. This issue may be related to a patch released on
 Tuesday that specifically addresses a BitLocker related
 problem. Microsoft also released a known issue
 rollback. These are essentially little scripts
 that make it easy to apply their recommended solution to
 this problem. So again, it is maybe a little bit easier than
 following the steps that are outlined to revert the
 configuration before you are applying the update. The
 Tuesday Microsoft updates also included a patch that I
 pointed out for the RDP client. One thing I mentioned
 there is that it's certainly possible for a victim to
 connect to an RDP server via a simple RDP URL that's included
 in an email or a web page. Another option is an RDP file.
 These files may include additional configuration
 options. For example, the RDP file may instruct the RDP
 client to share certain files or the clipboard with the
 server. Malicious users have abused this feature. Once the
 update is installed, Windows will display a warning after
 the user opens an RDP file for the first time. This warning
 will just explain to the user the danger of RDP files in
 general. But then for each new connection, there will be a
 dialogue explaining first of all, is the RDP file digitally
 signed? That is an option or is it not signed? And
 secondly, what resources the RDP file instructs the client
 to share with the server? So to give the user a little bit
 more insight into what is happening when they're
 actually opening this RDP file. And security researcher
 Aonan Guan found a new type of prompt injection vulnerability
 in various GitHub actions distributed by OpenAI vendors
 like Anthropic, Google and Microsoft. The problem isn't
 so much the prompt injection in this case, which leads to
 credential thefts are certainly serious, but prompt
 injections, well, themselves aren't really all that new.
 All affected vendors also have updated affected actions and
 released patched versions. What Aonan Guan however noted
 is that none of these vendors has assigned a CVE number to
 the floor or highlighted the security issue that is being
 addressed in this update. In particular, after recent
 supply chain issues, of course, around AI-related
 libraries, many developers have become more cautious
 about updates and have carefully pinned versions and
 Git hashes preventing automated updates from taking
 place. And this is even more important for vendors now to
 actually disclose any patched vulnerabilities. The
 vulnerability itself is not a big surprise. Again, prompt
 injection sort of comes with the territory here to some
 extent. But the issue here is more that vendors didn't
 disclose the vulnerability. Other vendors may be affected
 as well. These are just the vendors that Aonan Guan has
 tested in this particular work. And on Friday, I talked
 about how a number of vendors who released open source
 security-relevant tools like WireGuard and other VPN
 service and the like have had issues with Microsoft
 suspending their developer accounts. After some forth and
 back, in part via social media, it turned out that
 affected developers either did misrequest to update their
 information with Microsoft or in some cases Microsoft may
 have, well, not properly processed whatever information
 was submitted. This was in part required because these
 security-relevant tools will need some of these newer
 kernel access methods and such. So that requires
 additional verification as to who actually publishes the
 software. Not having, of course, any kind of easy-to
 -reach support or so hasn't helped with the issue. The
 problem appears now to be resolved. Microsoft and
 WireGuard, actually, WireGuard was one of the affected
 developers, did release a new version and has had it now
 properly signed by Microsoft. So all their drivers should be
 working going forward. Well, and that's it for today.
 Thanks for listening. Thanks for liking. Thanks for
 subscribing. Thanks for recommending this podcast to
 others. And talk to you again tomorrow. Bye.
 Bye. Bye. Bye. Thank you.