SANS Stormcast Friday, July 24th, 2026: OpenAI vs. Huggingface; Zimbra Exploited; Notepad++ Abuse; Browser as C2

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

previous

OpenAI vs. Huggingface; Zimbra Exploited; Notepad++ Abuse; Browser as C2

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Friday, July 24th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. This episode is brought to you by
 the SANS.edu Master's Degree Program in Information
 Security Engineering. The OpenAI versus Hugging Face
 incident does still dominate the news and Renato today
 wrote up as his diary for the day a summary of it with some
 lessons learned that I think are quite valuable here. So
 first of all, that if you have some kind of sandbox or so for
 your agent, it's typically not providing the security
 isolation that you expect. It's for many agents really
 just more of a guideline. Secondly, well, there's this
 assimility problem around guardrails that Hugging Face
 ran into where their models actually refused to analyze
 some of the evidence or respond because of guardrails
 they ran into. So that's an interesting, I think, lesson
 to take away from this. And then, of course, well, how did
 it actually get in? What were the vulnerabilities? And here,
 non-human identities, API keys and stuff like this still sort
 of played a major role here. So that's something that, of
 course, a lot of human -initiated exploits and
 intrusions are leveraging as well. So definitely something
 that you probably want to restrict and control. A couple
 times in the past, I've mentioned cross-site scripting
 vulnerabilities in Zimbra. So just fitting that, Sisa, in
 conjunction with other cybersecurity agencies, has
 published an advisory how a Russian state-sponsored actor
 is using cross-site scripting vulnerabilities to attack
 Zimbra users. So Zimbra, like all webmail systems, is
 struggling with cross-site scripting. You have to
 essentially display HTML email with cascading style sheets
 inside the user's browser and, of course, keep it properly
 separated from the rest of the page. There are some tricks
 like iframes and such that can help, but ultimately this has
 been a very difficult problem. And this is one example how
 these kind vulnerabilities are being attacked. In this case,
 it was the cascading style sheet that triggered the cross
 -site scripting vulnerability. And the attacker used it to
 display a username and password dialogue inside the
 webmail's user interface. So there was really no good way
 for the user to distinguish it from the normal username and
 password dialogue. Once the user entered the username and
 password, then, of course, the credentials were sent to the
 attacker. They also took a second factor if that was
 used. So again, remember, not all second factor
 authentication is phishing resistant. It's essentially
 kind of phishing what's happening here, even though it
 happens inside the page. Something like pass keys or
 some other 502 authentication would not be vulnerable to
 this particular attack. I have no idea if Zimbra supports it.
 Haven't really used Zimbra myself in a while. But anyway,
 so real good example of how these type of attacks are
 being exploited, even if you're up to date in your
 patches. Probably a good read if you're using Zimbra or a
 similar self-hosted webmail system because, well, like I
 said, they all tend to have very similar vulnerabilities
 like this. And we got a blog post by the Ukrainian cert
 with details regarding, well, other probably Russian
 attacks, at least target attacks against Ukraine that
 take advantage of Notepad++. Now, in this case, there's
 actually not a vulnerability being used, even though that's
 a little bit disputed here. The problem is that an
 attacker essentially sending a phishing email, tricking a
 user into expanding a malicious zip file, and then
 placing a DLL inside the extension folder for
 Notepad++. While this DLL essentially replicates a
 normal extension, it does include additional malicious
 functionality. There is a dispute whether or not a user
 should be able to replace a DLL like this. However, this
 is like how these extensions are installed in Notepad++. So
 I kind of agree here with Notepad++ that this is not
 really a vulnerability. It's really just how the product is
 supposed to work. It's not the user actually willingly
 installing a malicious extension. Like that's what we
 usually had in other products like Visual Studio Code and
 such. Not sure if that's happening with Notepad++ here
 as well. But in this case, no, the user really just unzips
 the file and the file opens and looks pretty normal, but
 has the side mission here of actually replacing and
 injecting that DLL. Well, earlier this week, I talked
 about how the calendar tool in Office 365 can be abused as a
 cover channel. Well, there is no shortage in cover channels.
 The latest here from Cisco is msaRAT. This particular tool
 is actually based in Rust, so I guess it's more secure, but
 it also uses the browser in order to connect to the
 malicious site. So the command control channel uses Chrome's
 DevTools protocol. It's an API that developer tools can hook
 into to basically send requests and receive responses
 via Google Chrome. That, of course, makes it a little bit
 more difficult to identify this traffic because when
 you're looking at the processes on your system,
 well, the traffic originates from Chrome. There's a lot of
 weird traffic that goes from and to browsers, so it's easy
 to kind of discard this as yet another odd kind of browser
 behavior and not actually follow through with it and
 look at the source that it's actually initiated by the
 malware. Well, and this is it for today. So thanks for
 listening. Thanks for liking, recommending, and for
 subscribing to this podcast, and talk to you again on
 Monday. Bye.