Hello and welcome to the Monday, July 28, 2025 edition
of the SANS and the Storm Center's Stormcast. My name is
Johannes Ulrich, recording today from Jacksonville,
Florida. And this episode is brought to you by the SANS.edu
graduate certificate program in cloud security. In diaries
this weekend, we have one by Xavier looking into, well,
we'll need Linux feature. And Xavier looks at it from sort
of a reverse analysis point of view, but it's really very
applicable for a number of different security tasks. And
that's Linux namespaces. Essentially, each process in
Linux may have sort of its own namespace, its own view of the
environment. And in this particular case, Xavier looked
at networking, where first of all, you are able to just
simply turn off networking capabilities for a particular
process with the sudo unshare dash dash net bash command.
That basically gives you then a bash shell without
networking. And now if you try to analyze some malware, well,
that malware can no longer communicate outbound. But it
goes more fine grain than that. You can also just set up
a different routing table for this particular process. And
for example, redirect traffic to sinkholes and the like.
Quite often when you're analyzing malware, you don't
want to turn off networking altogether because the malware
will not run if it can't download second stages and
such. But you just want to capture like what is that
second stage it's downloading and then send the request to a
sinkhole where you're just recording the HTTP requests.
And that's sort of where this feature is really helpful. But
like I said, namespaces in Linux can do a lot more
things. There's file systems and mounts and similar
features that you have available as you have for
networking. And I think it's a little bit an overlooked sort
of security feature in general when it comes to Linux. And a
lot of even experienced Linux administrators often haven't
really heard of namespaces and how they can be used. Well,
the next story, I guess, is sort of no good. Deed goes
unpunished. Microsoft a couple of years ago came out with UI
automation, user interface automation. That's an API that
allows software running on a system to better and more
simplistically interact with user interface elements. So,
for example, software could read the content of Windows or
interact with buttons and other user interface elements
on the system. That, of course, makes it much easier
to script GUI interactions. And, well, attackers are now
taking advantage of this. They're now using malware in
order to, for example, figure out what software is running
on the system, then read the content of various Windows.
And if they're, for example, seeing a browser window that
is connected to an online banking website, well, they
may take advantage of that and then steal credentials as the
user enters them. Overall, this is not sort of a
fundamentally groundbreaking new capability here that makes
Windows a lot less secure. It just makes it a little bit
easier for attackers. Attackers in the past have,
for example, just used browser plugins in order to steal
requests. That sort of works, too. It is a little more
generic. It goes beyond browsers. And that just makes
things a little bit easier for the attacker to interact these
kind of interactions with the user interface. From a
defensive point of view, Akamai recommends to basically
monitor the UI automation core .dll. That's where you would
see earliest requests and interactions like this
happening. Basically, what software uses that dll would
certainly be something worth paying attention to. And they
have here a couple of queries in their blog that will allow
you to select and query this interaction from Akamai's own
tools. For your tool, whatever you're using to monitor your
endpoints, you probably have to figure out how that
translates. And then something a little bit different here.
Usually, I don't really talk much about tools. But this
tool that I just came across and find kind of useful. In
particular, since we have so many vulnerabilities in APIs
these days. This particular tool, AutoSwagger, is built
for APIs that are using the OpenAPI or Swagger standard in
order to publish documentation for their APIs. And then the
tool does something that's actually really not all that
terribly difficult. It reads the specification, which is
meant to be machine readable, to then find particular
vulnerabilities in the API. For example, various API
endpoints that may be leaking PII without requiring
authentication. Sounds like a tool that you probably should
give a try if you are developing APIs or if you're
testing them. The entire process is a little bit like,
you know, what you have in SOAP with Whistles. OpenAPI or
Swagger for REST APIs is often used to describe the APIs,
again, in a standardized machine readable format. Well,
and that's it for today. So thanks again for listening and
talk to you again tomorrow. Bye.
