{ "id": "9983ab3b-fc1f-43f9-982f-ad2be6bdc20a", "created_at": "2026-04-06T00:10:25.399076Z", "updated_at": "2026-04-10T03:21:29.535918Z", "deleted_at": null, "sha1_hash": "7e3fb3bed0683db4ab2eacefd89aec06fb36571f", "title": "EternalPetya and the lost Salsa20 key | Malwarebytes Labs", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 215428, "plain_text": "EternalPetya and the lost Salsa20 key | Malwarebytes Labs\r\nBy Malwarebytes Labs\r\nPublished: 2017-06-28 · Archived: 2026-04-05 14:18:17 UTC\r\nWe have recently been facing a huge outbreak of a new Petya-like malware armed with an infector similar\r\nto WannaCry. The research is still in progress, and the full report will be published soon.\r\nIn this post, we will focus on some new important aspects of the current malware. The low-level attack works in\r\nthe same style as the first Petya, described here. As before, the beginning of the disk is overwritten by the\r\nmalicious Petya kernel and bootloader. When the malicious kernel is booted, it encrypts the Master File Table with\r\nSalsa20 and in this way, makes the disk inaccessible.\r\nThe code from Petya’s kernel didn’t change much, but the new logic implemented in the high-level part (the\r\nWindows executable) caused the change in the malware’s mission. In the past, after paying the ransom, the Salsa\r\nkey from the victim was restored and with its help, the Petya kernel was able to decrypt the Master File Table.\r\nNow, the necessary key seems to be lost for eternity. Thus, the malware appears to have only damaging intentions.\r\nLet’s have a look at the implementation and discuss the details.\r\nAnalyzed sample:\r\n71b6a493388e7d0b40c83ce903bc6b04 – the main DLL\r\nf3471d609077479891218b0f93a77ceb – the low level part (Petya bootloader + kernel)\r\n[UPDATE]  A small bug in the Salsa20 implementation has been found. Unfortunately, it is not significant\r\nenough to help restoring the key.\r\nHow is the disk encrypted?\r\nThe low level attack affecting the Master File Table hasn’t changed since Goldeneye. It is executed by the Petya\r\nkernel.\r\nThe Salsa20 algorithm that was implemented incorrectly in the early versions of Petya and caused it to be cracked\r\nhas been fixed in version 3 (read more here). Now it looks almost the same as in Goldeneye (that was the 4th step\r\nin the evolution) and it does not seem to have any significant bugs. Thus, once the data is encrypted, having the\r\nvalid key is the only way to restore it.\r\nHere’s a comparison of the changes in the code between the current version and the Goldeneye one.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\r\nPage 1 of 8\n\nLooking inside the code, we can see that the significant changes have been made only to the elements responsible\r\nfor displaying the screen with information.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\r\nPage 2 of 8\n\nAnother subtle, yet interesting change is in the Salsa20 key expansion function. Although the Salsa20 algorithm\r\nitself was not altered, there is one keyword that got changed in comparison to the original version. This is the\r\nfragment of the current sample’s code:\r\nAnd this is a corresponding fragment from Goldeneye:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\r\nPage 3 of 8\n\nInstead of the keyword typical for Salsa20 (“expand32-byte k“) we’ve got something custom: “-1nvald s3ct-id”\r\n(that can be interpreted as: “invalid sector id”). As we confirmed, the change of this keyword does not affect the\r\nstrength of the crypto. However, it may be treated as a message about the real intentions of the attackers.\r\nHow is the Salsa key generated?\r\nGenerating the Salsa key and the nonce, as before, is done by the PE file (in the higher level of the infector),\r\ninside the function that is preparing the stub to be written on the disk beginning.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\r\nPage 4 of 8\n\nIn all versions of Petya, a secure random generator was used. We can find it in the current version as well—it uses\r\nCryptGenRandom.\r\nThe generated Salsa key and nonce are stored in the dedicated sector for further use by the kernel during\r\nencryption.\r\nExample of the stored data:\r\nThe byte at the offset 0x4000 is the flag: 0 means that the disk is not encrypted yet, 1 means encrypted.\r\nFrom the offset 0x4001, the Salsa20 key starts. It is 32 bytes long. After that, at offset 0x4021 there is the random\r\nSalsa20 nonce.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\r\nPage 5 of 8\n\nWhat happens with the Salsa key after the encryption?\r\nAfter being read and used for the encrypting algorithm, the stored Salsa key is erased from the disk. You can see\r\nthe comparison of the disk image before and after the encryption phase.\r\nAs you can see, after use the key is erased.\r\nWhat is the relationship between the victim ID and the Salsa key?\r\nIn the previous versions of Petya, the victim ID was, in fact, the victim’s Salsa20 key, encrypted with the\r\nattacker’s public key and converted to Base58 string. So, although the Salsa key is erased from the disk, a backup\r\nwas still there, accessible only to the attackers, who had the private key to decrypt it.\r\nNow, it is no longer true. The victim ID is generated randomly, BEFORE the random Salsa key is even made. So,\r\nin the current version, the relationship of the Salsa key and the victim ID is none. The victim ID is just trash. You\r\ncan see the process of generating it on the video.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\r\nPage 6 of 8\n\nAfter the reboot from the infected disk, we can confirm that the random string generated before Salsa key and\r\nnonce is the same as the one displayed on the screen as the victim ID (“personal installation key”):\r\nConclusion\r\nAccording to our current knowledge, the malware is intentionally corrupt in a way that the Salsa key was never\r\nmeant to be restored. Nevertheless, it is still effective in making people pay ransom. We have observed that new\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\r\nPage 7 of 8\n\npayments are being made to the bitcoin account. You can see the link to the bitcoin address here:\r\nhttps://blockchain.info/address/1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX\r\nIf you are a victim of this malware and you are thinking about paying the ransom, we warn you: Don’t do this. It\r\nis a scam and you will most probably never get your data back.\r\nWe will keep you posted with the updates about our findings.\r\nAppendix\r\nMicrosoft’s report about the new version of Petya\r\nAbout the original version (Goldeneye):\r\n/blog/threat-analysis/2016/12/goldeneye-ransomware-the-petyamischa-combo-rebranded/\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/2017/06/eternalpetya-lost-salsa20-key/\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/\r\nPage 8 of 8\n\nencryption. Example of the stored data: \nThe byte at the offset 0x4000 is the flag: 0 means that the disk is not encrypted yet, 1 means encrypted.\nFrom the offset 0x4001, the Salsa20 key starts. It is 32 bytes long. After that, at offset 0x4021 there is the random\nSalsa20 nonce. \n Page 5 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/" ], "report_names": [ "eternalpetya-lost-salsa20-key" ], "threat_actors": [], "ts_created_at": 1775434225, "ts_updated_at": 1775791289, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/7e3fb3bed0683db4ab2eacefd89aec06fb36571f.pdf", "text": "https://archive.orkl.eu/7e3fb3bed0683db4ab2eacefd89aec06fb36571f.txt", "img": "https://archive.orkl.eu/7e3fb3bed0683db4ab2eacefd89aec06fb36571f.jpg" } }