Recommended reading

World's first CPU-level ransomware can "bypass every freaking traditional technology we have out there" — new firmware-based attacks could usher in new era of unavoidable ransomware

News
By published

A cybersecurity expert has created a proof of concept for CPU ransomware.

Ocypus Iota A62 Digital CPU Cooler
(Image credit: Tom's Hardware)

Rapid7's Chrstiaan Beek has written proof-of-concept code for ransomware that can attack your CPU, and warns of future threats that could lock your drive until a ransom is paid. This attack would circumvent most traditional forms of ransomware detection.

In an interview with The Register, Beek, who is Rapid7's senior director of threat analytics, revealed that an AMD Zen chip bug gave him the idea that a highly skilled attacker could in theory "allow those intruders to load unapproved microcode into the processors, breaking encryption at the hardware level and modifying CPU behavior at will."

Google's Security Team has previously identified a security vulnerability in AMD's Zen 1 to Zen 4 CPUs that allows users to load unsigned microcode patches. It later emerged that AMD Zen 5 CPUs are also affected by the vulnerability. Thankfully, the issue can be fixed with new microcode, just like a previous Raptor Lake instability. However, Beek saw his opportunity. "Coming from a background in firmware security, I was like, woah, I think I can write some CPU ransomware," and that's exactly what he did.

According to the report, Beek has indeed written proof-of-concept code for ransomware that can hide in a CPU. Reassuringly, he promises they won't release it.

As per the report, Beek reckons this type of exploit could lead to a worst case scenario: "Ransomware at the CPU level, microcode alteration, and if you are in the CPU or the firmware, you will bypass every freaking traditional technology we have out there."

Beek also referenced leaked comments from the Conti ransomware gang, which surfaced in 2022. In a presentation given at RSAC, he highlighted chat logs from the group. "I am working on a PoC where the ransomware installs itself inside UEFI, so even after reinstalling Windows, the encryption stays," reads one. Another noted that with modified UEFI firmware, "we can trigger encryption before the OS even loads. No AV can detect this."

The upshot? "Imagine we control the BIOS and load our own bootloader that locks the drive until the ransom is paid," a hacker hypothesized.

Beek warns that if bad actors were working on these exploits a few years ago, "you can bet some of them will get smart enough at some point and start creating this stuff."

To close his interview, Beek expressed his frustration that "We should not be talking about ransomware in 2025," and stated that everyone involved should be pulling together to fix the foundations of hardware security. He also bemoaned how many ransomware breaches were underpinned by high-risk vulnerabilities, weak passwords, lack of authentication, and more.

Follow Tom's Hardware on Google News to get our up-to-date news, analysis, and reviews in your feeds. Make sure to click the Follow button.

See more CPUs News
Stephen Warwick
Stephen Warwick
News Editor

Stephen is Tom's Hardware's News Editor with almost a decade of industry experience covering technology, having worked at TechRadar, iMore, and even Apple over the years. He has covered the world of consumer tech from nearly every angle, including supply chain rumors, patents, and litigation, and more. When he's not at work, he loves reading about history and playing video games.

9 Comments Comment from the forums
  • edzieba
    Ah warned ye!
    Ransomware is a really benign exploit in this case. With unfettered and effectively invisible owning of the CPU, you can insert much more subtle and nefarious malware. For example, you could modify every encryption call to a random value in a way that returns apparently random values that are instead deterministic. An attacker than insert this malware into a CPU, and then be able to decrypt every piece of plaintext that passes through that CPU, with no obvious way to know this is occurring (i.e. not just returning a static value for every call for a random one).
    Reply
  • jp7189
    I'm not clear on where this resides. Does this actually alter the CPU chip itself and ride along if it's moved to a new motherboard? Or does it alter the BIOS chip of the motherboard to patch CPU microcode at runtime?
    Reply
  • bit_user
    The article said:
    Beek has indeed written proof-of-concept code for ransomware that can hide in a CPU.
    Not exactly sure what he means by this. As mentioned in the prior articles about Zen's microcode signing vulnerability, the CPU's microcode is reset upon reboot. So, the malware cannot reside there, across reboots. The exploit must involve some other hack, such as infecting UEFI.

    I guess, one way you could use hacked microcode to hide malware is by relying on the microcode to interpret seemingly benign code in a malicious way. This could render whatever footprint the malware might have on the system virtually invisible to malware scanners.
    Reply
  • bit_user
    jp7189 said:
    Does this actually alter the CPU chip itself and ride along if it's moved to a new motherboard?
    No. Something would have to reload it into the CPU, every time the machine boots.
    Reply
  • bit_user
    edzieba said:
    With unfettered and effectively invisible owning of the CPU, you can insert much more subtle and nefarious malware.
    The people who matter already know this. Infected microcode can probably disable memory encryption and even inter-process protection features, allowing one process or guest VM to eavesdrop on another. This makes it a very big deal, for cloud operators.
    Reply
  • jp7189
    bit_user said:
    No. Something would have to reload it into the CPU, every time the machine boots.
    So, based on that, replacing the motherboard of possible refreshing the BIOS would fix it. I'm thinking of CPUs on the secondary market and how this would affect; could they be precompromised at time of sale?

    If this is in the BIOS chip how is it much different from other BIOS/firmware level malwares that we've had for ages? Those run before the OS and have (seemingly) the same capabilities as described in the article. I feel like I'm not getting what this researcher is saying.
    Reply
  • bit_user
    jp7189 said:
    I'm thinking of CPUs on the secondary market and how this would affect; could they be precompromised at time of sale?
    The information in prior articles on this subject assured us that the microcode inside the CPU is immutable.

    jp7189 said:
    I feel like I'm not getting what this researcher is saying.
    The CPU's microcode can alter the way its instruction decoders interpret the instruction opcodes it executes. So, he probably devised some clever way to use this phenomenon to enable the malware package on disk to evade detection.

    It's perhaps not inconceivable that a highly-targeted malware can avoid having any external footprint, aside from the hacked UEFI package which loads it in. But, microcode has limitations and so it would have to be an attack intended to modify something a very specific program does, which opens it up to external attacks.
    Reply
  • adamXpeter
    We hope he open sourced his work to support real science
    Reply
  • Krieger-San
    Rule number one if you require a secure device: Wipe everything, including the UEFI firmwares, and overwrite them with newer or same versions.

    Same with your hard drives - empty space can also contain viruses (Re: Volume Shadows, Snapshots, etc.); wipe the whole drive, not just a 'quick format'.

    Rule number two: Hire a security expert. Nothing is worse than a false sense of security.
    Reply