The RedVDS Takedown, Yet Another Chinese APT Emerges, and the StackWarp AMD Bug

So this is this is one of those incidents. It looks like in their analysis, Microsoft said that they track this threat actor as Storm 247-O. They've observed many cybercrime actors using this platform and they also have associated it with the raccoon Office 365 fishing service, which was taken down quite a while ago. Red VDS launched in 2019 and it's been operating since then.

It doesn't seem to be super stealthy. It uses a company that purports to be in the Bahamas as its its operating entity. And Microsoft went after this organization with legal means as well as seizing the technical infrastructure, which is a kind of a typical way that they and other organizations go after cybercrime groups, especially these phishing as a service, malware as a service, any of these cybercrime hosting services.

That's one of the ways that they go after them both with legal means and seizing their their actual physical infrastructure. So this is one of those operations. We have a story up on it on the site that you can read. I'll put that in the show notes as well. There's a bunch of different ways that threat actors were using the red VDS infrastructure. One of the main ways was in business e-mail compromise or BEC scams, it was kind of one of the primary use cases for this platform. They would gain access to target e-mail accounts, you know, monitor the conversations and then sort of insert themselves into those conversations as a trusted party to redirect payments, you know, to another bank account or wire transfer service, which is a typical structure of ABEC scam. This is just one of the ways they were enabled. This platform was also used for large scale phishing attacks as well as payment diversion scams

tied to real estate transactions, which is, I don't know if up and coming is the right phrase, but it's one of those use cases for phishing and other attacks that are becoming more prevalent instead of just the typical targeting of SMBs or even enterprises with BEC scams. The payment diversion for real estate transactions, which can obviously be very large amounts of money, are becoming more prevalent as well.

So that's something that was was going on in this infrastructure, Microsoft said. And threat actors were also using this infrastructure to host their own C2 infrastructure and fishing landing pages. So, you know, it was one of those all around kind of problematic infrastructures and platforms. So it's good to see Microsoft taking some action there. As I said earlier, they're very aggressive in doing this sort of stuff when it comes to attackers either abusing Microsoft platforms, you know, such as Azure, or anything that Microsoft happens to own or using unlicensed software in any way.

Microsoft really goes after those groups aggressively, as I said. So it's not surprising to Microsoft to see Microsoft do this, but it's always heartening to see things like this get taken down and disrupted. So that was good to see. You can read the story that's up on the Decipher site right now as well. So another interesting story. I mentioned last week that Cisco Talos had released a really good research paper on a new Chinese APT that they had been tracking for a little bit.

And this week they released another analysis of another suspected Chinese APT. Cisco's naming convention for these starts with UAT. So this one is UAT 8837 and they assess with medium confidence this is a Chinese Nexus actor, but it has all the hallmarks of that and the TTPS are are pretty close to a lot of other Chinese AP TS and Telos's analysis shows that this looks like an initial access team.

So this would be one of those APT groups whose main job is gaining access to target organizations, you know, whether that's an enterprise, a government agency, a small company, whatever it happens to be. The Chinese APT ecosystem, as we've talked about before, has a pretty, it's a pretty broad umbrella, but it also has some pretty specific division of Labor in a lot of cases.

So there will be teams that are specifically tasked with initial access, then they might hand off that access to a post compromise team that does the lateral movement and reconnaissance around that network. And then that team may hand it off to another third team that does the actual collection and exfiltration of whatever the intelligence and sensitive data that the the overall group is looking for might be.

So there's a lot of cooperation, collaboration, but there's also often times this division of Labor, which is an interesting hallmark of the Chinese APT ecosystem. See it sometimes in the Russian ecosystem as well, but it is a very well known portion of the the Chinese APT ecosystem. So this particular actor, UAT 8837 has the capability to exploit known vulnerabilities as well as zero days.

So that tells you that they have access to either they're, they're doing their own original vulnerability research or they have access to that research that's being done by, you know, a sister group in their, under their umbrella, which, you know, is another typical thing you see with the Chinese groups. This group has been targeting critical infrastructure organizations in North America. So I would encourage folks to go and read Talos's analysis of this.

It's, as usual, very well done. And it, it lays out a bunch of the tools and pieces of malware that this group use uses, Excuse me. And you know, some of which is custom malware and custom tools, some of which is known to other, you know, or used by other groups or some of which is legitimate tools that are, they're just misusing as is seen a lot in these operations as well.

