SANS Stormcast Monday, September 22nd, 2025: Odd HTTP Reuqest; GoAnywhere MFT Bug; EDR Freeze

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

previous

Odd HTTP Reuqest; GoAnywhere MFT Bug; EDR Freeze

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 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.