PetrWrap Technical Analysis Part II: Further Findings and Potential for MBR Recovery

Executive Summary

This technical analysis is a continuation of the previous technical blog (PetrWrap Technical Analysis – A Triple Threat: File Encryption, MFT Encryption, Credential Theft)  describing the threat of PetrWrap, a destructive malware with self-propagation capabilities.  After further analysis, CrowdStrike researchers discovered:

  • How the PetrWrap 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

PetrWrap DLL Loader

The PetrWrap 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 PetrWrap 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 PetrWrap DLL already mapped into process memory to another buffer
  • Calculates and patches the relative offsets in the PetrWrap copy with a new offset  
  • The new relative offset is calculated by subtracting the base address original PetrWrap DLL from the RVAs identified in the relocation table of the PetrWrap copy
  • Calls the function at offset +0x94A5 located in the PetrWrap copy
    • Calls FreeLibrary to unmap the original PetrWrap DLL from process memory
    • Overwrites the original DLL file with null bytes
    • Deletes the original PetrWrap DLL from the file system
    • Fixes the import table of the PetrWrap DLL copy
    • Calls the perfc_1 (export ordinal 1) function to kick off the worm activity and file/MFT encryption

The file cleanup combined with the file and MFT encryption process make it difficult to recover the original PetrWrap DLL.

SMB Exploitation and Infection

The EternalBlue and EternalRomance exploits are used for the MS17-010 vulnerability, and are subsequently used to propagate PetrWrap to vulnerable hosts on the local subnet. The infection process occurs in the following order:

  1. Test for vulnerable condition
  2. Check Windows version
  3. Trigger MS17-010 vulnerability. For more information, please click here.
  4. Deploy an SMB backdoor
  5. PetrWrap 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):

  1. An initial SMB_COM_NEGOTIATE request and response
  2. Session setup
  3. Tree connect
  4. PeekNamedPipe SMB transaction with FID: 0x0000
    1. Exploitable condition:
      1. Trans response, error:  STATUS_INSUFF_SERVER_RESOURCES
      2. Error code: 0xC0000205
      3. Server is out of resources
  5. Close session: Tree disconnect and AndX logoff

A check is then done to determine if the victim’s response is STATUS_INSUFF_SERVER_RESOURCES  (0xC0000205). An example of this is shown below:

If the error code does not exist, the session is cleaned up and PetrWrap 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

PetrWrap will only exploit one of the Windows versions listed above. If the version does not match one of the identified Windows versions, then the function to execute the exploit code returns without executing.

The EternalBlue exploit is launched against only the following Windows versions:

  • Windows 7
  • Windows 2008
  • Windows 2008 R2

The EternalRomance exploit is launched against only the following Windows versions:

  • Windows XP
  • XP Pro x64
  • Windows Server 2003
  • Windows Server 2003 R2
  • Vista

The EternalRomance code path begins at 0x10005C4C.

Trigger MS17-010 (EternalBlue)

The following image and explanation refers to the SMB network traffic that starts the exploitation process:

  1. An initial SMB_COM_NEGOTIATE request and response
  2. Session setup
  3. Tree connect
  4. PeekNamedPipe SMB transaction with FID: 0x0000
    1. Exploitable condition:
      1. Trans response, error:   STATUS_INSUFF_SERVER_RESOURCES
      2. Error code: 0xC0000205
      3. Server is out of resources
  5. NT trans request
    1. Followed by Trans2 secondary request, FID: 0x0000

This exploitation process is followed by a series of additional SMB packets. There are three types of packets that are identified based on size:

  • 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
  • TYPE 2:
    • TCP segment data size: 1152 bytes
    • Sends the DLL injector code

This first burst of requests are TYPE 0 packets.

To trigger the exploit, a 4207-byte “SMB Trans2 Secondary Request, FID: 0x0000” packet is sent to the vulnerable machine, as depicted below. This packet is built and sent in function sub_10003C0A.

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 PetrWrap 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 is the 2423 byte chunk for binary data starting at address 0x1000123B0 within the PetrWrap 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.

Sending the DLL Injector Code

The SMB backdoor code is the 2422-byte chunk of binary data starting at address 0x10012D27. This data is XORd with 0xCC. The backdoor is sent using multiple TYPE 2 packets.

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.

pertrwrap

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.

PetrWrap Infection

To deploy PetrWrap onto the system, a staging DLL is injected into “lsass.exe.” Once the DLL is injected into lsass, PetrWrap is written to the system in c:\windows:

The PetrWrap 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 PetrWrap 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, PetrWrap will NOT encrypt the MFT.  Victim machines that have avp.exe running when impacted by PetrWrap 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, PetrWrap 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 PetrWrap 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

pertrwrap

  • 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

pertrwrap

  • 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

The above steps will allow the user to access the system again, but certain files (that match the target extension list) on the system will still be encrypted and can only be decrypted with a private key possessed by the PetrWrap authors. Analysis also shows that the malware only encrypts the first 1MB of file contents, if the size of the file is greater than 1MB. The remaining contents are left untouched and intact.

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.

Additional Resources

For more information on CrowdStrike’s proactive protection features see the earlier CrowdStrike blog on how Falcon Endpoint Protection prevents the PetrWrap attack. In addition, watch a demo of  CrowdStrike Falcon® detecting and blocking PetrWrap.

The post PetrWrap Technical Analysis Part II: Further Findings and Potential for MBR Recovery appeared first on .

Article Link: https://www.crowdstrike.com/blog/petrwrap-technical-analysis-part-2-further-findings-and-potential-for-mbr-recovery/