A Wiper Disguised as Ransomware
Some malware is designed to make money. Some is designed to make a mess. MBRLocker — the sample that surfaced in April 2020 via the WildSky threat group — straddles both categories in a way that makes it equal parts disturbing and absurd.
Here's what happened: a freshly infected machine wouldn't boot Windows. Instead of the login screen, users got a black screen with white text demanding they contact two specific security researchers for decryption. Specifically: @VitaliKKremez, then head of threat intelligence at Everest, and @MalwareHeroTW, one of the MalwareHunterTeam co-founders. Their names, their Twitter handles, their reputations — plastered across the boot screen of a total stranger's laptop.
The researchers had nothing to do with it. No connection to the malware. No involvement in the distribution. They were props in a troll's theater.
This was a wiper. Not ransomware. No encryption happened. No key existed to unlock anything. The malware's sole job was to overwrite the Master Boot Record (MBR) and the Partition Boot Record (PBR) — the first tracks on the drive that tell the BIOS how to find Windows. Wipe those, and the system can't boot. Period.
Why Call It Ransomware?
The MBRLocker label has stuck since 2013, when the first variants appeared. They earned it honestly: they demanded payment, faked a countdown timer, and gave you a keychord (CTRL+ALT+ESC) that sometimes brought back the original MBR. Technically it was a wiper — no real encryption, no real key — but the extortion theater gave victims a reason to pay.
The 2020 variant drops the pretense of profit entirely. The "ransom note" on the boot screen reads:
"You are infected with Everest ransomware (MVRT) created by @VitaliKKremez and @MalwareHeroTW. To decrypt your files, you need to contact @VitaliKKremez or @MalwareHeroTW."
No payment instruction. No bitcoin address. No deadline. Just a public accusation directed at two people who'd never seen the victim's machine.
That's not ransomware. That's not even a prank in any way that's actually funny. It's reputation warfare aimed at researchers, funded by destruction at a stranger's expense.
The Technical Damage
Malwarebytes reverse-engineered the binary and published their analysis on their "CyberSec IT" YouTube channel. The malware targets both the MBR and the PBR, effectively destroying the disk's boot layout.
Here's the critical distinction most coverage misses: data files on the drive aren't touched. The wiper doesn't scramble your documents, photos, or databases. It destroys the pointer table that tells Windows where to find them. The data is still there. But without the partition table or a backup of it, the system is effectively blind to its own contents.
Recovery depends on what survived:
- MBR-based systems: Use
bootrec /fixmbrandbootrec /fixbootfrom a recovery console to rewrite the boot record. TestDisk can scan for and reconstruct lost partition tables. If the data area wasn't overwritten, PhotoRec can carve files by signature. - GPT-based systems: The backup GPT header at the end of the disk survives if the malware didn't explicitly overwrite it. Tools like
gdiskcan restore the primary partition table from that backup copy.
The recovery path exists. It's just that very few end users know these tools exist, let alone how to run them from a command prompt while their machine displays a false accusation on screen.
The Attribution Problem
What makes this story worth revisiting in the context of AI cybersecurity threats isn't the wiper itself, destructive primitives like this have been cheap since the mid-2010s. It's the impersonation angle.
The malware used real names. Real handles. Real reputations. It weaponized trust in security researchers by making them the face of a crime they didn't commit. And crucially, the researchers had no way to stop it, no way to warn every single victim, and no way to control who believed the accusation.
Fast-forward to the threat landscape we navigate today. Attribution attacks have matured considerably since 2020. The techniques that once required writing a custom boot sector are now available through far more sophisticated tooling:
- Deepfake audio and video can impersonate executives or security personnel to authorize fraudulent actions.
- AI-generated phishing can mimic an individual's writing style so precisely that recipients have no heuristic left to catch them.
- Automated credential-stuffing and identity spoofing scale beyond anything the 2020 MBRLocker author could have manually orchestrated.
The underlying principle is identical: hijack someone else's identity to either extract compliance or destroy credibility. MBRLocker was a crude prototype of a concept that's now industrialized, the same class of attack that tells your finance team "this payment instruction came from the CFO." The medium changes. The lie doesn't.
It has also moved inside the enterprise perimeter. As organizations roll out autonomous tooling, impersonation and identity abuse now target the defenders' own infrastructure; our analysis of how security software gets subverted into high-privilege weapons shows the same trust-weaponization pattern playing out against EDR and agent platforms.
Distribution and the Human Factor
MBRLocker has historically spread through the most unremarkable vector imaginable: cracked software downloads. If you're downloading a pirated Photoshop keygen at 2 AM from a forum that has a countdown timer before the download link appears, you're the target demographic. Not because you're careless, because the threat model for those sites has always been "you will get malware, the only question is which kind."
That's not victim-blaming. It's an observation about where the blast radius concentrates. The people most likely to encounter MBRLocker are also the people least likely to have endpoint protection, least likely to have a backup strategy, and most likely to panic when a black screen with white text appears at boot. Modern campaigns have compressed that reaction window even further, our breakdown of ransomware lockouts achieved in under 24 hours shows how little time victims get once an attacker gains a foothold.
SentinelOne's analysis confirmed the malware's distribution via those same cracked-software pipelines. Their recommendation, block download sites offering cracked commercial software, and ensure endpoint protection catches known wiper families, is sound but incomplete. It doesn't address the attribution problem. It doesn't stop a variant from appearing tomorrow that blames a different researcher, or a different vendor, or a different organization.
What Defenders Actually Learned
The 2020 incident was a low-tech event. A custom MBR, a hardcoded string, a social media handle embedded in plaintext. No zero-days. No sophisticated evasion. It succeeded because it was easy to build and hard to recover from if you were an untrained end user.
Three lessons that still apply:
Back up the partition table, not just files. Most backup strategies cover user data. Almost none cover the MBR/PBR metadata. Tools like dd on Linux or mbrbak on Windows can snapshot the first 512 bytes of a disk in seconds. That 512-byte file turns a full system rebuild into a two-minute restore.
Have a boot recovery plan. bootrec /fixmbr, bootrec /fixboot, and TestDisk exist. Write down where the Windows recovery media lives before you need it. TestDisk and PhotoRec are free, portable, and don't require a bootable OS to run. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) maintains general cybersecurity best practices for backup and recovery that, while written for organizations, map cleanly to this scenario.
Researchers need a response plan for impersonation. This one is more 2026 than 2020. When malware or a disinformation campaign publicly attributes an attack to you by name, you need a pre-positioned public statement template, a legal pathway for takedown requests, and a way to reach affected platforms before the accusation spreads. The speed of the attack surface, social media, boot-screen messages, SMS, means the reputation damage is done within hours.
The Prank Framing
SentinelOne's original blog post used the phrase "destructive pranks" in its title, and some reporting leaned into that. The author of MBRLocker called it a prank.
It wasn't a prank. Pranks require consent from the target audience. The victims here had no choice in the matter, lost access to their systems through no fault of their own, and in many cases lost data permanently because they had no backup. The researchers targeted by the false attribution faced reputational damage they couldn't control.
Calling it a prank centers the perpetrator's amusement over everyone else's losses. That framing matters because it normalizes the act. In 2026, we see the same linguistic pattern everywhere, "it's just a joke" accounts for AI-generated impersonations, "it's a prank" for data destruction, "just messing with you" for harassment campaigns. The label is always a tool of minimization.
The underlying behavior, destroy value in someone else's environment, then hide behind humor to avoid accountability, is what separates a prank from an attack. MBRLocker was an attack.
Looking Forward
Wiper malware doesn't require state resources to build. That's been true since the 2010s, when tools like Shamoon and NotPetya proved that destruction could be cheap. MBRLocker's 2020 variant proved it could be cheap and petty.
As AI tooling makes it easier to generate convincing impersonations, of people, of organizations, of security vendors, the response has to be both technical and social. Verify identity through trusted channels. Keep offline backups. Separate attribution claims from evidence. And when someone says "it's just a prank," ask who paid the price.
