{
	"id": "e1e0a423-9d21-4fff-a652-f3a7d00957ed",
	"created_at": "2026-04-06T00:18:06.942345Z",
	"updated_at": "2026-04-10T03:29:24.028041Z",
	"deleted_at": null,
	"sha1_hash": "e32715ee8ed5733487a4282d086fd8b939c5b4c9",
	"title": "EternalPetya - yet another stolen piece in the package? | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 306062,
	"plain_text": "EternalPetya - yet another stolen piece in the package? |\r\nMalwarebytes Labs\r\nBy Malwarebytes Labs\r\nPublished: 2017-06-29 · Archived: 2026-04-05 16:37:49 UTC\r\nSince June 27th we have been investigating the outbreak of the new Petya-like malware armed with an infector\r\nsimilar to WannaCry. Since day one, various contradicting theories started popping up. Some believed that this\r\nmalware is a rip-off of the original Petya, while others think that it is another step in Petya’s evolution. However,\r\nthose were just different opinions and none of them were backed up with enough evidence to hold solid. In this\r\npost, we will try to fill this gap by making step-by-step comparisons of the current kernel and the one on which it\r\nis based (Goldeneye Petya).\r\nAnalyzed sample:\r\n71b6a493388e7d0b40c83ce903bc6b04 – the main DLL\r\nf3471d609077479891218b0f93a77ceb – the low level part (Petya bootloader + kernel) \u003c- the main\r\nfocus of this analysis\r\nWhy is it important to know whether or not the code was recompiled?\r\nAnswering this question and collecting enough evidence is crucial for further discussions on attribution. The\r\nsource code of the original Petya has never been leaked publicly, so in case it was recompiled it proves that the\r\noriginal Petya’s author, Janus, is somehow linked to the current outbreak (either this is his work or he has sold the\r\ncode to another actor).\r\nIn this analysis, we hope to identify if this malware could have been recompiled from the original code, or it’s just\r\na work of anyone with the appropriate skills to modify the ready-made binary. Doing so would not entirely\r\ndisprove Janus as the creator, but his involvement becomes less likely.\r\nAnyways, let’s take a look at the code.\r\nSectors\r\nLooking at the sectors, we can find that the layout of EternalPetya is identical to Goldeneye. Full comparison:\r\nPetya kernel:\r\nPetya Goldeneye: sector 1\r\nPetya Eternal: sector 1\r\nData sector:\r\nPetya Goldeneye: 32\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 1 of 13\n\nPetya Eternal: 32\r\nVerification sector:\r\nPetya Goldeneye: 33\r\nPetya Eternal: 33\r\nOriginal MBR (xored with 7)\r\nPetya Goldeneye: 34\r\nPetya Eternal: 34\r\nHexadecimal comparison\r\nComparing both kernels at hexadecimal level, we can see tiny differences at various points. However, there are big\r\nportions of code that are identical in both.\r\nThe screenshots below show fragments of the (current) EternalPetya on the left, and Goldeneye on the right.\r\nIts interesting that, at some point, the layout of the same strings in the memory was shifted:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 2 of 13\n\nAs mentioned, the data sector starts in both cases at the same offset. This sector stores the random Salsa20 key and\r\nnonce, which are generated per victim, and this is identical in both cases. However, in Goldeneye the victim ID is\r\nmuch longer, which is not surprising taking into the account the fact that in the past it was supposed to be the\r\nencrypted backup of the Salsa key, and now it is just an arbitrary string, so it’s length doesn’t really matter.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 3 of 13\n\nThe Bootloader\r\nThe first thing that struck me as different was the bootloader. Fragment of the hexdump (as before: EternalPetya\r\non the left, and Goldeneye on the right.):\r\nFunctionality-wise, it is the same in both cases. It is supposed to read 32 (0x20) sectors from the disk, starting\r\nfrom sector 1, and load them into memory at the address 0x8000. However, the opcodes that are used in both cases\r\nto do the same operations are a bit different.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 4 of 13\n\nThis is the old bootloader, used in Goldeneye:\r\nAnd this is the bootloader used in the EternalPetya version:\r\nMy first impression upon seeing this was that the code was recompiled with different settings, however, another\r\npossibility also exists. The total length of the different fragments are the same – so, we cannot exclude the\r\npossibility that someone manually edited them inside the pre-compiled binary.\r\nOptimizations – and why it matters\r\nSo far we’ve seen some interesting changes, but they were not enough to prove or disprove whether the code was\r\nrecompiled. However, the breakthrough in the research may lie in the interesting observation made by David\r\nBuchanan.\r\nHis theory was based on compiler optimization, which ensures that the same character will not need to be loaded\r\ninto memory twice. We can see this rule applied in examining the code responsible for storing a string in the\r\nmemory. Inside of Goldeneye’s key expansion function, we can find that this kind of optimization absolutely\r\nhappens – every character is unique, no character is loaded twice:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 5 of 13\n\nBut in the corresponding fragment of the current kernel, we can find that this rule is broken. The character ‘d’\r\nrepeats and optimization was not applied:\r\nIf the same code was generated by a compiler, this fragment would look identical to other repeated characters:\r\nmov al, 'd' mov [bp+var_B], al mov [bp+var_3], al\r\nThis is a very strong argument against the theory of the code being recompiled. But anyway, let’s continue the\r\nanalysis and see if we can find even more evidence.\r\nCloser look at the changes\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 6 of 13\n\nIn a previous post I presented a fast comparison of the current kernel vs Goldeneye, done with the help of IDA\r\nplugin, BinDiff:\r\nWe can see that significant modifications have been made only in the functions related to displaying the\r\ninformation screen. Let’s check how exactly these changes have been applied.\r\nmain_info_screen (offset 0x8426):\r\nChanges of the main_info_screen pointed out by the BinDiff (left: current, right: Goldeneye):\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 7 of 13\n\nAs we can see, the call to a function at 0x008848E was replaced with NOPs (No Operation). This is a common\r\npractice used to remove an unwanted function in case of patching compiled binaries. Yet, sometimes it can be also\r\nintroduced by #Ifdefs. The rest of the code matches the previous version, even using the same offsets. However,\r\nthe addresses to the displayed strings are different in both binaries.\r\nThe unreferenced function is still present in the current binary:\r\n…and called in some other places of code:\r\nComparison to the Goldeneye’s call graph, it lacks one of the references, but the other ones are consistent:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 8 of 13\n\nsub_86E0 (offset 0x86E0):\r\nThe second change is in another function, that is also a part of the information screen. It is not referenced from\r\nany other place in the code:\r\nAs we can see, it is called at the beginning of the previously discussed function:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 9 of 13\n\nIn the Goldeneye kernel, the corresponding function was the one responsible for printing the skull:\r\nThe first jump leads to the loop responsible for displaying the skull and waiting for the key to be pressed by the\r\nuser. Fragment of the code:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 10 of 13\n\nLooking inside the EternalPetya code, we are almost sure that this function was patched post-compilation, rather\r\nthan recompiled. The first jump, that was supposed to lead to the loop leads directly to the function end:\r\nThe original code is still in the binary, but it is never referenced (dead code).\r\nAre the patches reversible?\r\nI thought as a finishing touch of this research it would be interesting to reverse the changes and bring the dead\r\ncode back to life. As an input, I used the dumped code of:\r\nEternalPetya kernel + bootloader (f3471d609077479891218b0f93a77ceb).\r\nMy version (reverse patch): (7957520271edf003742db63fc250c231).\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 11 of 13\n\nIndeed, after applying the patches, we are back to seeing the same blinking screen, only the skull is gone (the\r\ncorresponding strings has been overwritten):\r\nConclusions\r\nI think the presented evidence is enough to prove, that the code was not recompiled from the original source (in\r\ncontrary to what I initially suspected). Thus, the involvement of the original Petya author, Janus, seems unlikely. It\r\nseems in this case he was just chosen as a scapegoat by some different actor.\r\nThe edits made in the code are well crafted – the person doing them was fluent in assembly and knew\r\nexactly what to change and why. Thus, it gave the first impression of very neat and clean modifications, that could\r\npossibly be a result of code recompilation. Yet, after doing a deeper analysis, we have identified numerous\r\nnuances that show otherwise.\r\nEternalPetya seems to be a patchwork made of code stolen from various sources. In addition to the modified\r\nversion of the GoldenEye Petya kernel, we can find the leaked NSA exploits from the “Eternal” series as well as\r\nlegitimate applications, such as PsExec.\r\nIt is common practice among unsophisticated actors (script-kiddies) to steal and repurpose someone else’s code.\r\nHowever, in this case, the composition was done well by a person or team with good technical knowledge and\r\ncareful execution. A possible reason for using so many stolen elements, apart from saving actor’s time, could have\r\nbeen to throw off any obvious signs of attribution.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 12 of 13\n\nThere are still many mysteries to solve about this malware which creates many theories that, until proven true, are\r\nnothing more than speculation.\r\nAppendix\r\nRead also:\r\n/blog/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\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.wordp\r\nSource: https://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen-piece-package/"
	],
	"report_names": [
		"eternalpetya-yet-another-stolen-piece-package"
	],
	"threat_actors": [
		{
			"id": "bbf66d2d-3d20-4026-a2b5-56b31eb65de4",
			"created_at": "2025-08-07T02:03:25.123407Z",
			"updated_at": "2026-04-10T02:00:03.668131Z",
			"deleted_at": null,
			"main_name": "ZINC EMERSON",
			"aliases": [
				"Confucius ",
				"Dropping Elephant ",
				"EHDevel ",
				"Manul ",
				"Monsoon ",
				"Operation Hangover ",
				"Patchwork ",
				"TG-4410 ",
				"Viceroy Tiger "
			],
			"source_name": "Secureworks:ZINC EMERSON",
			"tools": [
				"Enlighten Infostealer",
				"Hanove",
				"Mac OS X KitM Spyware",
				"Proyecto2",
				"YTY Backdoor"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "7ea1e0de-53b9-4059-802f-485884180701",
			"created_at": "2022-10-25T16:07:24.04846Z",
			"updated_at": "2026-04-10T02:00:04.84985Z",
			"deleted_at": null,
			"main_name": "Patchwork",
			"aliases": [
				"APT-C-09",
				"ATK 11",
				"Capricorn Organisation",
				"Chinastrats",
				"Dropping Elephant",
				"G0040",
				"Maha Grass",
				"Quilted Tiger",
				"TG-4410",
				"Thirsty Gemini",
				"Zinc Emerson"
			],
			"source_name": "ETDA:Patchwork",
			"tools": [
				"AndroRAT",
				"Artra Downloader",
				"ArtraDownloader",
				"AutoIt backdoor",
				"BADNEWS",
				"BIRDDOG",
				"Bahamut",
				"Bozok",
				"Bozok RAT",
				"Brute Ratel",
				"Brute Ratel C4",
				"CinaRAT",
				"Crypta",
				"ForeIT",
				"JakyllHyde",
				"Loki",
				"Loki.Rat",
				"LokiBot",
				"LokiPWS",
				"NDiskMonitor",
				"Nadrac",
				"PGoShell",
				"PowerSploit",
				"PubFantacy",
				"Quasar RAT",
				"QuasarRAT",
				"Ragnatela",
				"Ragnatela RAT",
				"SocksBot",
				"TINYTYPHON",
				"Unknown Logger",
				"WSCSPL",
				"Yggdrasil"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "c81067e0-9dcb-4e3f-abb0-80126519c5b6",
			"created_at": "2022-10-25T15:50:23.285448Z",
			"updated_at": "2026-04-10T02:00:05.282202Z",
			"deleted_at": null,
			"main_name": "Patchwork",
			"aliases": [
				"Hangover Group",
				"Dropping Elephant",
				"Chinastrats",
				"Operation Hangover"
			],
			"source_name": "MITRE:Patchwork",
			"tools": [
				"NDiskMonitor",
				"QuasarRAT",
				"BackConfig",
				"TINYTYPHON",
				"AutoIt backdoor",
				"PowerSploit",
				"BADNEWS",
				"Unknown Logger"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434686,
	"ts_updated_at": 1775791764,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e32715ee8ed5733487a4282d086fd8b939c5b4c9.pdf",
		"text": "https://archive.orkl.eu/e32715ee8ed5733487a4282d086fd8b939c5b4c9.txt",
		"img": "https://archive.orkl.eu/e32715ee8ed5733487a4282d086fd8b939c5b4c9.jpg"
	}
}