Hello and welcome to the Friday October 10th, 2025
edition of the SANS Internet Stormcenter's Stormcast. My name
is Johannes Ullrich, recording today from Denver, Colorado.
This episode is brought to you by the SANS.edu Graduate
Certificate Program in Purple Team Operations. And in
diaries, today we do have another diary by one of our
undergraduate interns. This time it's Jin Quan Low, who
wrote about a redtail infection. Redtail is a
cryptojacker, so essentially infecting your system in order
to mine cryptocurrency, in this case typically Monero.
Now, what I like about this particular write-up is it
doesn't just focus on exactly what hash, for example, was
used or what IP address the attack came from. Quite often
defenders are a little bit overly concerned with these
indicators of compromise. What's really more important
to inform your defense is the TTPs that are being used by a
particular attacker in order to identify certain weaknesses
in your systems that you need to defend. In this example,
for example, it's things like weak passwords or, for
example, the modification of the .ssh authorized keys file
in order to gain persistent access to the system. In
particular, the later one is one of those things that's
often not done very well. So you want to protect that
authorized keys file, maybe make sure that it's only
writable by the root user, or you deploy them centrally into
a location other than the user's home directory, which,
of course, also then makes it easier to detect any
unauthorized modifications to this file. So overall, a nice
approach here to look at a honeypot detect from this lens
based on the miter attack matrix and not just looking at
these individual very kind of ephemeral indicators of
compromise. Well, remember a week or two ago, I talked
about the breach of the MySonicWall service. At the
time, SonicWall published a blog post stating that a small
number, I think they mentioned three or five percent of
customers who used MySonicWall to back up their
configuration, had their configuration stolen from the
MySonicWall cloud service. And they kind of blamed it, well,
as so often on the user. Apparently, those users had
weak passwords. At least, that's what was the suggestion
of the blog post as they attributed the incident to
password brute forcing. Now, yesterday, SonicWall did
change their story. All configurations backed up to
MySonicWall were compromised. So all users either had bad
passwords or something else may happen. Well, apparently,
it wasn't the user's fault. It was SonicWall's fault. They
also didn't initially scope the incident correctly and as
a result missed the fact that all configurations backed up
to MySonicWall were compromised. They still take a
little bit, well, security, I guess, from the fact that the
passwords were hashed. But they were hashed in the
firewall before they were uploaded to MySonicWall. Well,
all other parts of the configuration files were
stored in the clear in SonicWall's cloud service.
Cleaning up after this is, of course, the user's problem.
You're supposed to change all credentials, even the ones
that were hashed because, of course, once an attacker has a
hashed credential, they're always able to brute force it.
It's really just a matter of time. And I'm not sure exactly
what hashing algorithms are in play here and how long it
would take an attacker to crack a specific credential
that they found in these configurations. And, of
course, in addition to the credentials, there's a lot of
other network details in those configurations that have now
also leaked. And CrowdStrike did today release patches for
two vulnerabilities that affect the Falcon Windows
client. Actually, I should call them issues because in
their advisory, Cloudflare says these are issues and
logic errors. They do avoid the word vulnerabilities
because that probably sounds worse for a company that makes
a security product. Both of these vulnerabilities do allow
a user who is already able to execute code on these systems
to delete arbitrary files. It's really more sort of a
Falcon sensor bypass vulnerability. Well, and then
we have news about Ivanti, but not from Ivanti. The news
comes from the Seride Initiative. The Seride
Initiative today released 13 advisories affecting
vulnerabilities in Ivanti for which there is no patch
available yet. The Seride Initiative usually waits a
certain amount of time before they're doing so. Now, Ivanti
is aware of these vulnerabilities. For some of
them, you will get a patch in November. For others, you will
have to wait till March next year to get an update. These
vulnerabilities are remote code execution
vulnerabilities, SQL injection vulnerabilities, and other
similar vulnerabilities that we have in the past seen
heavily exploited against Ivanti products, in particular
by ransomware gangs. So, until March, good luck, and hope
your Ivanti instance will survive. But since it's
Friday, I want to close on a positive note, and with that,
we do have some research work from one of our sans.edu
master's degree students. Michael, could you introduce
yourself, please? Hi. Yeah. Thanks for having me. My name
is Michael Sampson. I just recently graduated from the
sans master's program, and I've been in the information
security space for 12-plus years now, doing everything
from endpoint security work in the beginning to more
application security, offensive security work later
on, and now kind of use the offensive security skill sets
to help with defensive.
And, yeah, you'll see the offensive security mindset in
the research. Yeah. So, offense informs defense, as we
always say. But your paper hit on a topic that actually is so
timely. We had a number of issues with that recently. Can
you explain a little bit what the paper was about? Yeah. So,
the paper was about identifying the attack surface
behind AI agents. So, the initial generative AI
solutions that were out there, such as early days of ChatGPT,
they were fairly simple AI chatbots. But today, now you
have AI agents that have access to various tools, and
we're also leading to a world where you have interconnected
AI agents, where you can have one AI agent calling another
AI agent in the background to return your completion. And
so, there's a critical mesh of attack surface hiding behind
an AI agent. So, it's important to be able to map
that. And so, that was what the research was around, being
able to start that discovery process. So, we're talking
agents. Is this MCP? And so, that protocol that's being
used here to connect different AI pieces? Yeah. So, MCP is
the primary protocol being used now to expose tools to AI
agents. But the way that I conducted the attack surface
enumeration for this research was protocol agnostic. So, you
could have tools exposed to an AI agent using a non
-standardized method or protocol. And the idea is to
still be able to detect that attack surface. So, the
protocol is not a vulnerability. It's how you
use that particular protocol. Is that sort of it? Like with
HTTP, it's not HTTP. The problem may contribute, but
the problem is the vulnerable website. Is that sort of the
idea here? Exactly. You know, one of the common problems
you'll likely see with tools exposed through an MCP server
is just inadequate authorization checks. For
example, when performing calls to various tools, which should
be under the calling user's identity. But in a lot of
cases, you may see those calls being conducted under a system
identity, creating kind of provesque or cross-tenant
compromise scenarios. But yeah, the protocol itself
isn't the vulnerability. It's just a standardized way of
exposing tools to an agent. But the way you expose the
tools themselves, the way you write those wrappers around
your API calls can be vulnerable. Yeah. So, I guess
going back to the web application analogy, it's kind
of like when I connect back to a database, it's usually sort
of one user ID for all queries. It's not that the
database really knows what front-end user really sort of
is sending the query back. So, that's kind of one of the
problems here. And just similar to that, if my
application messes up access control, well, the user is
able to retrieve data they're not having access to. So,
that's really what we're dealing with here. Yeah,
that's really interesting that we sort of have basically old
vulnerabilities coming back here to haunt us. And I think
that's a lot of what these are. Can you sort of walk us
through sort of an example attack, sort of what this
would look like in an application? Yeah. So, the one
vulnerability you may see is leaving the authentication
process up to the AI agent. So, maybe exposing a tool to
the agent that authenticates the user and relying on the AI
agent to properly pass that user identity to their next
tool call that accepts the user ID as an argument, for
example. And then, in those scenarios, you can use things
like a chain of thought prompt injection to kind of convince
the agent that, oh, you've already called this
authentication tool, received this user ID, now go ahead and
call this other tool in order to access data under that
person's identity. So, the attack would basically be some
form of prompt injection where I basically trick the AI agent
into believing I'm someone else. Or what would the prompt
look like there? Do you have sort of an example? Yeah.
Yeah. So, the prompt could look like essentially some
sort of JSON structure where you have the going in a chain
of thought confusion scenario, JSON object that acts as the
output or received from a tool. So, maybe you have some
sort of delimiter such as dashes. You put in the JSON
payload with the expected output from that tool call,
that authentication tool call, or maybe user ID and what
other attributes may exist. And then some other delimiter.
And then the next prompt would be where you made this tool
call. Now, go ahead and perform XYZ function calling
the next tool and return the results to the user and
submitting that prompt. And it does require that you kind of
have some reconnaissance already around the tools that
are available to the agent, the expected return values,
the expected parameters. And that's what the research honed
in on is creating a way for you to enumerate those so then
you can use those details for the prompt injection attack
afterwards. So, complete attack. I first figure out
what tools to use, how to exchange parameters, and then
I find sort of these ways how to nest different prompts and
such to basically expose one back-end tool to the prompt
that I wouldn't have otherwise access to. Exactly. That's
really interesting. A little bit server-side request for
Jurya, I guess, in there as well. In a way, yeah. These
patterns always come back. So, your paper explains all these
details, how to enumerate it, how to find it. Your paper can
be found in the SANS reading room or the cybersecurity
research part of the sands.edu website. Anything you want
people to get away with it or who should read the paper?
Yeah. So, it's useful for anyone that has an AI agent
that they're trying to secure or if their organization is
building AI agents and you'd like to test them to identify
the attack surface behind them. It's great for that.
There is also an open source tool that was released along
with the research that you can use to get started with this
attack surface enumeration. And that tool is linked at the
bottom of the paper. So, excellent. So, tool and paper,
everything free to download from the SANS website, or I
assume GitHub for the tool. And, yeah, thanks for joining
me here and thanks for talking about your paper. If anybody
has any feedback or such, please let me know. And,
again, the link will be in the show notes. Thanks for
listening and talk to you again on Monday. Bye.
