SANS Stormcast Friday, October 17th, 2025: New Slack Workspace; Cisco SNMP Exploited; BIOS Backdoor; @sans_edu research: Active Defense

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

previous

New Slack Workspace; Cisco SNMP Exploited; BIOS Backdoor; @sans_edu reseach: Active Defense

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 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 Master's Degree Program in Information
 Security Engineering. Well, today's diary was really more
 sort of a little bit an internal thing, and that's a
 new DShield support Slack workspace. We had Slack
 workspaces for the last almost 10 years, I believe, that we
 started using Slack and has been quite successful. Sadly,
 Salesforce, which was the company behind Slack, for some
 reason that I haven't really been able to track down
 exactly how it happened, moved us to an enterprise account.
 Now, they're known to sometimes offer sort of trial
 pro accounts, but apparently they mixed it up with a SANS
 account, moved us to the enterprise account. And while
 it was nice to have the features, the bill was not
 quite as nice, and they weren't able to easily undo
 their mistake. So the only option we really had was to
 move to a new Slack workspace. And that's what we're doing
 now. You should have already received an email with a link
 to the new Slack workspace if you signed up for the original
 Slack workspace. And there's also a link in today's diary.
 Also, all the other links to our Slack workspace are
 hopefully updated. If not, let me know if something still
 points to the old Slack workspace. The old workspace
 will be deleted on Monday, and then everything should be
 moved over to the new workspace. While we're talking
 a little bit about internal stuff, there was also an issue
 with a particular Pocketcast application for Android with
 this podcast. They fixed it. It just required them
 refreshing the feed. And if you're a user of that
 application and you note that the feed isn't updated, you
 can actually request it from them. They were really amazing
 and quick in responding to have that working again. And
 any other podcast issues, please let me know. I can't
 really test all the different feeds and applications people
 are using to listen to the podcast. And so if you run
 through any problems, please let me know. And then we have
 a bit more detail about the recently patched vulnerability
 in Cisco devices. This affected Cisco switches, and
 it was the SNMP vulnerability. Now, the vulnerability itself
 initially didn't really look that bad. It was well
 described as denial of service and remote code execution. But
 the remote code execution was only possible for an account
 with elevated privileges. However, even at the time when
 it was released, when the patch was released late in
 September, it already mentioned that this
 vulnerability is actually already being exploited. So
 now we got more details here from Trend Micro about how
 this vulnerability was exploited. And essentially,
 Trend Micro here explains that the attacker focused on older
 Cisco models, which did not do any address space layout
 randomization, which as a result made this vulnerability
 easier to exploit. It's exploitable on newer devices
 as well. But in order to bypass the randomization, it
 takes a few tries to actually make the exploit work. And
 that, well, I guess makes it a not reliable vulnerability to
 exploit. So they're focusing on the older devices. Once
 they gained access to various switches, they basically used
 that access in order to break down some of the isolations
 that you may have set up, like VLANs and the like, and they
 make lateral movement easier. You typically then ended up
 with rootkits on your Linux devices. So that was sort of
 the end game here in this particular case, which then
 basically exposed you to a fixed username and password,
 sort of a backdoor access, and also backdoor accessible via
 UDP. So they basically broke down your network protections
 by breaking into these Cisco switches and removing various
 security precautions that you may have configured, and then
 access individual endpoints they were interested in.
 Overall, a pretty sophisticated attack. But with
 this write up from Trend Micro, you now have something
 to threat hunt for and make sure that you aren't already
 exploited. And as always, of course, make sure that you
 update your network equipment. And then we've got an
 interesting blog post here by Paul Asadoorian summarizing
 research done by researchers at Eclipseum about, well, not
 exactly backdoor, but something effectively a
 backdoor in framework devices. This framework is a laptop
 manufacturer. They're famous for their very maintainable
 and modular laptops. And the bias in the firmware in these
 laptops, well, comes with a firmware or boot shell. And
 this is not unusual. There's often sort of a little shell
 that executes before the system fully boots. You may
 have run into this if you had a corrupt disk or something
 like this, and the main operating system couldn't
 boot. But the problem with these boot shells is that,
 well, they have access to the complete system before it's
 completely booted. So if you're able to modify the
 system at this point, well, then you are able to, for
 example, disable some security features that the bias
 attempts to implement. And that's exactly what's
 happening here. There's a command, the mm command, that
 allows you to read and write memory. And with that, it's
 possible, for example, to override some security checks
 and even make them persistent across reboots. Pretty
 interesting research framework has addressed these
 vulnerabilities. I think for one or two models, they still
 have an update pending for this particular issue. But
 wouldn't be surprised if other manufacturers don't have the
 same particular issue. Well, and it's Friday again, and I
 have yet another sans.edu student. Could you introduce
 yourself, please? Well, and it's Friday again, so it's
 time for another sans.edu student, and their research
 paper with me today is Mark. Mark, could you introduce
 yourself, please? Yeah, good morning, Dr. Aldrich, and it's
 Mark Stevens. I am a cybersecurity architect at
 Cisco, and I've recently completed my MSISE, which was
 a phenomenal experience. Yeah, so great that you're all done,
 but before it got done, you had to write a research paper.
 So what was the research paper about? Can you do a quick
 introduction on that? Yeah, so I haven't had a driver on why
 I needed to write this research. And it kind of
 started after one of my healthcare CISOs said to me,
 you know, it doesn't really matter what we are doing. We
 believe that we're breached. We believe that the
 adversaries are already inside of the network. And so after a
 little bit of thought of like, okay, if somebody is already
 on the inside of the network, what's the best way to detect
 them? And so I focused on active defense and adversarial
 engagement. So the ability to be able to identify that the
 malicious attackers are inside of our environments and to get
 them to reveal themselves by making mistakes, by
 encouraging them to make mistakes. So just to clarify,
 active defense here means more something like deception. It
 doesn't mean hacking back. So it absolutely means deception
 and studying. So I did use the MITRE Engage framework. So
 everyone's familiar with MITRE attack framework, where we
 look at TTPs of different campaigns and techniques and
 tactics that adversaries are using. Well, there is a, I'd
 say, little known or little used framework called MITRE
 Engaged. And MITRE Engage actually enables us to
 actually build detections, deceptions, and also ways that
 we can study adversaries in our environment. So it's a
 kind of a progression of different ways that we can
 learn and engage with the adversary. Hacking back is
 definitely should be left to somebody with, you know, a
 federal government type of activity. So not advised to
 hack back. Yeah. So what kind of actors did you apply that
 to? Was it sort of more your average run-of-the-mill
 exploit or were you really more looking for more advanced
 attacks here? Yeah. So actually, I, you know, I
 purposely did not choose an extremely advanced, you know,
 malware injection or some type of attack. But I looked at the
 principles and the concept of MITRE attack framework where
 an attacker progresses through the stages. You know, once
 they have initial access, then the next phase typically is
 discovery. So if I focused on that, so my research started
 from the concept of the attacker is already on the
 inside of my network. How do I enable or how do I identify
 when an adversary starts to try to discover more or
 better, richer targets inside of my environment? So I
 focused on a lot of scanning, the ability for them to
 discover infrastructure in the network, the ability for an
 adversary to actually start active scanning and looking
 for systems. And then, of course, once the system's
 compromised or has been accessed, then how do they,
 when they start looking for, you know, the crown jewels,
 the files, the things that they may want to either
 encrypt or steal in the environment. So I didn't
 progress forward into some type of, you know, reverse
 malware and malware reverse engineering concept. I wanted
 to focus on the reality of the adversary inside my network.
 And now they need to expand inside of that environment.
 And, of course, if you look at many of the active campaigns
 through MITRE ATT&CK, each one will say, like FinTech, once
 they've had initial access, their next phase is discovery.
 What can they find inside of the environment to actually
 steal, destroy, or encrypt? Can you walk us through sort
 of, you know, a little example, like, you know, how
 would they find a particular document or, and sort of how
 that informs your detection? Yeah, so the way that I did
 it, you know, it has to be, because it's a research
 project, it has to be some type of controlled
 environment. So I did build an environment that I knew that I
 leveraged deception technologies. I just deployed
 honey tokens on a Linux platform. I wrote and deployed
 a honeypot in my environment that when the honeypot was
 actually accessed, then it would actually send alerts
 into a professional system, Cisco XDR. I used that because
 that's what I had available. And then finally, you know,
 comparing active scanning of an environment to planting
 networks. So, you know, kind of the dark nets inside of our
 environment where we know there should be no activity.
 Once we see some type of active scanning into that
 environment, then at that point, I want to be able to
 detect and respond to that. So, honey token, honey pots,
 and then dark nets or honey nets, if you want to use a
 honey phrase, with inside of those. And so I built each of
 the research tests, the experiments around that. The
 first one was simply, you know, assume an adversary is
 in your environment. They're not going to have Kali Linux,
 right? They're not going to have some attack tool already.
 Now, maybe they upload it, but it's most likely that they're
 going to find a foothold on some existing system. So I
 chose in my research, you know, a simple Windows, poorly
 secured Windows platform where we assume that they already
 have access. So what tools from Windows are there at that
 point for them to be able to launch? In this particular
 system, I allowed them to install Nmap, and once they
 have Nmap on there, then at that point, they could do
 active scanning of networks, right? So I placed a target
 honey pots in a network with a number of other servers. When
 that Nmap session scanned and made a connection to that
 honey pot, at that point, you know, it's a high-fidelity
 alert. So, and that's one of the things I think it's worth
 noting, that in an active defense posture, it is often a
 goal to have a high-fidelity detection that we can close
 down the detection and the response time. So actually
 enable us to know that there's somebody in the environment
 that we want to respond to. So that's actually, you know, so
 going back to MITRE engaged, interestingly enough, there
 are scenarios where you may wish to actually study the
 adversary in your environment. And that studying means
 allowing the adversary to proceed through their attack
 so that you can see what commands that they use, what
 are they actually looking for. Now, again, I would suggest
 that only being for the most sophisticated of organizations
 to allow a potential adversary into your environment and
 knowingly and allow them to move. But there are areas
 where you can now build sidecar networks or
 environments that you know that the adversary can attack,
 you know, call it a network
 that you don't mind being compromised with inside of
 there. So once you have that environment, so let's back
 that up. So you could either put some simple detections in
 the environment that as soon as something connects to it,
 that is a high-fidelity attack, high-fidelity attack
 detection. Or you could build some environment so that you
 allow the adversary to proceed through and, you know, get
 further into a false environment. But we make it
 look as real as possible. We make it look as attractive as
 possible for a real target. So first is services. Then the
 other, it would be the honey token concept. And the honey
 token concept is, you know, maybe it's false files, files
 that are full of passwords, files that are full of crypto
 -looking keys, files that are some type of personal
 identifiable information that an attacker may be interested
 in to achieve or retrieve, right? So that's another, you
 know, that honey token has to be attractive. So we're
 assuming that the adversary is on the system. And then once
 the adversary is on the system, they're then at that
 point going to search for it. If you look at the average
 Linux platform, right, at the default configuration, you can
 run fine commands on the Linux system, and it really doesn't
 generate any logging of any interest. So in a honey token
 environment, because we know these are the files that we
 want them to find, at that point I wrote a simple Python
 script to look for a file access. And then once the file
 was accessed, to be able to capture the user credentials,
 the file type, the timestamp, and then to send that via
 syslog to, you know, a target. And once it's sent to a
 target, at that point you can build detections from that.
 The goal was to give us more telemetry to be able to take,
 to feed into a detection. Once we have a detection, then we
 can, you know, respond accordingly. So the way you
 described it was really sort of more a little bit that
 threat hunting scenario, basically, you assume
 compromise, now you try to find the attacker. Do you
 think that's sort of part of threat hunting, or could also
 be sort of part of intrusion detection, basically detecting
 intrusion before it sort of happens? Well, you know, so I
 would recommend not putting honeypots on the internet
 side. So to place honeypots or any type of detection on the
 inside of the network. I'm focusing on, in my research, I
 focus on the concept of the adversary is already inside of
 the network. You know, there's many pundits out there will
 say there's two types of organizations, right? The ones
 that know that they're compromised, and the ones that
 are compromised, right? So it's a concept of if we place
 ourselves in a state of paranoia that the adversaries
 are in our environment, this is a healthy step to not
 overwhelm our SOC with, you know, extra information. This
 is a targeted deception and active defense system inside
 of our environment, that we know that if anything connects
 to it, then at that point, it is something we want to
 investigate. Because, you know, and some of it may be, I
 put a honey token on an executive's machine. It's
 hidden. It's in a hidden directory. The executive
 really should never be able to see it. But suddenly, if a
 process scans that system and accesses that file, that's a
 good indication that something unusual is going on in that
 system. So any way that we can create a new detection or an
 early warning detection inside our environment, that's what
 we're really focusing on. Arguably, you could say, well,
 this is this threat intelligence. That's where
 once we understand, so importantly, active defense is
 not static. Active defense needs to move with the
 campaigns that are being used or the vulnerabilities that
 are actually in our environments by the attackers.
 So, you know, if we deploy static honeypots, that's
 really not going to be a huge amount of value. But if we can
 deploy dynamic honeypots or dynamic files or services of
 our containers, you know, think about Log4j when, you
 know, and I realize it's still actively scanned and it's
 still actively exploited in our environments out there.
 But as that was first deployed, if we had a
 container that was a honeypot that could kind of simulate
 the services and the vulnerabilities for Log4j and
 something connected to it, well, at that point, again,
 high detection, high fidelity detection, and gives us a
 great opportunity to actually study what are these
 adversaries actually after in the environment on that side.
 So arguably, it is absolutely about active defense and
 detection of something that may be inside our environment,
 but it also enables us to look at active threats that are
 ongoing and be able to continuously iterate our
 active defense environments. And, you know, the more
 sophisticated organizations can actually take that
 information that they learn and feed it back into our
 defenses. So changing our snort signatures, our WAF
 signatures, or maybe even how something may have gotten into
 an environment. So absolutely, it is, you know, not only
 something we deployed to ring an alarm bell, but something
 we deployed to make the blue team better. Yeah. Yeah,
 thanks for that summary, Mark. And the link to the paper will
 be in the show notes. And I hope many people will enjoy it
 and, well, maybe deploy some of those ideas in their
 network. Thank you. Thanks, Dr. Rovek. And that's it for
 today. So thanks for listening and talk to you again on
 Monday. Thank you.