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.
