SANS Stormcast Wednesday, September 17th, 2025: Phishing Resistants; More npm Attacks; ChatGPT MCP abuse

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

previous

Phishing Resistants; More npm Attacks; ChatGPT MCP abuse

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 Wednesday, September 17th,
 2025 edition of the SANS Internet Storm Center's
 Stormcast. My name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Graduate Certificate Program in
 Cybersecurity Engineering. Well, we have today a little
 bit of different diary, not of our usual deep technical
 diary, but something a little bit lighter from a technical
 point of view, but still very, very important. And that's the
 idea of phishing resistant authentication. A lot of the
 phishing advice given these days doesn't really sort of
 consider that really well. And authentication is very focused
 on multi-factor authentication, which is a
 good thing, but it does often not protect against phishing.
 So the idea of phishing resistant authentication is
 that the user is no longer in charge what credentials to
 provide to a particular website. Whenever you have any
 scheme where the user decides what credentials to provide,
 the user could be fooled into providing those credentials to
 the wrong websites. And then you have tools like evilginx
 and such that allow these machine in the middle
 attacks that will take those credentials, retrieve a
 session ID from the application the user is
 attempting to connect to. And with that, the attacker is
 authenticated. So that has to be avoided. You must remove
 the ability from the user to provide the credentials to the
 wrong website. An initial start, and that's probably the
 simplest way to get started, but far from perfect, is a
 password manager. Password managers tend to be pretty
 good in setting up the right credentials for the right
 websites. There have been vulnerabilities in the past,
 the password managers, but for the most part, they get that
 right. They get it better, typically, than a user would.
 The ultimate fix is really something like certificates,
 like pass keys, FIDO 2 authentication, where you have
 technical means that basically prevent you from sending the
 wrong credentials to the wrong website, because the user
 doesn't really know what the credentials are. And the
 device, like your authenticator, your password
 manager, again, if the pass key is stored with the
 password manager, decides what credentials to send. And with
 that, you are avoiding a lot of these phishing issues, or
 really all phishing issues. So look into phishing-resistant
 authentication. NIST, in a recent update to some of their
 standards, has also emphasized this. And just, you know,
 let's get another argument for phishing-resistant
 authentication, how difficult it can be to recognize
 phishing. I looked at some of the recently registered
 domains for npm.js. That's basically what happened here
 in the latest attack against npm. So normally, it's npm.js
 .com. Well, in the recent attack, npm.js.help was used.
 But there's also an npm.js.cam that was recently registered.
 And that looks very much like .com. So very easy to overlook
 that you're actually on the wrong domain here. Actually,
 I'm a little bit surprised that attackers haven't used
 the .cam top-level domain more for phishing. And I looked at
 some of the recent domains, not just npm, but other banks
 and such. There are a couple, but seems to be a little bit
 less than I would expect. So not to give any attackers here
 any tips. Then talking about these npm attacks, well, it
 turns out the Singularity/nx attackers are back. These were
 the attackers, or the attacker, who originally
 caused the compromise of about 40 packages. The new wave of
 compromises is similar, but different to the prior
 attacks. Now, the prior attacks were very much focused
 on cryptocurrency secrets. And then it was a little bit, they
 were dismissed as being not very successful in actually
 achieving their goal. And not really stealing a lot of
 cryptocurrency. This new attack uses a little bit more
 of a worm-like payload as they're compromising
 vulnerable repositories. And just sort of a quick overview
 here from aikido.dev, what this particular worm does. It
 first basically harvests secrets. And they focus on a
 lot of these sort of continuous integration
 environments and secrets there, like process.env is
 particularly mentioned here. Cloud metadata, that's
 potentially accessible. Then they're creating a GitHub
 repo. That's now named differently. That's being used
 to exfiltrate those secrets. And they're also creating
 GitHub actions in order to then, again, get access to
 secrets. The propagate part here is the real important
 one. But they are now trying to find additional
 repositories that they may have access to as any valid
 npm tokens. And with that, basically, they try to infect
 additional libraries, additional accounts that the
 user may have access to. All of the repositories are also
 then made public. This may be sort of a little bit of a
 tricky way of just exfiltrating data. Instead of
 exfiltrating the data, they make it public. And now it may
 get a little bit more difficult to figure out who's
 actually receiving the data. Because, of course, once these
 repositories are public, anybody can access them. And
 there will be a lot more noise kind of covering up the actual
 attacker. So, really interesting development here.
 It's not clear if this second wave is also started with
 phishing. It's likely that it did. But I haven't seen any
 confirmation about that yet. The malware is substantially
 different. Which, of course, could indicate a new wave. And
 maybe a little bit different initial entrance vector. Maybe
 still using some of the repositories that were
 initially compromised by the first wave. And some people
 also noted that this new wave did affect some CrowdStrike
 repositories. Now, these do not affect the actual product.
 They're Falcon sensor. But if people are building software
 using CrowdStrike, they may have used some of these
 packages. However, again, they were only vulnerable for a
 relatively short amount of time. And if you use them
 during that amount of time, well, you may end up with the
 backdoor version. Then in vulnerabilities, we have an
 interesting post to LinkedIn by Ito Miyamura about how the
 recently added agentic capabilities, where basically
 added the model context protocol to OpenAI, can be
 abused. One obvious use of these protocols is to automate
 workflows. For example, if you're receiving emails, if
 you are receiving calendar invites or such to
 automatically respond to them or handle them. Well, the
 problem with all of these large language model
 interactions is there is no clear distinction between user
 data and code. So any calendar invite that you may receive
 may actually include a prompt that will then basically trick
 OpenAI or chat GPT here to act on the attacker's behalf. And
 then use the same MCP interconnect to then, for
 example, connect to your email client or whatever you exposed
 to this protocol. Interesting warning here. Nothing
 fundamentally new. We have seen this with pretty much any
 implementation of these type of systems. So be very careful
 what you are exposing. Well, and this is it for today. So
 thanks again for listening and thanks for liking and
 subscribing to this podcast. And thanks also for any tips
 or such about any content that I should cover or not cover.
 So with that, thanks and talk to you again tomorrow. Bye.