{ "id": "ea509fa9-0fce-4691-bcd6-b59808c82114", "created_at": "2026-04-06T00:15:18.892398Z", "updated_at": "2026-04-10T03:36:25.396581Z", "deleted_at": null, "sha1_hash": "cd1b224509674d31ed92f3ed56e2f67feadf7af5", "title": "Petya and Mischa - Ransomware Duet (Part 1) | Malwarebytes Labs", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 795209, "plain_text": "Petya and Mischa - Ransomware Duet (Part 1) | Malwarebytes\r\nLabs\r\nBy hasherezade\r\nPublished: 2016-05-18 · Archived: 2026-04-05 19:16:14 UTC\r\nAfter being defeated about a month ago, Petya comes back with new tricks. Now, not as a single ransomware, but\r\nin a bundle with another malicious payload – Mischa. Both are named after the satellites from the GoldenEye\r\nmovie.\r\nThey deploy attacks on different layers of the system and are used as alternatives. That’s why, we decided to\r\ndedicate more than one post to this phenomenon. Welcome to part one! The main focus of this analysis is Petya\r\n(the Green version).\r\nThe second part (about Mischa) you can read about it here.\r\nUPDATE: Improved version of Green Petya is out. More details given in the new article.\r\nLet’s start with some background information.\r\nThis time authors also deployed a page with information for potential clients of their Ransomware-As-A-Service:\r\nJust like in the case of Chimera, the authors use bitmessage for communication with the new recruits of the\r\ncriminal cooperation:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 1 of 18\n\nAnd post doxing threats, also known from Chimera:\r\nAnalyzed samples\r\n8a241cfcc23dc740e1fadc7f2df3965e – main executable\r\nf7596666d8080922d786f5892dd70742– main executable (from a different campaign)\r\nExecution flow\r\nThe main executable – a dropper protected by a crypter/FUD:\r\nunpack and deploy: Setup.dll\r\ninstall: Petya\r\nalternatively – deploy: Mischa.dll\r\nBehavioral analysis\r\nJust like the previous version, it is distributed via cloud storage and pretends to be a job application:\r\nThe executable is again packed with an icon of a PDF document:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 2 of 18\n\nAfter deploying it, it can drop one of the two payloads – Petya – that works similarly to the previously described\r\nversion, or Mischa – that has features of a typical ransomware. The decision which payload to deploy is based on\r\nprivileges with which the sample runs – that implies accessibility to write to the MBR. If writing there is not\r\npossible, authors decided not to miss the chance of infecting the system and deploy more typical userland attack\r\nwith Mischa.\r\nFrom the point of view of the user – your decision taken on UAC pop-up will result in deploying one out of the\r\ntwo payloads. If you choose “No” – you get Mischa. If you choose “Yes” – you get Petya.\r\nPetya\r\nThe infection process looks exactly the same as in the previous verison of Petya. User Account Control\r\nnotification pops up, and in case the user accepts it, Petya installs itself in the MBR and crashes the system. Stage\r\n2 of the infection also looks almost the same. First it runs the fake CHKDSK, that in reality encrypts the disc.\r\nThen, the user can see the ASCII art with the blinking skull and the ransom note. Only the color theme changed –\r\ninstead of red, we have a black background with green text:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 3 of 18\n\nThis theme is consistent for the full ransomware – the same colors we can find on the page for the victim, and on\r\nthe HTML with the ransom note dropped by Mischa.\r\nPage for the victim:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 4 of 18\n\nInside\r\nThe new version of Petya uses exactly the same bootloader – again it loads 32 sectors starting from the sector 34\r\nto the memory at 0x8000 and then jumps there.\r\nKernel start:\r\nAgain, checking if the data is already encrypted is performed, using a one byte flag that is saved at the beginning\r\nof sector 54. If this flag is unset (the value of first byte is 0), program proceeds to the fake CHKDSK scan.\r\nOtherwise (if the value of the byte is 1), it displays the main green screen.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 5 of 18\n\nThe key used for the encryption is again generated by the dropper and stored in the binary. That’s why if we catch\r\nPetya at Stage 1 – before the fake CHKDSK run and erase it, recovering system is still easy. A live CD to support\r\nStage 1 key recovery has been already released (here).\r\nKey verification\r\nKey verification is performed in the following steps:\r\n1. Input (key) from the user is read.\r\nAccepted charset: 123456789abcdefghijkmnopqrstuvwxABCDEFGHJKLMNPQRSTUVWX – if the\r\ncharacter outside of this charset occurred, it is skipped.\r\nOnly the first 16 bytes are stored\r\n2. Data from sector 55 (512 bytes) is read into memory  // it will be denoted as verification buffer\r\n3. The value stored at physical address 0x6c21 (just before the Tor address) is read into memory. It is an 8\r\nbyte long array, unique for a specific infection. // it will be denoted as nonce\r\n4. The verification buffer is encrypted by Salsa20 with the 16 byte long key and the nonce\r\n5. If, as a result of the applied procedure, verification buffer is fully filled with 0x7 – it means the supplied\r\nkey is correct.\r\nWhat changed in the new Petya?\r\nStoring the Salsa key (stage1)\r\nThis time it the key is saved differently, without scrambling. Probably the authors realized that scrambling does\r\nnot provide them any protection, so they gave up this idea completely:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 6 of 18\n\nLength of Salsa key\r\nIn the Red Petya authors used 16 byte long key – however, they were scrambling it and used it to make a 32 bit\r\nlong key. Now they gave it up and they just use the 16 byte long key as it is. That’s why, instead of functions\r\nexpand32 we will see in the new Petya the function expand16:\r\nSalsa implementation\r\nAlso this time, Salsa20 is used in several places in Petya’s code – for encryption, decryption and key verification.\r\nSee the diagram below:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 7 of 18\n\nWe made a comparison of Salsa implementation fragments, that have been found vulnerable in the previous\r\nimplementation.\r\nsalsa20_rol\r\nSee below the original version of this function – copied from Salsa20 implementation:\r\nstatic uint32_t rotl(uint32_t value, int shift) { return (value \u003c\u003c shift) | (value \u003e\u003e (32 - shift)\r\nCode comparison – old one vs the new one:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 8 of 18\n\nThat’s how it has been implemented in the Red Petya:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 9 of 18\n\nThe old version of this function was taking 2 arguments and it was an almost exact clone of the original function –\r\nthe only difference was that it was using 16 bit variables. Reconstruction of the code:\r\nstatic uint16_t rotl(uint16_t value, int16_t shift) { return (value \u003c\u003c shift) | (value \u003e\u003e (32 - s\r\nAnd the new version – from Green Petya:\r\nThe new version is more complex – it takes 3 arguments and uses calls to additional helper functions. To achieve\r\nthe functionality of shifting a DWORD, two WORD-sized parameters have been used (one representing the lower\r\npart of the DWORD and another representing the higher):\r\nstatic uint16_t rotl(uint16_t value_word1, uint16_t value_word2, int16_t shift) { return (shr(v\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 10 of 18\n\ns20_hash\r\noriginal version: https://github.com/alexwebr/salsa20/blob/master/salsa20.c#L59\r\nCode comparison – old one vs the new one:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 11 of 18\n\nFirst changed fragment corresponds to this part of the original Salsa20 implementation:\r\n for (i = 0; i \u003c 16; ++i) x[i] = z[i] = s20_littleendian(seq + (4 * i));\r\nThat's how it has been implemented in the Red Petya:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 12 of 18\n\nAnd the new version - from the Green Petya:\r\ns20_littleendian also changed, but very slightly - a bit extension has been added:\r\nSecond changed fragment corresponds to this part of the original Salsa20 implementation:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 13 of 18\n\nfor (i = 0; i \u003c 16; ++i) { z[i] += x[i]; s20_rev_littleendian(seq + (4 * i), z[i]); }\r\nThat’s how it has been implemented in the Red Petya:\r\nAnd the new version - from Green Petya:\r\nFull reconstruction and comparison of implementations of this function:\r\nhttps://gist.github.com/hasherezade/f59939f5d20ebdfd36343dfcae66bfa9\r\nNew Petya, new bug\r\nAs we can see, the authors tried to fix the bug of using 16 bit long units where the 32 bit long units were required.\r\nThe new implementation of Salsa looks almost correct... However, due to just one bug, it still needs only 8 valid\r\ncharacters of the key, out of 16!\r\nThe bug lies in invalid implementation of the function s20_littleendian. That's how this function looks in the\r\norigial Salsa20:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 14 of 18\n\nstatic uint32_t s20_littleendian(uint8_t *b) { return b[0] + (b[1] \u003c\u003c 8) + (b[2]\r\nAnd that's how the Petya's version looks:\r\nstatic int16_t s20_littleendian(uint8_t *b) { return b[0] + (b[1] \u003c\u003c 8); }\r\nIn the previous, Red Petya every second character of the key had no importance to the encryption/decryption. The\r\npattern was: c?c?c?c?c?c?c?c? - where the c means a valid character and ? means any random character from the\r\nset.\r\nValid key - hpLehdbjdcVaMDGj (revealed at Stage 1 by Antipetya Live CD)\r\nAccepted key hxLxhxbxdxVxMxGx :\r\nIn the current case, the pattern is a bit different (and more difficult to exploit): cc??cc??cc??cc??. See example\r\nbelow:\r\nValid key - sHbGrSTkpCrhoKRt (revealed at Stage 1 by Antipetya Live CD)\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 15 of 18\n\nAccepted key - sHxxrSxxpCxxoKxx :\r\nVerification buffer\r\nSimilar to the previous version, a verification buffer is used in order to check whether or not the provided key is\r\nvalid. However, values expected in the verification buffer changed.  In the green Petya, a key was passed as valid\r\nif the verification buffer got filled by ASCII character '7' (that is byte 0x37). Now, the byte 0x7 has been used.\r\nChecking characters of the validation buffer:\r\nin red Petya:\r\nin green Petya\r\nStability\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 16 of 18\n\nIn the Red Petya, interrupting the fake CHKDSK caused real problems. Even after having a correct key full disk\r\nwas not decrypted correctly - because Petya didn't check which sectors are encrypted and which are not, and was\r\napplying Salsa again on everything. In the Green edition authors improved it.\r\nYet, some victims of Petya reported to us, that they encountered the situation, where they bought a valid key but\r\nstill the disk wasn't decrypted properly. That's why we recommend making a dump of the full disk as soon as you\r\nnotice that you are infected with Petya (before trying any decryption methods).\r\nFragment of the talk between the victim and the attackers. Till now, user didn't got either his data or his bitcoins\r\nback:\r\nConclusion\r\nThe new Petya comes with significant improvements. The authors realized the weakness and tried to make\r\nappropriate fixes in the code. However, they left another flaw that weakens the encryption. Unfortunately, the\r\nprevious approach, based on genetic algorithm will not work this time - due to the different specifics of the\r\ngenerated output. The remaining solution seems to be only bruteforce of the 8 characters. Further research about\r\nthe possibility of writing a decryptor is in progress.\r\nThe idea of making a bundle of two completely different ransomwares is new and creative.  The group of\r\ncybercriminals who released it seems to do everything in order to gain clients on the black market. Probably the\r\nsame group released other ransomware before: Chimera and Rokku. The main method of distribution used by\r\nthem is via targeted campaigns of malicious e-mails. That's why we recommend to pay more attention on the\r\nreceived attachments and be very cautious. We can expect, that they will come with some new ideas in the future.\r\nAppendix\r\nhttp://www.bleepingcomputer.com/news/security/petya-is-back-and-with-a-friend-named-mischa-ransomware/ -\r\nBleeping Computer about Mischa\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 17 of 18\n\nAbout the previous (red) version of Petya:\r\n/blog/threat-analysis/2016/04/petya-ransomware/\r\nAbout the author\r\nUnpacks malware with as much joy as a kid unpacking candies.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nPage 18 of 18", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://blog.malwarebytes.com/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/" ], "report_names": [ "petya-and-mischa-ransomware-duet-p1" ], "threat_actors": [ { "id": "f88b16bc-df4b-48e7-ae35-f4117240ff24", "created_at": "2022-10-25T15:50:23.556699Z", "updated_at": "2026-04-10T02:00:05.312313Z", "deleted_at": null, "main_name": "Chimera", "aliases": [ "Chimera" ], "source_name": "MITRE:Chimera", "tools": [ "PsExec", "esentutl", "Mimikatz", "Cobalt Strike" ], "source_id": "MITRE", "reports": null }, { "id": "3da47784-d268-47eb-9a0d-ce25fdc605c0", "created_at": "2025-08-07T02:03:24.692797Z", "updated_at": "2026-04-10T02:00:03.72967Z", "deleted_at": null, "main_name": "BRONZE VAPOR", "aliases": [ "Chimera ", "DEV-0039 ", "Thorium ", "Tumbleweed Typhoon " ], "source_name": "Secureworks:BRONZE VAPOR", "tools": [ "Acehash", "CloudDrop", "Cobalt Strike", "Mimikatz", "STOCKPIPE", "Sharphound", "Watercycle" ], "source_id": "Secureworks", "reports": null }, { "id": "873a6c6f-a4d1-49b3-8142-4a147d4288ef", "created_at": "2022-10-25T16:07:23.455744Z", "updated_at": "2026-04-10T02:00:04.61281Z", "deleted_at": null, "main_name": "Chimera", "aliases": [ "Bronze Vapor", "G0114", "Nuclear Taurus", "Operation Skeleton Key", "Red Charon", "THORIUM", "Tumbleweed Typhoon" ], "source_name": "ETDA:Chimera", "tools": [ "Agentemis", "Cobalt Strike", "CobaltStrike", "SkeletonKeyInjector", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434518, "ts_updated_at": 1775792185, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/cd1b224509674d31ed92f3ed56e2f67feadf7af5.pdf", "text": "https://archive.orkl.eu/cd1b224509674d31ed92f3ed56e2f67feadf7af5.txt", "img": "https://archive.orkl.eu/cd1b224509674d31ed92f3ed56e2f67feadf7af5.jpg" } }