{ "id": "623511e3-ef80-4a4e-a519-7bc8e3227a67", "created_at": "2026-04-06T01:31:23.349775Z", "updated_at": "2026-04-10T13:12:00.183629Z", "deleted_at": null, "sha1_hash": "dccedf66ab80baaca8f3b1723a14f07b101b9bf1", "title": "Petya and Mischa: ransomware duet (part 2)", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 824316, "plain_text": "Petya and Mischa: ransomware duet (part 2)\r\nBy hasherezade\r\nPublished: 2016-06-09 · Archived: 2026-04-06 00:57:43 UTC\r\nAfter being defeated in April, Petya comes back with new tricks. Now, not as a single ransomware, but in a bundle\r\nwith another malicious payload – Mischa. Both are named after the satellites from the GoldenEye movie.\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 two! The main focus of this analysis is\r\nMischa and Setup.dll (the malicious installer that chooses which payload to deploy).\r\nThe first part (about Green Petya) you can read about it here.\r\nUPDATE: Improved version of Green Petya is out. More details given in the new article.\r\nAnalyzed samples\r\n8a241cfcc23dc740e1fadc7f2df3965e – main executable\r\nc8e4829dcba8b288bd0ed75717214db6 – Setup.dll\r\n10b2d20a3c36fe6a5bf6f3b15149c3d1– Mischa.dll (raw dump from the memory)\r\n34da44570eb8c7a5038370f553eb3899  – Mischa.dll (with filled section xxxx)\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\nAs mentioned in the previous part of the article, both malicious payloads are dropped by the same dropper. The\r\nchoice of which one will be used for the attack is made based on the privileges with which the sample is deployed.\r\nFirst, there is a request asking a user to elevate the application’s privileges:\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 1 of 15\n\nIn case the user answered “Yes” to the question – his/her machine was getting infected by the Petya ransomware\r\n(described in details here).\r\nBut even in case the user was more cautious and didn’t allow to deploy payload with administrator privileges, it\r\ndidn’t help much. Authors of the malware still found a way to attack the system. Just by launching another\r\npayload – Mischa, that does not require elevated privileges in order to work.\r\nThis payload works just like any other ransomware – encrypting files one by one and dropping a ransom note:\r\nYOUR_FILES_ARE_ENCRYPTED.HTML (identical name was used before by another ransomware: Chimera).\r\nThe layout is analogical to the one used by Petya.\r\nThe same text we can find in a dropped TXT file.\r\nEncryption process\r\nMischa does not need to download a key from the CnC server – data can be encrypted offline as well. Extensions\r\ngiven to the encrypted files are random, generated at runtime (they are same like a part of the tor address):\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 2 of 15\n\nThe atypical feature of Mischa is that it encrypts not only documents, but executables also (only few ransomware\r\nhas been observed to do it).\r\nEntropy of encrypted samples is high and no patterns are visible. See below a visualization of bytes.\r\nsquare.bmp : left – original, right encrypted with Mischa\r\nThe same input does not produce the same output – that suggest that every file is encrypted with an individual key\r\n(or initialization vector).\r\nAt the end of every encrypted file, the unique ID is appended (like the one displayed in the ransom note):\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 3 of 15\n\nPage for the victim:\r\nInside\r\nThe main executable (with an icon pretending a PDF document) is packed in an underground cryptor and its only\r\nrole is to deliver and deploy the malicious core – Setup.dll. This exe’s code doesn’t make much sense for the\r\nfunctionality of the malware – it is only a deception layer added to create a noise and cover a real mission of the\r\nsample. Description of the packing will be omitted this time (it’s very similar to the packing of the previous\r\nPetya).\r\nSetup.dll\r\nSetup.dll carry inside Petya and Mischa and decides which one of them will be dropped. This is the part of the\r\nmalware is responsible for triggering the UAC popup.\r\nSimilarly to the dropper of the previous Petya, it comes with a section .xxxx:\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 4 of 15\n\nThis section is very important, because it contains both payloads – Petya and Mischa (encrypted by simple XOR\r\nbased algorithm). At the beginning of the execution they are being decrypted:\r\nWe can see a stub similar to the previous Petya:\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 5 of 15\n\nIn the same section a new PE file is revealed, that turns out to be a DLL of Mischa.\r\nAuthors tried to deceive tools for automated dumping of PE files from the memory, and provided fake\r\n“MZ”…”PE” patterns:\r\nAfter decrypting the payloads, an environment check is performed in order to choose which one of them will be\r\ninstalled. The process token (resembling the privileges with which the sample was run) is used for choosing which\r\ninstallation path to follow next.\r\nReading the token of current process:\r\nChoosing between Petya and Mischa is done in few steps. First, the token check is used to get information if the\r\napplication is deployed with administrative rights. If it is not, then the it tries to run it’s new copy with higher\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 6 of 15\n\nprivileges (using runas command). If this attempt failed, Mischa is dropped (otherwise – Petya).\r\nDropper comes with a list of Anti-Malware products, which presence is checked before the payload is deployed:\r\nAmong strings we can see URLs for Petya as well as for Mischa. The below part of code is responsible for\r\ngenerating individual URLs for the particular victim and writing them into the payload:\r\nInside the dropper, Mischa’s DLL (similarly to Petya’s stub) is being filled with additional, unique data. Similarly\r\nto Petya, Mischa gets a random key that will be used in further encryption process. This key is encrypted using\r\nECC and transformed into a victim ID. Then, part of this victim ID becomes a part of the individual web address.\r\nThis unique data is generated by the dropper and (encrypted by a simple XOR based algorithm) stored in a new\r\nsection – .xxxx  – dynamically appended to the payload in the preparation phase. (If we dump Mischa too early,\r\nwithout this section, we will get incomplete data and the DLL will not run properly). See below – example of\r\nMischa.dll with the added section:\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 7 of 15\n\nAt this stage, the victim ID  that later is being displayed in the ransom note, as well as the onion addresses are\r\nready.\r\nAfter such preparation, Mischa.dlll is injected to conhost.exe and deployed as a remote thread. Below, we can see\r\nthe buffer containing the prepared Mischa.dll being written to the memory allocated in the remote process:\r\nExecution (including encryption) continues in the remote thread.\r\nMischa.dll\r\nAgain we can see a DLL using ReflectiveLoader* – just like in the case of Chimera and Rokku (along with other\r\nsimilarities in the code, it may confirm the theory, that authors behind those projects are the same):\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 8 of 15\n\n*ReflectiveLoader is a special stub belonging to the technique of Reflective DLL Injection. This technique allows\r\nto produce a DLL that can be easily injected into another process. Similarly to a shellcode, such DLL is self-contained and automatically loads all it’s dependencies.\r\nWhat is attacked?\r\nMischa fetches the list of mapped drives (GetLogicalDriveStringsA) and identifies the drive type by a Windows\r\nAPI function: GetDriveType. It attacks removable, fixed and remote drives.\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 9 of 15\n\nBlacklisted paths:\r\nWindows $Recycle.Bin Microsoft Mozilla Firefox Opera Internet Explorer Temp Local LocalLow Chrome\r\nAttacked extensions:\r\ntxt doc docx docm odt ods odp odf odc odm odb rtf xlsm xlsb xlk xls xlsx pps ppt pptm pptx pub epub\r\nHow does the encryption work?\r\nEvery file is encrypted with a random key. First, using WindowsCryptoAPI function CryptGenRandom 128\r\nrandom bits are fetched. Then, they are hashed and used to generate the initialization vector.\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 10 of 15\n\nApart from the above few calls, Windows Crypto API is not used for the cryptography. Instead, all is implemented\r\nlocally (just like in case of Chimera and Rokku). Below – fragment of the local implementation of function SHA-256, containing typical constants:\r\nFile content is read in portions – 1024 bytes at once:\r\nand then, encrypted by the locally implemented algorithm:\r\nEncryption process is divided in 2 phases.\r\nPhase 1:\r\nEach 16 bytes of the read chunk is preprocessed by XOR with a 16 byte long buffer:\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 11 of 15\n\nAt first, as the XOR key a random buffer is used. For next portions of data, the output of the second phase\r\nbecomes the XOR key (it is a characteristics of Cipher Block Chaining – CBC)\r\nPhase 2:\r\nThe output of phase 1 is passed to another encrypting function:\r\nThis block cipher processes 16 bytes of the input and gives as a result 16 bytes of encrypted output. Encryption\r\ninvolves a 16 byte long key (that was hardcoded in the appended section) – in a given example it is\r\nvW2ebtSboq7gBdUU.\r\nNotice the same key saved inside the .xxxx section (client ID – stored just after that – represents the encrypted\r\nform of this key, that only the attackers can decode):\r\nAs long as Mischa is running, this key is in memory in open text. But once it finishes, this data is being destroyed\r\nand only the encrypted form of the key is left – user receives it in the ransom note. (It is somehow similar to the\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 12 of 15\n\nlogic of Petya).\r\nEncrypted chunks are being written into the file one by one:\r\nAfter the full file is encrypted and the content stored, additional data is appended at the end.\r\nThen, file is moved under the new name.\r\nLet’s have a look at the appended data and it’s role in decoding the file. At the end of the encrypted file we can\r\nfind:\r\n1. Length of the original file (0x528 -\u003e 1320)\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 13 of 15\n\n2. Initialization vector – the random buffer of 16 bytes, that was used to initialize the XOR cycle:\r\n3. Client ID (as mentioned before) – that is encrypted key which was used for the second encryption operation. In\r\nthe above example, this key was: vW2ebtSboq7gBdUU\r\nHaving the important pieces of data – initial XOR buffer and the decrypted key – full process of encryption can be\r\nreversed by the attackers.\r\nConclusion\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 14 of 15\n\nMischa, in contrast to Petya, is yet another typical ransomware. It is well packed and written cleanly, but the core\r\nlooks simple. We didn’t find any novel or unexpected features inside. It seems like the main focus of the authors\r\nwas Petya, and Mischa was added just as a failsafe. However, even if it is simple, it plays the planned role pretty\r\nwell. When the user rejected the request of elevating application privileges, he/she will probably not expect the\r\napplication to be running at all. But this is the event that makes Mischa deploy it’s sneaky attack. In fact it may\r\nhave more painful consequences than the attack of Petya. In case of Petya, some part of the disk content can be\r\nrecovered using forensics tools – but with Mischa it is not possible.\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\n/blog/threat-analysis/2016/04/petya-ransomware/ – about the previous version of Petya\r\nPetya and Mischa – Ransomware Duet (Part 1):\r\n/blog/threat-analysis/2016/05/petya-and-mischa-ransomware-duet-p1/\r\nAbout the author\r\nUnpacks malware with as much joy as a kid unpacking candies.\r\nSource: https://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nhttps://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2\r\nPage 15 of 15", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.malwarebytes.com/blog/news/2016/06/petya-and-mischa-ransomware-duet-p2" ], "report_names": [ "petya-and-mischa-ransomware-duet-p2" ], "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": 1775439083, "ts_updated_at": 1775826720, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/dccedf66ab80baaca8f3b1723a14f07b101b9bf1.pdf", "text": "https://archive.orkl.eu/dccedf66ab80baaca8f3b1723a14f07b101b9bf1.txt", "img": "https://archive.orkl.eu/dccedf66ab80baaca8f3b1723a14f07b101b9bf1.jpg" } }