{ "id": "69ebe9a9-4241-4862-99c3-13aac4ed5acf", "created_at": "2026-04-06T00:22:00.624967Z", "updated_at": "2026-04-10T03:26:53.277489Z", "deleted_at": null, "sha1_hash": "efcf1ec26fbd855f6af9adc8de3ba2f5cf1e531b", "title": "NotPetya Technical Analysis Part II: Further Findings", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2426053, "plain_text": "NotPetya Technical Analysis Part II: Further Findings\r\nBy Shaun Hurley and Karan Sood\r\nArchived: 2026-04-05 14:14:59 UTC\r\nUpdate:\r\nDue to naming convention consistency in the industry, CrowdStrike is now calling this variant of Petya -\r\nNotPetya.\r\nExecutive Summary\r\nThis technical analysis is a continuation of the previous technical blog (NotPetya Technical Analysis – A Triple\r\nThreat: File Encryption, MFT Encryption, Credential Theft) describing the threat of NotPetya, a destructive\r\nmalware with self-propagation capabilities. After further analysis, CrowdStrike researchers discovered:\r\nHow the NotPetya DLL loads functions to ensure proper cleanup from the victim machine\r\nThe order in which the infection process takes place\r\nPotential for recovery of the victim machine’s MBR and boot manager when running one specific antivirus\r\nsoftware\r\nNotPetya DLL Loader\r\nThe NotPetya DLL, seen in the wild with the filename “perfc.dat”, takes the following steps during the DLL\r\nloading process to ensure that there is no trace of the NotPetya DLL (perfc.dll) having being on the system:\r\nCopies file contents from disk into a buffer residing in process memory\r\nChecks to determine if the DLL has already been loaded\r\nCopies the NotPetya DLL already mapped into process memory to another buffer\r\nCalculates and patches the relative offsets in the NotPetya copy with a new offset\r\nThe new relative offset is calculated by subtracting the base address original NotPetya DLL from the RVAs\r\nidentified in the relocation table of the NotPetya copy\r\nCalls the function at offset +0x94A5 located in the NotPetya copy\r\nCalls FreeLibrary to unmap the original NotPetya DLL from process memory\r\nOverwrites the original DLL file with null bytes\r\nDeletes the original NotPetya DLL from the file system\r\nFixes the import table of the NotPetya DLL copy\r\nCalls the perfc_1 (export ordinal 1) function to kick off the worm activity and file/MFT encryption\r\nThe file cleanup combined with the file and MFT encryption process make it difficult to recover the original\r\nNotPetya DLL.\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 1 of 12\n\nSMB Exploitation and Infection\r\nThe EternalBlue and EternalRomance exploits are used for the MS17-010 vulnerability, and are subsequently used\r\nto propagate NotPetya to vulnerable hosts on the local subnet. The infection process occurs in the following order:\r\n1. Test for vulnerable condition\r\n2. Check Windows version\r\n3. Trigger MS17-010 vulnerability. For more information, please click here.\r\n4. Deploy an SMB backdoor\r\n5. NotPetya infection\r\nTest for Vulnerable Condition\r\nAs can be seen in the control flow graph, core_MS17_010 is initially called to determine if the exploit condition\r\nexists. If it does, core_MS17_010 is called again with slightly different arguments to exploit the vulnerability and\r\nsend the shellcode.\r\nThe following is an image and explanation of the SMB network traffic used to determine if the victim is\r\nvulnerable (Victim: 172.16.1.132):\r\n1. An initial SMB_COM_NEGOTIATE request and response\r\n2. Session setup\r\n3. Tree connect\r\n4. PeekNamedPipe SMB transaction with FID: 0x0000\r\n1. Exploitable condition:\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 2 of 12\n\n1. Trans response, error: STATUS_INSUFF_SERVER_RESOURCES\r\n2. Error code: 0xC0000205\r\n3. Server is out of resources\r\n5. Close session: Tree disconnect and AndX logoff\r\nA check is then done to determine if the victim’s response is STATUS_INSUFF_SERVER_RESOURCES\r\n(0xC0000205). An example of this is shown below:\r\nIf the error code does not exist, the session is cleaned up and NotPetya iterates to the next IP address. If the error\r\ncode exists, the core_MS17_010 returns 0, and the vulnerability is exploited.\r\nCheck Windows Version\r\nPrior to executing the exploit code, a test ensues to determine which version of Microsoft Windows is running on\r\nthe system. This is done by parsing the “Session Setup AndX Response” packet. Once the version of the OS is\r\nidentified it is mapped to a numeric value:\r\n2 - Windows XP\r\n3 - Windows XP Pro x64, Windows 2003, Windows 2003 R2\r\n4 - Windows Vista\r\n5 - Windows 7\r\n6 - Windows 2008\r\n7 - Windows 2008 R2\r\nNotPetya will only exploit one of the Windows versions listed above. If the version does not match one of the\r\nidentified Windows versions, then the function to execute the exploit code returns without executing. The\r\nEternalBlue exploit is launched against only the following Windows versions:\r\nWindows 7\r\nWindows 2008\r\nWindows 2008 R2\r\nThe EternalRomance exploit is launched against only the following Windows versions:\r\nWindows XP\r\nXP Pro x64\r\nWindows Server 2003\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 3 of 12\n\nWindows Server 2003 R2\r\nVista\r\nThe EternalRomance code path begins at 0x10005C4C.\r\nTrigger MS17-010 (EternalBlue)\r\nThe following image and explanation refers to the SMB network traffic that starts the exploitation process:\r\n1. An initial SMB_COM_NEGOTIATE request and response\r\n2. Session setup\r\n3. Tree connect\r\n4. PeekNamedPipe SMB transaction with FID: 0x0000\r\n1. Exploitable condition:\r\n1. Trans response, error: STATUS_INSUFF_SERVER_RESOURCES\r\n2. Error code: 0xC0000205\r\n3. Server is out of resources\r\n5. NT trans request\r\n1. Followed by Trans2 secondary request, FID: 0x0000\r\nThis exploitation process is followed by a series of additional SMB packets. There are three types of packets that\r\nare identified based on size:\r\nTYPE 0:\r\nTCP segment data size: 132 bytes\r\nThe first 10 bytes of the TCP segment data contain:\r\n0x0 - Null byte\r\n0x2 - 0xFFF7\r\n0x4 - 2 byte value based on a timing check\r\n0x6 - 2 byte value based on another timing check\r\nThe rest of the packet contains null bytes\r\nTYPE 1:\r\nTCP segment data size: 2920 bytes\r\nThis packet sends the kernel shellcode\r\nThis packet is sent with the same data 13 times\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 4 of 12\n\nThis first burst of requests are TYPE 0 packets. To trigger the exploit, a 4207-byte \"SMB Trans2 Secondary\r\nRequest, FID: 0x0000\" packet is sent to the vulnerable machine, as depicted below. This packet is built and sent in\r\nfunction sub_10003C0A.\r\nThe exploit code is contained within the 4096 byte \"Extra byte parameters\" section of the Trans2 packet. This\r\n4096 buffer is filled with hex byte '\\x54' ('T'). At offset 0xB within that buffer, the hex byte '\\x51' is used to specify\r\nthe start of the data that will trigger the overflow on the vulnerable machine. The specific code to trigger the\r\noverflow is the 175-byte chunk of binary data within the NotPetya binary, starting at address 0x10010B08. The\r\ncode is not encoded.\r\nSending the Ring 0 Shellcode\r\nOnce the vulnerability has been exploited, the Ring 0 shellcode is sent using TYPE 1 packets. The ring 0\r\nshellcode, which contains the SMB backdoor code, is the 2423 byte chunk for binary data starting at address\r\n0x1000123B0 within the NotPetya binary. The ring 0 shellcode is encoded with a simple byte xor. The xor key is\r\n0xCC. The shellcode starts at offset 0x1F1 within the TCP segment data.\r\nDeploy SMB Backdoor\r\nThe backdoor that gets deployed onto an exploited system appears to be a modified version (based on network\r\ntraffic) of the DoublePulsar rootkit leaked by the Shadow Brokers actors.\r\nNetwork Traffic\r\nIf there is a DoublePulsar knock feature, it is not used. Once the SMB backdoor is in place, the ‘Reserved’ field of\r\nthe SMB Header for the response packet is set to 0x1100, as seen below. Normally this field is NULL.\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 5 of 12\n\nPrior to triggering the code to exploit the\r\nsystem, the “Reserved” field in the SMB header is checked to see if it is set to 0x11.\r\nIf the “Reserved” field in the SMB header is set to 0x11, the staging code is built and sent to the targeted machine.\r\n“Trans2 Request, SESSION_SETUP” packets are used to send the staging DLL to the target.\r\nNotPetya Infection\r\nTo deploy NotPetya onto the system, a staging DLL is injected into “lsass.exe.” Once the DLL is injected into\r\nlsass, NotPetya is written to the system in c:\\windows:\r\nThe NotPetya DLL keeps the same filename the file was called when executed on the attacking machine (in this\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 6 of 12\n\ncase, olga.dll). Once the file is written, it can be launched. The staging DLL executes the file in the same way as\r\npsexec and wmic: rundll32.exe. As can be seen below, the same arguments are passed to the NotPetya DLL.\r\nMBR Restoration for Machines running Kaspersky Antivirus\r\nThrough analysis, it was discovered that if the victim machine has avp.exe (associated with Kaspersky antivirus)\r\nprocess running, NotPetya will NOT encrypt the MFT. Victim machines that have avp.exe running when impacted\r\nby NotPetya will simply have the first 10 sectors of the physical disk overwritten with uninitialized data. For\r\nvictim machines that do not have avp.exe running, NotPetya will overwrite the MBR with a custom boot loader,\r\nwhich will then load 16-bit code responsible for encrypting the MFT. The following displays “before and after”\r\nimages of the MBR on a machine with avp.exe running. Notice the lack of the footer (0x55, 0xAA) in the MBR\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 7 of 12\n\nafter the modification.\r\nAdditionally, analysis also shows that the NotPetya malware overwrites the 2nd sector of the C:\\ volume with\r\nuninitialized data as well. This sector contains the Boot Manager, which is loaded by the VBR (Volume Boot\r\nRecord) and is needed for booting up the system. Overwriting this sector renders the machine unbootable. It\r\nshould be noted that this change occurs regardless of whether the victim machine has avp.exe process running on\r\nthe system or not. The following are the before and after images of the 2nd sector:\r\nIf the avp.exe process exists on the system, upon reboot, the victim is prompted with an error message that an\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 8 of 12\n\noperating system cannot be found:\r\nSteps to Recover MBR\r\nAnalysis has confirmed that in the case of the presence of avp.exe process, the MBR is actually recoverable via\r\nthe Windows repair tools. For Windows 7 and higher, the following steps can be taken to recover the MBR:\r\nBoot from a Windows installation disk\r\nUpon system reboot, click Next → Repair Your Computer\r\nUnder System Recovery Options, click on “Use Recovery Tools”\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 9 of 12\n\nClick “Startup Repair”\r\nThe MBR should now be repaired. Users can confirm this by clicking on “Click here for diagnostic and\r\nrepair details” and scrolling down to the MBR section\r\nClick Close → Finish. This will reboot the machine\r\nSome users might receive the following error message upon reboot. This error is due to the boot manager\r\ncorruption\r\nTo rectify this issue, change the boot order to boot from the Windows disk image. This can be achieved by\r\ngoing into the BIOS settings\r\nUpon system reboot, follow the first 2 steps and the user should then see the OS under System Recovery\r\nOptions\r\nClick on the OS, choose the “Use recovery tools” option, and click Next\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 10 of 12\n\nTo repair the boot manager, click on “Command Prompt” and enter the following command:\r\nbootrec /fixboot\r\nUpon successful execution of the command, close the command prompt and click “Restart”\r\nUpon repairing the MBR and the boot manager, the user can boot the system without the Windows\r\ninstallation disk and access the system\r\nThe above steps will allow the user to access the system again, but certain files (that match the target extension\r\nlist) on the system will still be encrypted and can only be decrypted with a private key possessed by the NotPety\r\nauthors. Analysis also shows that the malware only encrypts the first 1MB of file contents, if the size of the file is\r\ngreater than 1MB. The remaining contents are left untouched and intact.\r\nAs the above image shows, line 20 compares the file size with 0x100000 (1,048,576 bytes or 1MB). If the file size\r\nis greater than 1MB, line 26 declares variables FileSize_1 and FinalFileSize to be 0x100000. These values are\r\nthen used in CreateFileMappingW, MapViewOfFile and CryptEncrypt to encode the first 1MB of the file contents.\r\nThe rest of the file remains untouched.\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 11 of 12\n\nAdditional Resources\r\nFor more information on CrowdStrike’s proactive protection features see the earlier CrowdStrike blog on how\r\nFalcon Endpoint Protection prevents the NotPetya attack. In addition, watch a demo of CrowdStrike Falcon®\r\ndetecting and blocking NotPetya.\r\nSource: https://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nhttps://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/\r\nPage 12 of 12", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/" ], "report_names": [ "petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery" ], "threat_actors": [ { "id": "d4f7cf97-9c98-409c-8b95-b80d14c576a5", "created_at": "2022-10-25T16:07:24.561104Z", "updated_at": "2026-04-10T02:00:05.03343Z", "deleted_at": null, "main_name": "Shadow Brokers", "aliases": [], "source_name": "ETDA:Shadow Brokers", "tools": [], "source_id": "ETDA", "reports": null }, { "id": "171b85f2-8f6f-46c0-92e0-c591f61ea167", "created_at": "2023-01-06T13:46:38.830188Z", "updated_at": "2026-04-10T02:00:03.114926Z", "deleted_at": null, "main_name": "The Shadow Brokers", "aliases": [ "Shadow Brokers", "ShadowBrokers", "The ShadowBrokers", "TSB" ], "source_name": "MISPGALAXY:The Shadow Brokers", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434920, "ts_updated_at": 1775791613, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/efcf1ec26fbd855f6af9adc8de3ba2f5cf1e531b.pdf", "text": "https://archive.orkl.eu/efcf1ec26fbd855f6af9adc8de3ba2f5cf1e531b.txt", "img": "https://archive.orkl.eu/efcf1ec26fbd855f6af9adc8de3ba2f5cf1e531b.jpg" } }