A Technical Analysis of NotPetya
June 28, 2017
- Share on:
Unless you have been living under a rock, over the last couple days you probably heard a lot about Petya / NotPetya. Our security analysts took a close look at NotPetya. You can view the long version video showing Cynet stopping NotPetya here, and read the detailed technical post below:
Cynet NotPetya Mitigation Layers
Technical Analysis of NonPetya
Technical Analysis of NonPetyaSHA256: 027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745
Over the past 24-hours, we analyzed the new ransomware variant. It was very similar to the old Petya variant, which patches the MBR (on Sector 0). However, this ransomware was more sophisticated than any ransomware we came across before.
First, it checks if has already run, by searching if “c:\Windows\perfc” file exists. If the file exists, the ransomware kills itself (a sort of kill switch).
Next, it changes the MBR record (Sector 0 on the physical disk) to write its own program instead of the Windows Operation System, by using DeviceIoControl method.
The MBR modification will cause the following note to display:
Then, it creates a scheduled task to reboot the system after 1 hour, most likely to wait until it has propagated itself to all the victims and to encrypt the local drives. To create tasks, it uses schtasks.exe / at.exe windows processes.
Here, the real fun is about to begin. To find potential victims, the ransomware uses several techniques:
The first one is responsible for collecting all of the client IP Addresses on all DHCP subnets, by using DhcpEnumSubnets and DhcpEnumSubnetClients WinAPI methods.
For each IP, it checks if it can open a socket using ports 445 OR 139 (SMB ports).
The second technique is to get all of TCP endpoints available to the ransomware, by calling to GetExtendedTcpTable (from “iphlpapi.dll”).
After this, the next technique is to use GetIpNetTable to get all the IP addresses from the ARP Cache.
And the last (and our favorite) technique is to use NetServerEnum to get the primary Domain Controller.
Next, from its resources, the ransomware dumps on %TEMP%\RandomFileName.tmp a Mimiktaz “like” executable, to steal the user credentials from lsass.exe Windows process. This helps it later to run itself on remote victim computers over the network.
The ransomware runs the dumper tool, and communicates with the “dumper” using windows NamedPipe.
Following this, it dumps an old version of psexec to the file system (named dllhost.dat).
To run in highest privileges, it tries to steal Tokens of other running processes using DuplicateTokenEx and SetTokenInformation.
Then, the ransomware starts its propagation. In addition to the dumped credentials, it tries to steal more credentials by using CredEnumerateW. This is especially true if it finds users starting with “TERMSRV/”.
To run itself on other victims in network, it tries to copy itself to \\HOST\admin$\ share on the victim host.
It tries to run itself by running the dumped psexec using rundll32.exe.
If this fails, it tries running itself using the WMI “process call create” command.
It also tries to propagate itself using the EternalBlue and EternalRomance exploits, released a few months ago and it exploits SMB vulnerabilities in Windows OS.
In the next phase, the ransomware encrypts all fixed drives.
The list of file extensions the ransomware tries to encrypt is shown below:
The ransomware tries to run the exploit thread with a victim ip address of a localhost, probably used as a privilege escalation technique.
In the next phase, the ransomware takes actions to clean its traces from the system by deleting the Event Viewer Logs:
And right after this, it tries to restart by calling NtRaiseHardError or using a legit API call for InitiateSystemShutdownEx or ExitWindowsEx API function.
