Podcast Detail

SANS Stormcast Tuesday, July 14th, 2026: MCP/AI Related Scans; Improve Router Hygiene; OAuth Client ID Spoofing; Veeam Vuln;

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

previous
Podcast Logo
MCP/AI Related Scans; Improve Router Hygiene; OAuth Client ID Spoofing; Veeam Vuln;
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Tuesday, July 14, 2026 edition
 of the SANS Internet Storm Center's Stormcast. My name is
 Johannes Ullrich, recording today from Washington, D.C.
 And this episode is brought to you by the SANS.edu Graduate
 Certificate Program in Cybersecurity Engineering.
 Manuel today wrote up an interesting trend that he has
 been observing in a site that he is watching. Well, it's
 just a basic web server, but more and more it is being hit
 by requests for MCP connections. So the model
 control protocol that's commonly used with AI, as well
 as requests for AI credentials. For a long time
 we have seen a lot of requests for like .env files and the
 like, essentially files that typically contain credentials.
 But what Manuel is seeing and that sort of matches our
 global data as well. More and more of these scans are
 looking for credentials specifically associated with
 AI models. With the goal of course being that some of
 these credentials could be abused by the attacker to gain
 access to free to the attacker AI tokens. Now the MCP
 connection attempts are also interesting. First of all,
 many of them are just checking for the presence of the slash
 MCP URL. Of course, if there's a 404 coming back, the URL
 doesn't exist and the attacker knows that this is not at
 least the right access for the API. Well, but a couple of
 requests that Manuel observed also contained the full MCP
 compliant payload to initiate a new connections. So
 definitely attackers are looking for these services to
 again likely abuse them for their own purposes. And CISA
 together with a few other self information security related
 federal organizations and the FBI has published some
 guidance on how to better protect your routers. Now the
 routers we're talking about here are more sort of the ISP
 enterprise routers, not your home router, which of course
 is often the target of attacks. The guidance here is
 specific to exploits that have been observed in recent
 attacks. attacks by Russian threat actors. So none of
 these attacks are really new, but there are really a couple
 of nuances here. I think they're often overlooked. For
 example, with SNMP, well, implement and only allow SNMP
 version three. I see that often missed. I often see SNMP
 version one, version two still enabled. Well, just in case
 you need it, it's insecure. It uses simple community strings
 for authentication that are easily guessed and sniffed off
 the wire. So definitely something that you should
 avoid. Secure passwords that should be really table stakes.
 What I find particularly interesting is a reference
 here to Cisco smart install. Cisco routers by default come
 in the smart install enabled configuration. And the goal
 here is really that you can basically deploy one of these
 routers and then remotely configure it. So in order to
 configure it from scratch, there is usually no
 authentication involved. But even after you configured the
 router, this smart install feature often remains enabled,
 allowing essentially anybody to reconfigure your router. So
 definitely this is, I think, the number one part here I
 take away from this guidance because I've seen this even
 mentioned with some of the volt-typhoon breaches and
 such that Cisco smart install here was used in order to gain
 access and change configurations of routers.
 Also, basically, you know, firewall best practices block
 some of the common ports used by protocols that really
 shouldn't be used across the internet like SNMP, TFTP and
 SMI. So these protocols should really not be exposed and
 their access should be limited to the local network. And
 Proofpoint documented an interesting and somewhat
 unexpected behavior from EntraID that is apparently
 being abused by some threat groups in order to brute force
 usernames and passwords. So whenever you send a request to
 EntraID to verify username and password, in particular, when
 you're using the resource owner flow, you will send a
 client ID that is identifying the application, basically
 sending the request and the username and password. What
 these attackers do is that they use random, non-existing
 client IDs that are correctly formatted. They use UUID
 version 4 format, these client IDs. What happens in the logs
 in this case with EntraID is that the application name is
 not populated since, well, no application with this ID
 exists. The login will also fail. However, the attacker
 will get back information about whether the username or
 the password were correct. So that way the attacker is still
 able to enumerate valid users and also verify whether or not
 a particular password they're attempting to use does exist,
 whether it's valid for this particular account. But since
 administrators often summarize by application name in order
 to find, for example, suspicious frequent requests
 from particular unregistered applications. Well, since
 there is no name, these events often go overlooked and are
 not recognized as brute forcing. So what Proofpoint
 recommends here is that you specifically look for any
 events where the application name is not populated as this
 may be an indicator for the, this kind of brute forcing.
 And the other problem of course, is since the login
 fails. Because if the attacker is getting back a result that
 yes, the username and password is correct, well, it still
 didn't result in the login success. So if you're just
 looking for login success, for example, from odd
 applications, well, you will not get any hits. So if you're
 using EntraID, take a look at this Proofpoint block. They go
 into more detail about how to detect and how to search for
 these types of events. Well, ahead of patch Tuesday, I want
 to mention at least one vulnerability and that would
 be one published today or advisory for it published
 today by backup company Veeam. It's a remote code execution
 vulnerability, but it does require credentials. However,
 they can be any domain user. Well, and this is it for
 today. So thanks for listening. Thanks for liking.
 Thanks for recommending this podcast. Thanks for everybody
 who attended my talk today here at Sands Fire and well,
 talk to you again tomorrow. Bye.