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.