And they have a good breakdown of the way that this this team does hands on keyboard work after they're into a target network, which is always interesting to see. So I'd encourage folks to go and read that as well. And the third story I wanted to mention, and this is a really interesting one for me, I have like this weird affinity for hardware based vulnerabilities. You know, you can think back to things like Spectre and Meltdown and a lot of the side channel attacks or speculative execution attacks that we've seen over the last 15, I guess years, something like that.

They're always fascinating to me, even though the depth of technical knowledge needed to understand them is not something that I usually have. They're often like way over my head in terms of the actual understanding of how these attacks work. But this week there was an interesting vulnerability. It's not a side channel attack or a speculative execution attack. It's a vulnerability that a team from a German Research Institute disclosed this week. And it's called Stack Warp.

And I'm just going to read the the simple explanation that they have on their page. It's a security vulnerability that exploits A synchronization bug present in all AMD Zen One through 5 processors. In the context of SEVSNP, this flaw allows malicious VM hosts to manipulate the guest VM stack pointer. This enables hijacking of both control and data flow, allowing an attacker to achieve remote code execution and privilege escalation inside a confidential VM. So that's the technical explanation. That's their short version of it. They have a very detailed research paper that's online and they're presenting this work at USENIX in a little in a few months.

So so AM DSEV. If for people that aren't familiar is AMD secure encrypted virtualization technology which is ACPU extension that enables you to use secure virtual machines in the presence of an untrusted hypervisor. So this is useful if the hypervisor might be compromised or something along those lines. So this is not, as I said, it's not a speculative execution or side channel leak or anything like that. It's a hardware bug in a MDCPUS.

The good news is that AMD has released fixes for the effective processors. So those are available. There's, as I mentioned, a very detailed research paper on this, and I would encourage folks to go and have a look at that. Fundamentally, you know, these hardware bugs are very, very, very difficult to find. That's why you don't see a ton of them and often quite difficult to exploit.

The good news is that this research team said that they have no evidence of exploitation in the wild yet. Obviously that does not mean that it has not been exploited. It just means there's no evidence of it. But the it's good news that there's no evidence of it. Obviously there is a CVE for it. It's 2025-29943 if you want to go read that. AMD has a security advisory out as well. But this is one of those things, you know, I spent a lot of time reading this just to get the lay of the land and see how serious it was in, in how widespread the, the issue was. It's pretty widespread for, for machines that run AMD processors.

But as I said, there's a, there's a fix available from, from AMD, which is the good news. So folks should go and check that out. Stack Warp is the name of the bug and you can find the the research at stackwarpattack.com. So go have a look at that. I'll drop the the link in the show notes as well. So that's kind of the the overview for this week. Be back next week with another news Rep podcast.

And the last thing I wanted to mention was the other podcast that we released this week was my interview with Jeremiah Grossman and Robert Hansen. 22 guys I've known for a very long time, more than 20 years actually, and who have been around the security industry for much longer than that in fact, and have done all kinds of different things. If you're not familiar with their work, I'd encourage you to go and look them up. I can't list it all here, but we had a really great conversation about vulnerability management, kind of the cyclical nature of not just vendors and enterprise security teams trying to address VM and patch management and everything that goes along with that, but also the ways in which people are trying to approach it now from more of a kind of a data backed way and not just hey, this is a critical CVSS,

you know, 9.8 bug. We got to go patch it everywhere, but more of a, hey, this bug isn't being used in breaches and here's the result of those breaches. So we know that it can cause actual damage. We need to go patch this. Or on the flip side of that coin, this bug is serious, but it's never been used in a breach. It's there's no evidence it's actually been exploited in the wild. You should get to it, but it's not something you should, you know, drop everything and go patch.

So I'd encourage everybody to go have a listen or watch that podcast. It's on our YouTube channel as well, and it was a great conversation. Those are two of the smartest people I know, and it's always great to hear their perspective on these things. We talked a lot about not just vulnerability management, but a lot about the industry and security tools in general. So if you're interested in that kind of thing, which I imagine you are, go have a listen. So thanks everyone for listening here. I appreciate it.

Have a great week and I'll talk to you soon.