Hello and welcome to the Monday, September 22, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich, recording today from Las
Vegas, Nevada. And this episode is brought to you by
the SANS.edu Bachelor's Degree Program in Applied
Cybersecurity. This weekend I tried a little bit something
different with my diary, something that we have done in
the past and I think haven't really done as much recently
as we should. And that's, well, really just post an
observation where I have no idea what it's about. And
hopefully someone here in the audience or someone who read
it on the SANS will be able to fill in some of the gaps here.
The problem is an sort of interesting request that our
honeypots have been seen lately. And of course,
honeypots typically are being hit by sort of malicious
requests. And that's why I suspect that this is some kind
of maybe recon scan or whatever. The HTTP header that
sort of made this request stick out is the X-Forwarded-App
header. When you're dealing with proxies, they're
usually like the X-Forwarded-Host, X-Forwarded-IP address,
and headers like that being used to indicate if a request
went through a proxy and, well, what the original client
IP address was. This looks like something similar. And
quite often, headers like this with proxies are being used to
potentially bypass authentication, bypass access
control, because, well, then the recipient believes that
this is actually an already authenticated request that was
authenticated by some proxy. That's my guess at this point.
Now, the string, the value being provided with this app
header is somewhat random. It's always app dot and then a
couple of random characters. There are a couple additional
headers like a license ID and such. All of it looks very
much like a mobile device. So that may be another hint here
what's going on. And the URL appears to be pointing to
something like a QR code. So there are a few possibilities
here. What could potentially be happening with these
requests? If anybody has any insight into what's going on
there, well, let me know. And it would be interesting to
really sort of narrow this down what's happening here.
It's just a little bit of hunch here, maybe nothing. But
yeah, I have no idea what it is. Well, and then let's talk
about vulnerabilities. On Thursday, Forta released an
advisory disclosing just patched vulnerability in its
Go Anywhere MFT product. That product is susceptible to a
desolization vulnerability, or actually it's the license
servlet in Go Anywhere MFT that is vulnerable here. An
attacker does not need to be authenticated in order to
actually exploit this vulnerability. And what they
have to do is send a forged license response signature.
That's sort of how they would trigger that desolization
vulnerability. Of course, desolization vulnerabilities
do allow for arbitrary code execution. And that turns this
into an unauthenticated remote code execution vulnerability
with a CVSS score of 10.0. In addition to patching, Forta
advices that you should never ever expose the admin
interface of this product to the public internet. That just
expands your attack surface. And well, I guess there may be
other vulnerabilities. Now, talking about other
vulnerabilities in that product, a couple of years
ago, this product had some similar vulnerabilities. And
they were heavily used for ransomware. So definitely
apply the update as quickly as possible. And also make sure
that you reduce your attack surface and don't expose this
admin interface. Well, and something for the offensive
listeners here to the podcast, the Zero Salarium blog this
weekend introduced a new anti -EDR tool that they are
calling EDR Freeze. Well, other tools around that will
block and kill some endpoint detection and response
products or EDR products. But unlike some of these other
tools, this tool actually doesn't attempt to terminate
the EDR solution on the target. Instead, well, as the
name implies, it just freezes it. It renders it
unresponsive. The other interesting part about this
technique is that it can be performed in user space only.
And that's a very important distinction. A lot of the
other techniques that counter EDR, they usually require
something like a vulnerable driver that is then being used
for privilege escalation. And then that access can be used
in order to mess with the EDR solution. This is not
necessary for this particular technique. Instead, well,
Windows error reporting is used to interact with the
target process. In this case, the EDR process. The tool
takes advantage of the mini dump write dump function,
which is really intended to sort of take a quick memory
snapshot of a process. And that's useful for debugging.
And in order to create that memory dump, well, the process
has to be halted briefly. Now, this is usually not a problem
because that's very short and the process will immediately
resume after that memory dump has been collected. But Sir
Solarium in their blog post also looked at how to overcome
some of these limitations. There's also another issue
they have to overcome, and that's the protected process
light, which is essentially a flag that's set for anti
-malware processes and such to provide some additional
protection there. And well, in their blog post, they outline
some tricks that they're using there. First of all, they're
using a tool called WerFaultSecure that essentially
is used to create these debug dumps and introduce faults.
Basically, that's sort of what it does. So that overcomes the
restrictions on these processes and allows normal
user to interact with these processes. And then after they
sort of attach this tool and create their memory dump, then
they immediately start pulling that and that will then more
or less indefinitely freeze the process. So that's
basically put it in a suspend state. There's more detail in
the blog post, how it all works and how to use it. The
tool itself is made public on GitHub, so you can just
download it and experiment with it. I haven't had a
chance to do that yet. So as always, be careful. May do
something completely different that tool, but that sounds
like a reasonable approach to do this. Now, from a defensive
point of view, and I'm always on the defensive side here,
what you could do is you could basically monitor this
WerFaultSecure tool. That's nothing that a user typically
would be running. And then you can also monitor what
arguments are being passed to it and check if any of the
arguments, which is essentially the PID of the
process you're interacting with, is the PID of one of
these protected processes. Well, and this is it for
today. So thanks again for listening and thanks for
liking and subscribing to this podcast. As always, I'm in
Vegas here at our network security conference this week.
If you want to say hi, I'm teaching 522 here, SEC 522. So
just look it up. I haven't seen what room I'll be exactly
in yet, but it shouldn't be too hard to figure out. I
usually carry some stickers and such around with me. I
think I'll also do a presentation later this week
and I'll announce that later. Well, that's it. Thanks and
talk to you again tomorrow. Bye.
