![Helping Non-Security Stakeholders Understand ATT&CK in 10 Minutes or Less [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/video-ATTCK2-1)
![Qatar’s Commercial Bank Chooses CrowdStrike Falcon®: A Partnership Based on Trust [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/Edward-Gonam-Qatar-Blog2-1)
![Endpoint Protection and Threat Intelligence: The Way Forward [VIDEO]](https://assets.crowdstrike.com/is/image/crowdstrikeinc/GK-Blog_Images-1)
Update:
Due to naming convention consistency in the industry, CrowdStrike is now calling this variant of Petya - NotPetya.Executive Summary
This technical analysis is a continuation of the previous technical blog (NotPetya Technical Analysis – A Triple Threat: File Encryption, MFT Encryption, Credential Theft) describing the threat of NotPetya, a destructive malware with self-propagation capabilities. After further analysis, CrowdStrike researchers discovered:- How the NotPetya DLL loads functions to ensure proper cleanup from the victim machine
- The order in which the infection process takes place
- Potential for recovery of the victim machine’s MBR and boot manager when running one specific antivirus software
NotPetya DLL Loader
The NotPetya DLL, seen in the wild with the filename “perfc.dat”, takes the following steps during the DLL loading process to ensure that there is no trace of the NotPetya DLL (perfc.dll) having being on the system:- Copies file contents from disk into a buffer residing in process memory
- Checks to determine if the DLL has already been loaded
- Copies the NotPetya DLL already mapped into process memory to another buffer
- Calculates and patches the relative offsets in the NotPetya copy with a new offset
- The new relative offset is calculated by subtracting the base address original NotPetya DLL from the RVAs identified in the relocation table of the NotPetya copy
- Calls the function at offset +0x94A5 located in the NotPetya copy
- Calls FreeLibrary to unmap the original NotPetya DLL from process memory
- Overwrites the original DLL file with null bytes
- Deletes the original NotPetya DLL from the file system
- Fixes the import table of the NotPetya DLL copy
- Calls the perfc_1 (export ordinal 1) function to kick off the worm activity and file/MFT encryption
SMB Exploitation and Infection
The EternalBlue and EternalRomance exploits are used for the MS17-010 vulnerability, and are subsequently used to propagate NotPetya to vulnerable hosts on the local subnet. The infection process occurs in the following order:- Test for vulnerable condition
- Check Windows version
- Trigger MS17-010 vulnerability. For more information, please click here.
- Deploy an SMB backdoor
- NotPetya infection
Test for Vulnerable Condition
As can be seen in the control flow graph, core_MS17_010 is initially called to determine if the exploit condition exists. If it does, core_MS17_010 is called again with slightly different arguments to exploit the vulnerability and send the shellcode.
The following is an image and explanation of the SMB network traffic used to determine if the victim is vulnerable (Victim: 172.16.1.132):
- An initial SMB_COM_NEGOTIATE request and response
- Session setup
- Tree connect
- PeekNamedPipe SMB transaction with FID: 0x0000
- Exploitable condition:
- Trans response, error: STATUS_INSUFF_SERVER_RESOURCES
- Error code: 0xC0000205
- Server is out of resources
- Exploitable condition:
- Close session: Tree disconnect and AndX logoff
If the error code does not exist, the session is cleaned up and NotPetya iterates to the next IP address. If the error code exists, the core_MS17_010 returns 0, and the vulnerability is exploited.
Check Windows Version
Prior to executing the exploit code, a test ensues to determine which version of Microsoft Windows is running on the system. This is done by parsing the “Session Setup AndX Response” packet. Once the version of the OS is identified it is mapped to a numeric value:- 2 - Windows XP
- 3 - Windows XP Pro x64, Windows 2003, Windows 2003 R2
- 4 - Windows Vista
- 5 - Windows 7
- 6 - Windows 2008
- 7 - Windows 2008 R2
- Windows 7
- Windows 2008
- Windows 2008 R2
- Windows XP
- XP Pro x64
- Windows Server 2003
- Windows Server 2003 R2
- Vista
Trigger MS17-010 (EternalBlue)
The following image and explanation refers to the SMB network traffic that starts the exploitation process:
- An initial SMB_COM_NEGOTIATE request and response
- Session setup
- Tree connect
- PeekNamedPipe SMB transaction with FID: 0x0000
- Exploitable condition:
- Trans response, error: STATUS_INSUFF_SERVER_RESOURCES
- Error code: 0xC0000205
- Server is out of resources
- Exploitable condition:
- NT trans request
- Followed by Trans2 secondary request, FID: 0x0000
- TYPE 0:
- TCP segment data size: 132 bytes
- The first 10 bytes of the TCP segment data contain:
- 0x0 - Null byte
- 0x2 - 0xFFF7
- 0x4 - 2 byte value based on a timing check
- 0x6 - 2 byte value based on another timing check
- The rest of the packet contains null bytes
- TYPE 1:
- TCP segment data size: 2920 bytes
- This packet sends the kernel shellcode
- This packet is sent with the same data 13 times
The exploit code is contained within the 4096 byte "Extra byte parameters" section of the Trans2 packet. This 4096 buffer is filled with hex byte '\x54' ('T'). At offset 0xB within that buffer, the hex byte '\x51' is used to specify the start of the data that will trigger the overflow on the vulnerable machine.
The specific code to trigger the overflow is the 175-byte chunk of binary data within the NotPetya binary, starting at address 0x10010B08. The code is not encoded.
Sending the Ring 0 Shellcode
Once the vulnerability has been exploited, the Ring 0 shellcode is sent using TYPE 1 packets. The ring 0 shellcode, which contains the SMB backdoor code, is the 2423 byte chunk for binary data starting at address 0x1000123B0 within the NotPetya binary. The ring 0 shellcode is encoded with a simple byte xor. The xor key is 0xCC. The shellcode starts at offset 0x1F1 within the TCP segment data.Deploy SMB Backdoor
The backdoor that gets deployed onto an exploited system appears to be a modified version (based on network traffic) of the DoublePulsar rootkit leaked by the Shadow Brokers actors.Network Traffic
If there is a DoublePulsar knock feature, it is not used. Once the SMB backdoor is in place, the ‘Reserved’ field of the SMB Header for the response packet is set to 0x1100, as seen below. Normally this field is NULL.
Prior to triggering the code to exploit the system, the “Reserved” field in the SMB header is checked to see if it is set to 0x11.
If the “Reserved” field in the SMB header is set to 0x11, the staging code is built and sent to the targeted machine.
“Trans2 Request, SESSION_SETUP” packets are used to send the staging DLL to the target.
NotPetya Infection
To deploy NotPetya onto the system, a staging DLL is injected into “lsass.exe.” Once the DLL is injected into lsass, NotPetya is written to the system in c:\windows:
The NotPetya DLL keeps the same filename the file was called when executed on the attacking machine (in this case, olga.dll). Once the file is written, it can be launched.
The staging DLL executes the file in the same way as psexec and wmic: rundll32.exe. As can be seen below, the same arguments are passed to the NotPetya DLL.
MBR Restoration for Machines running Kaspersky Antivirus
Through analysis, it was discovered that if the victim machine has avp.exe (associated with Kaspersky antivirus) process running, NotPetya will NOT encrypt the MFT. Victim machines that have avp.exe running when impacted by NotPetya will simply have the the first 10 sectors of the physical disk overwritten with uninitialized data. For victim machines that do not have avp.exe running, NotPetya will overwrite the MBR with a custom boot loader, which will then load 16-bit code responsible for encrypting the MFT. The following displays “before and after” images of the MBR on a machine with avp.exe running. Notice the lack of the footer (0x55, 0xAA) in the MBR after the modification.
Additionally, analysis also shows that the NotPetya malware overwrites the 2nd sector of the C:\ volume with uninitialized data as well. This sector contains the Boot Manager, which is loaded by the VBR (Volume Boot Record) and is needed for booting up the system. Overwriting this sector renders the machine unbootable. It should be noted that this change occurs regardless of whether the victim machine has avp.exe process running on the system or not. The following are the before and after images of the 2nd sector:
If the avp.exe process exists on the system, upon reboot, the victim is prompted with an error message that an operating system cannot be found:
Steps to Recover MBR
Analysis has confirmed that in the case of the presence of avp.exe process, the MBR is actually recoverable via the Windows repair tools. For Windows 7 and higher, the following steps can be taken to recover the MBR:- Boot from a Windows installation disk
- Upon system reboot, click Next → Repair Your Computer
- Under System Recovery Options, click on “Use Recovery Tools”
- Click “Startup Repair”
- The MBR should now be repaired. Users can confirm this by clicking on “Click here for diagnostic and repair details” and scrolling down to the MBR section
- Click Close → Finish. This will reboot the machine
- Some users might receive the following error message upon reboot. This error is due to the boot manager corruption
- To rectify this issue, change the boot order to boot from the Windows disk image. This can be achieved by going into the BIOS settings
- Upon system reboot, follow the first 2 steps and the user should then see the OS under System Recovery Options
- Click on the OS, choose the “Use recovery tools” option, and click Next
- To repair the boot manager, click on “Command Prompt” and enter the following command:
bootrec /fixboot
- Upon successful execution of the command, close the command prompt and click “Restart”
- Upon repairing the MBR and the boot manager, the user can boot the system without the Windows installation disk and access the system
As the above image shows, line 20 compares the file size with 0x100000 (1,048,576 bytes or 1MB). If the file size is greater than 1MB, line 26 declares variables FileSize_1 and FinalFileSize to be 0x100000. These values are then used in CreateFileMappingW, MapViewOfFile and CryptEncrypt to encode the first 1MB of the file contents. The rest of the file remains untouched.
