{
	"id": "6891a211-db87-4064-bbf0-a0666d33cd3d",
	"created_at": "2026-04-06T00:18:26.726224Z",
	"updated_at": "2026-04-10T03:21:32.800809Z",
	"deleted_at": null,
	"sha1_hash": "f70585d9d0130f09d724008a06007ebe88efb14e",
	"title": "Petya - Taking Ransomware To The Low Level | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1200362,
	"plain_text": "Petya - Taking Ransomware To The Low Level | Malwarebytes\r\nLabs\r\nBy Malwarebytes Labs\r\nPublished: 2016-03-31 · Archived: 2026-04-05 14:13:24 UTC\r\nPetya is different from the other popular ransomware these days. Instead of encrypting files one by one, it denies\r\naccess to the full system by attacking low-level structures on the disk. This ransomware’s authors have not only\r\ncreated their own boot loader but also a tiny kernel, which is 32 sectors long.\r\nPetya’s dropper writes the malicious code at the beginning of the disk. The affected system’s master boot record\r\n(MBR) is overwritten by the custom boot loader that loads a tiny malicious kernel. Then, this kernel proceeds with\r\nfurther encryption. Petya’s ransom note states that it encrypts the full disk, but this is not true. Instead, it encrypts\r\nthe master file table (MFT) so that the file system is not readable.\r\n[UPDATE] READ ABOUT THE LATEST VERSION: GOLDENEYE\r\nPREVENTION TIP: Petya is most dangerous in Stage 2 of the infection, which starts when the affected system is\r\nbeing rebooted after the BSOD caused by the dropper. In order to prevent your computer from going\r\nautomatically to this stage, turn off automatic restart after a system failure (see how to do this).\r\nIf you detect Petya in Stage 1, your data can still be recovered. More information about it is [here] and in this\r\narticle.\r\nUPDATE: 8-th April 2016 Petya at Stage 2 has been cracked by leo-stone. Read more: https://petya-pay-no-ransom.herokuapp.com/ and https://github.com/leo-stone/hack-petya. Tutorial helping in disk recovery is\r\nhere.\r\nAnalyzed samples\r\ndfcced98585128312b62b42a2a250dd2 – zipped package containing the malicious executable\r\naf2379cc4d607a45ac44d62135fb7015 – the main executable\r\n 7899d6090efae964024e11f6586a69ce – Setup.dll\r\nd80fc07cc293bcd36e630d45a34aca11  – a dump of Petya bootloader + kernel\r\nMain executable from another campaign (PDF icon)\r\na92f13f3a1b3b39833d3cc336301b713\r\nSpecial thanks to: Florian Roth – for sharing the samples, Petr Beneš – for a constructive discussion on Twitter.\r\nBehavioral analysis\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 1 of 16\n\nThis ransomware is delivered via scam emails themed as a job application. E-mail comes with a Dropbox link,\r\nwhere the malicious ZIP is hosted. This initial ZIP contains two elements:\r\na photo of a young man, purporting to be an applicant (in fact it is a publicly available stock image)\r\nan executable, pretending to be a CV in a self-extracting archive or in PDF (in fact it is a malicious dropper\r\nin the form of a 32bit PE file):\r\nIn order to execute its harmful features, it needs to run with Administrator privileges. However, it doesn’t even try\r\nto deploy any user account control (UAC) bypass technique. It relies fully on social engineering.\r\nWhen we try to run it, UAC pops up this alert:\r\nAfter deploying the application, the system crashes. When it restarts, we see the following screen, which is an\r\nimitation of a CHKDSK scan:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 2 of 16\n\nIn reality, the malicious kernel is already encrypting. When it finishes, the affected user encounters this blinking\r\nscreen with an ASCII art:\r\nPressing a key leads to the main screen with the ransom note and all information necessary to reach the Web panel\r\nand proceed with the payment:\r\nInfection stages\r\nThis ransomware have two infection stages.\r\nThe first is executed by the dropper (Windows executable file). It overwrites the beginning of the disk (including\r\nMBR) and makes an XOR encrypted backup of the original data. This stage ends with an intentional execution of\r\nBSOD. Saving data at this point is relatively easy, because only the beginning of the attacked disk is overwritten.\r\nThe file system is not destroyed, and we can still mount this disk and use its content. That’s why, if you suspect\r\nthat you have this ransomware, the first thing we recommend is to not reboot the system. Instead, make a disk\r\ndump. Eventually you can, at this stage, mount this disk to another operating system and make the file backup. See\r\nalso: Petya key decoder.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 3 of 16\n\nThe second stage is executed by the fake CHKDSK scan. After this, the file system is destroyed and cannot be\r\nread.\r\nHowever, it is not true that the full disk is encrypted. If we view it by forensic tools, we can see many valid\r\nelements, including strings.\r\nWebsite for the victim\r\nWe noted that the website for the victim is well prepared and very informative. The menu offers several language\r\nversions, but so far only English works:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 4 of 16\n\nIt also provides a step-by-step process on how affected users can recover their data:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 5 of 16\n\nStep1: Enter your personal identifier\r\nStep2: Purchase Bitcoins\r\nStep3: Do a Bitcoin transaction\r\nStep4: Wait for confirmation\r\nWe expect that cybercriminals release as little information about themselves as possible. But in this case, the\r\nauthors and/or distributors are very open, sharing the team name—”Janus Cybercrime Solutions”—and the project\r\nrelease date—12th December 2015. Also, they offer a news feed with updates, including press references about\r\nthem:\r\nIn case of questions or problems, it is also possible to contact them via a Web form.\r\nInside\r\nStage 1\r\nAs we have stated earlier, the first stage of execution is in the Windows executable. It is packed in a good quality\r\nFUD/cryptor that’s why we cannot see the malicious code at first. Executions starts in a layer that is harmless and\r\nused only for the purpose of deception and protecting the payload. The real malicious functionality is inside the\r\npayload dynamically unpacked to the memory.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 6 of 16\n\nBelow you can see the memory of the running process. The code belonging to the original EXE is marked red.\r\nThe unpacked malicious code is marked blue:\r\nThe unpacked content is another PE file:\r\nHowever, if we try to dump it, we don’t get a valid executable. Its data directories are destroyed. The PE file have\r\nbeen processed by the cryptor in order to be loaded in a continuous space, not divided by sections. It lost the\r\nability to run independently, without being loaded by the cryptor’s stub. Addresses saved as RVA are in reality raw\r\naddresses.\r\nI have remapped them using a custom tool, and it revealed more information, i.e. the name of this PE file is\r\nSetup.dll:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 7 of 16\n\nUPDATE: if we catch the process of unpacking in correct moment, we can dump the DLL before it is destroyed.\r\nThe resulting payload is: 7899d6090efae964024e11f6586a69ce\r\nAs the name suggest, the role of the payload is to setup everything for the next stage. First, it generates a unique\r\nkey that will be used for further encryption. This key must be also known to attackers. That’s why it is encrypted\r\nby ECC and displayed to the victim as a personal identifier, that must be send to attackers via personalized page.\r\nRandom values are retrieved by Windows Crypto API function: CryptGenRandom. Below, it gets 128 random\r\nbytes:\r\nMaking of onion addresses:\r\nRetrieving parameters of the disk using DeviceIoControl\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 8 of 16\n\nRead/write to the disk:\r\nAfter overwriting the beginning of the disk, it intentionally crashes the system, using an undocumented function\r\nNtRaiseHardError:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 9 of 16\n\nAt this point, first stage of changes on the disk have been already made. Below you can see the MBR overwritten\r\nby the Petya’s boot loader:\r\nNext few sectors contains backup of original data XORed with ‘7’. After that we can find the copied Petya code\r\n(starting at 0x4400 – sector 34).\r\nWe can also see the strings that are displayed in the ransom note, copied to the the disk:\r\nStage 2\r\nStage 2 is inside the code written to the disk’s beginning. This code uses 16 bit architecture.\r\nExecution starts with a boot loader, that loads into memory the tiny malicious kernel. Below we can see execution\r\nof the loading function. Kernel starts at sector 34 and it is 32 sectors long (including saved data):\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 10 of 16\n\nBeginning of the kernel:\r\nChecking if the data is already encrypted is performed using one byte flag that is saved at the beginning of sector\r\n54. If this flag is unset, program proceeds to the fake CHKDSK scan. Otherwise, it displays the main red screen.\r\nThe fake CHKDSK encrypts MFT using Salsa20 algorithm. The used key is 32 byte long, read from the address\r\n0x6C01. After that, the key gets erased.\r\nSalsa20 is used in several places in Petya’s code – for encryption, decryption and key verification. See the\r\ndiagram below:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 11 of 16\n\nInside the same function that displays the red screen, the Key checking routine is called. First, user is prompted to\r\nsupply the key. The maximal input length is 73 bytes, the minimal is 16 bytes.\r\nDebugging\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 12 of 16\n\nOf course, we cannot debug this stage of Petya via typical userland debuggers that are the casual tools in\r\nanalyzing malware. We need to go to the low level. The simplest way (in my opinion) is to use Bochs internal\r\ndebugger. We need to make a full dump of the infected disk. Then, we can load it under Bochs.\r\nI used the following Bochs configuration (‘infected.dsk’ is my disk dump): bochsrc.txt\r\nThis is how it looks running under Bochs:\r\nKey verification\r\nKey verification is performed in the following steps:\r\n1. Input from the user is read.\r\nAccepted\r\ncharset: 123456789abcdefghijkmnopqrstuvwxABCDEFGHJKLMNPQRSTUVWX – if\r\nthe character outside of this charset occurred, it is skipped.\r\nOnly first 16 bytes are stored\r\n2. The supplied key is encoded by a custom algorithm. Encoded key is 32 bytes long.\r\n3. Data from sector 55 (512 bytes) is read into memory  // it will be denoted as verification\r\nbuffer\r\n4. The value stored at physical address 0x6c21 (just before the Tor address) is read into\r\nmemory. It is an 8 byte long array, unique for a specific infection. // it will be denoted as\r\nnonce\r\n5. The verification buffer is encrypted by 256 bit\r\nIf, as the result of applied procedure, verification buffer is fully filled with ‘7’ – it means the supplied key is\r\ncorrect.\r\nExample: encoded key versus supplied key:”\u003e\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 13 of 16\n\n[/CGATAGCLOSE\u003e\r\nThe algorithm for encoding the supplied key is very simple:\r\nhttps://gist.github.com/hasherezade/785f7da52dfd91fe9e59ae283df2e898\r\nValid key is important for the process of decryption. If we supply a bogus key and try to pass it as valid by\r\nmodifying jump conditions, Petya will recover the original MBR but other data will not be decrypted properly and\r\nthe operating system will not run.\r\nWhen the key passed the check, Petya shows the message “Decrypting sectors” with a progress.\r\nAfter it finishes, it asks to reboot the computer. Below is Petya’s last screen, showing that user finally got rid of\r\nthis ransomware:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 14 of 16\n\nConclusion\r\nIn terms of architecture, Petya is very advanced and atypical. Good quality FUD, well obfuscated dropper – and\r\nthe heart of the ransomware – a little kernel – depicts that authors are highly skilled. However, the chosen low-level architecture enforced some limitations, i.e.: small size of code and inability to use API calls. It makes\r\ncryptography difficult. That’s why the key was generated by the higher layer – the windows executable. This\r\nsolution works well, but introduces a weakness that allowed to restore the key (if we manage to catch Petya at\r\nStage 1, before the key is erased). Moreover, authors tried to use a ready made Salsa20 implementation and make\r\nslight changes in order to adopt it to 16-bit architecture. But they didn’t realized, that changing size of variables\r\ntriggers serious vulnerabilities (detailed description you can find in CheckPoint’s article).\r\nMost of the ransomware authors take care of the user experience, so that even a non technical person will have\r\neasy way to make a payment. In this case, user experience is very bad. First – denying access to the full system is\r\nnot only harmful to a user, but also for the ransomware distributor, because it makes much harder for the victim to\r\npay the ransom. Second – the individual identificator is very long and it cannot be copied from the screen. Typing\r\nit without mistake is almost impossible.\r\nOverall, authors of Petya ransomware wrote a good quality code, that, however – missed the goals. Ransomware\r\nrunning in userland can be equally or more dangerous.\r\nAppendix\r\nAbout Petya by other vendors:\r\nhttps://blog.gdatasoftware.com/2016/03/28213-ransomware-petya-encrypts-hard-drives – first article about\r\nPetya ransomware (by GData)\r\nhttps://blog.gdatasoftware.com/2016/03/28226-ransomware-petya-a-technical-review – technical analysis\r\nby GData\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 15 of 16\n\nhttp://blog.trendmicro.com/trendlabs-security-intelligence/petya-crypto-ransomware-overwrites-mbr-lock-users-computers/\r\nhttp://www.bleepingcomputer.com/news/security/petya-ransomware-skips-the-files-and-encrypts-your-hard-drive-instead/\r\nRead also:\r\nhttp://www.invoke-ir.com/2015/05/ontheforensictrail-part2.html – Master Boot Record\r\nhttp://sysforensics.org/2012/06/mbr-malware-analysis/ – MBR malware analysis\r\nhttps://socprime.com/en/blog/dismantling-killdisk-reverse-of-the-blackenergy-destructive-component/ –\r\nDismantling KillDisk: reverse of the BlackEnergy destructive component (another malware attacking hard\r\ndisk)\r\nThis was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest\r\nin InfoSec. She loves going in details about malware and sharing threat information with the community. Check\r\nher out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2016/04/petya-ransomware/"
	],
	"report_names": [
		"petya-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434706,
	"ts_updated_at": 1775791292,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f70585d9d0130f09d724008a06007ebe88efb14e.pdf",
		"text": "https://archive.orkl.eu/f70585d9d0130f09d724008a06007ebe88efb14e.txt",
		"img": "https://archive.orkl.eu/f70585d9d0130f09d724008a06007ebe88efb14e.jpg"
	}
}