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

previous

RedTail Defenses; SonicWall Breach; Crowdstrike “Issues”; Ivanti 0-days; Mapping Agentic Attack Surface (@sans_edu paper)

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 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.