Thanks to Nemes Sándor and Anand Ajjan of SophosLabs for their behind-the-scenes work on this article.
Here’s a ransomware story with a difference.
Petya is modern-day malware that locks you out of your data, much like TeslaCrypt or Locky, but does it the hard way.
This malware family (detected and blocked by Sophos products as Troj/Petya-*) uses low-level programming tricks that went out of vogue nearly two decades ago.
Instead of scrambling your data files and leaving the rest of your computer running just fine, Petya leaves all your data intact, but scrambles the indexes on your disk so that Windows can no longer make sense of it.
In other words, the individual disk sectors that contain your programs and files are left untouched, but the so-called metadata that Windows uses to turn your raw data into useful information is wiped out.
That’s a bit like opening up a filing cabinet, taking out all the carefully-arranged papers from every folder in every drawer, unstapling every document, removing any bulldog clips or paper clips that are there to keep some sort of internal order…
…and then throwing the whole lot high in the air to land in a jumbled up mess.
Everything is there, but it’s not much use: you might be able to re-organise it, but it wouldn’t be a quick or a cheap job.
In common with most encrypting ransomware, Petya then offers to sell you an unscrambling key that will pick up all the papers, sort them into order, replace the staples and clips, put them in the right folders, and file them neatly back in their proper places.
What happens?
Petya arrives as an innocent-looking Windows program that you are forced, tricked or talked into running.
The malware then takes advantage of its good fortune, and:
- Pops up a User Account Control (UAC) security prompt that it hopes you will authorise. (Sufficiently many legitimate programs do this that it is understandable, if undesirable, for you to click [OK].)
- Generates a one-time encryption key of 16 bytes, together with a human-readable “personal decryption code” that the crooks use to identify you later.
- Uses its privileges to write data-scrambling code and the encryption key into the Master Boot Record (MBR) and other disk sectors that lie outside the area allocated to your C: drive.
- Reboots your computer.
The MBR is the very first sector on your hard disk, and on older computers, it’s the first thing (after the so-called BIOS firmware) that runs during startup.
That happens not only before Windows loads, but also while your computer is still running in what we’ll call “1980s-mode.”
The security features built into the processor itself, such as memory protection and privilege levels, aren’t activated yet.
Those hardware features are what Windows and other modern operating systems rely on to keep programs apart and to stop unauthorised access to critical system resources such as the hard disk itself.
In fact, even on a multi-core 64-bit CPU with gigabytes of RAM, a computer booting from the MBR is running in the same open-for-anyone-to-do-anything 16-bit mode that MS-DOS did 30 years ago, with just 1MB of RAM directly accessible.
Unfortunately, even just a few hundred bytes of code and RAM is more than enough to implement as-good-as-uncrackable encryption, and to scramble vital parts of the as-yet-unprotected hard disk.
Once Petya has encrypted your disk indexes, it rewrites its own data to wipe out the encryption key it just used, so you can’t simply reboot to unscramble the disk.
Petya uses a strong encryption algorithm called Salsa20 – strong enough that it won a global competition as the code of choice to replace the cipher known as RC4, which was found in the early 2000s to have irremediable cryptographic flaws and should no longer be used.
Petya’s sneaky trick, which greatly simplifies its implementation, is that is doesn’t bother trying to make sense of the directories and files on your Windows C: drive.
Instead, it simply scrambles the Master File Table (MFT) of your C: drive, which is the central index of what goes where in a Windows disk.
The MFT is much easier for low-level code like a boot sector to find than other files, by design.
That’s because the MFT is the core data needed to make sense of the rest of the disk, in much the same way that a technical paper usually has an abstract on the first page to help you get started.
Unfortunately, without the MFT, the rest of your data is not much more useful than a pile of digital shredded cabbage – so much so that Windows helpfully keeps a second copy of the MFT, but that’s easy to find, too.
Faster, leaner, meaner
The crooks can effectively lock you out of your whole disk by scrambling just a tiny part of it; and they can restore it equally quickly, making for a faster, leaner, meaner flavour of ransomware.
First, you see a fake CHKDSK screen intended to discourage you from pulling the plug until the malware has finished:
Then, in true 1980s malware style, there’s some 80×25 ASCII art:
Press a key, as instructed, and you get the “pay page”:
Petya doesn’t need, and doesn’t have, any programming for network access, because it doesn’t need to call home.
It relies on you doing the network call-home manually, by typing in one of the “dark web” URLs off the screen of your frozen computer, which takes you to a CAPTCHA:
Of course, you need a second computer to get online, but once you do, you’re in the same sort of situation that you would be with file-based ransomware like TeslaCrypt or Locky:
Good and bad news
The good news is that, according to our statistics, you’re unlikely to see this malware.
The bad news is that, just like a lot of 1980s boot sector malware, it’s likely to fail catastrophically by making incorrect assumptions about the layout of your disk .
If you have a recent Windows computer, the hard disk is almost certainly arranged using a system called GPT (short for GUID Partition Table) instead of MBR.
An MBR-based computer has, as its name suggests, a master boot record that contains not only the boot-time code but also the disk partition table; the sectors immediately following the MBR are almost always unused, which is why Petya “borrows” them to store some of its own code.
But a GPT hard disk has an MBR (for backward compatibility purposes) immediately followed by its own partition table: a one-sector header followed by at least 32 sectors of partition data.
Petya overwrites this GPT data, but doesn’t keep a backup of it, assuming instead that the sectors were unused.
If that happens, the malware can’t unscramble your disk.
A dedicated data recovery service might be able to recover some or all your files (or an automated disk repair program might help if you are willing to risk trying and failing), but paying the crooks won’t help in such cases.
What do do?
Although Petya is rather different from the rest of the ransomware we’ve seen in recent years, you can defend against it by following the same advice.
We’ve published an article entitled How to stay protected against ransomware to help you out.
Does having an image of the hard drive with tools such as Macrium, AOMEI or other disk imaging software enable a recovery from such a nasty ransomware?
The answer is, “It depends what sort of disk image.” If you have a sector level copy of the disk that can be used toclone it onto a blank, new drive, then the answer is obviously yes: just wipe your ransomware-ravaged disk and treat it as new 🙂
Of course, even a file-based data backup will help you recover, though you’ll need to reinstall Windows and all your applications to get right back to where you were.
I like Clonezilla. bare metal clones. Any OS, any encryption, just clones it. But it includes other options too.
So, let me get this straight…
Cybercriminals resurrect boot-level malware for MBR-formatted Windows partitions, but when it comes to GPT-formatted Windows partitions, it can’t be decrypted? (FYI, because of my familiarity with UEFI vs. BIOS and Mac vs. Windows booting schemes, I understand the difference between MBR and GPT. After all, GPT had been used since Apple released their first Intel Macs!) Instead, they cause damage to the partition scheme, which can’t be fixed by any tool they can “sell” you, but by free, disk recovery systems?
In a world where more and more PCs switch to UEFI, and with it, GPT-formatted hard drives, is there really any practical reason why they would want to do this? It’s like a malware proof-of-concept with no way for the cybercriminals can make money… unless the unsuspecting victim is using a really old computer! They really made their own profitable scheme inherently unprofitable!! Way to go, cybercriminals!!!!
The criminals will still make the money though as they will have taken your cash before you realise that the key you purchased didn’t work. In effect they are worse than TeslaCrypt and Locky as they cannot guarantee their decryption key will work.
they are no better or worse than the others, they are all equal scum of the Earth.
So how does code running in user-mode, even if it is elevated, manage to get raw access to the disk to overwrite the MBR? Seems like that’s something that only signed and verified system code should be able to do.
And surely if you have UEFI with the secure boot feature turned on, that should stop the computer from booting if the MBR is corrupt? Which would mean you’d never see the messages from the malware.
From Vista on, elevated code can’t write to the raw physical device without getting an exclusive lock first…
…unless the sectors it’s writing to are outside the areas allocated to any active volumes. So you can write over the first few sectors on the disk, until you reach the boot sector of the first volume (usually C:) that’s actually in use.
Apparently the idea is to protect disks that are in use from being changed by an application while they’re also being changed by Windows itself (a dangerous race condition that tends to cause corruption), but not to break programs such as partition editors that rely on changing MBR or GPT metadata while Windows is running.
If you are UEFI-booting then you won’t see the malware messages no matter what, because the malware relies on the flow of execution passing into the MBR, which only happens with a BIOS-plus-MBR style bootstrap.
Thanks – that makes sense.
Hi Paul, If you enabled boot sector write protection / virus protection in the BIOS would this stop this? (Assuming you didn’t click Y at boot to allow it).
Also, if it had managed to scramble the MBR then programs like Recuva should be able to retrieve some of the data files. Would a recovery program work more efficiently if the drive was defragged prior to infection as the data files would be contiguous?
What would happen with SSD’s – would TRIM kick in and start erasing all the data? In which case would it be better to mirror the drive first before attempting to recover it?
Whether BIOS-level write protection would work depends on how it’s implemented. If it’s a firmware-controlled setting that can only be bypassed *during boot*, then yes. If it’s software protection that depends on how you trigger a disk write, then no.
I suspect that NTFS recovery might work better if you defragmented recently, on the assumption that bigger chunks of files are stored next to each other and can thus more reliably be stitched back together.
Defragmentation that may no longer be happening regularly if you’re dealing with an SSD, I would imagine…
Paul,
This threat, and all the other Win problems, make me glad that I run my Win-10 as a Parallels virtual machine on my iMac. Unfortunately, some apps aren’t available for OS-X, but I do keep my Win time to a minimum – and no mail, no browsing, etc using Win.
Every so often I copy the pvm file (some 75 GB) to encrypted external hard drive that’s normally not powered up. So if Win-10 goes down for whatever reason, I can completely restore.
This begs the issue:
If I were an ardent Win user, why not run a Win virtual machine (on my Win host)? Aside from a perhaps-minor speed hit, if the VM gets trashed, it could be restored easily.
Alan
If you run Windows in a VM, your VM is as much at risk from ransomware as your host computer. If your VM gets wiped out, you still need some sort of backup or snapshot to go back to!
And there’s still the issue of malware on the host computer as well as the VM. Roundabouts and swings, I’d say…though making a copy of a complete, unmounted VM file is generally easier and quicker than imaging a full hard disk…
not to mention VOIP kinda sucks over VMs if you need to use it within the VM itself.