On Tuesday 27 June, we saw another outbreak of ransomware. This blog is live and will be updated as we know more. The ransomware is currently being discussed as a variant of Petya, which also modifies the Master Boot Record (MBR), although this ransomware also has traits similar to WannaCry in that it uses Eternal Blue for some propagation.
An excellent FAQ document has been produced by our Fox-IT team in the Netherlands:
Sample
A sample has been published reported to be the sample in action on VirusTotal [1]
Delivery Mechanisms
There are likely to be multiple delivery mechanisms, we have seen some evidence of email borne threats and office documents to deliver the initial implant.
A number of sources are reporting a supply chain compromise through a Ukrainian company [4] although this cannot be confirmed at the current time.
Post infection Behaviour
Our Cyber Defence Operations team and Fox-IT Security Research team have confirmed that once inside an organisation it uses the Eternal Blue exploit for propagation. There is also evidence of pass the hash techniques, which potentially make it a serious threat inside a corporate network.
This ransomware was observed only communicating to internal hosts on a network estate, not propagating to random Internet IP addresses as previously observed in the WannaCry outbreak. Our analysis of original binary includes a number of embedded files. This includes a 32-bit and 64-bit version of a password dumping tool DLL, and a copy of psexec. This DLL is very similar to sekurlsa.dll from mimikatz.
This means that fully patched machines can also be infected via the network, clearly this a disturbing proposition. The enumeration of the internal networks during propagation is likely to mean that the ransomware spreads quickly inside, however, is unlikely to spread outside of those networks.
High level functional map
- Try to acquire privileges and perform process enumeration looking for specific process name hashes.
- The sample will start by checking if a file with the same name as itself is in C:Windows
(less the extension) if not then it will create it. We believe this could be some sort of marker of infection since there is a delay before a reboot it triggered rather than a “kill-switch” or “vaccine”. - Get drive geometry and identify the type of boot sector used (MBR/GPT/RAW).
- Starts writing to DeviceHarddisk0Dr0 (512bytes – one sector at a time) 35 sectors. Overwrites the MBR and stores the original xor’ed with 0x7h at sector 34 (last sector written).
- Setups a scheduled task to reboot the machine after some time.
- Drops a password dumping tool to %UserProfile%AppDataLocalTemp
.tmp. - Starts enumerating the local subnet probing live machines on TCP ports 139 and 445. It then will use the acquired credentials from the password dumping tool to copy itself over the network.
- If on a domain controller it will enumerate all DHCP subnet leases.
- Will attempt to copy itself over `admin$` network share to locally connected machines.
- Will attempt to launch EternalBlue and EternalRomance exploit in order to spread.
- Will try to execute the copied versions of itself using dropped Psexec in `C:Windowsdllhost.dat` or WMI.
- Encrypt files in `C:` except `C:Windows`.
- Clean up logs after encryption using wevutil and fsutil.
Technical Analysis Details
This ransomware was observed only communicating to internal hosts on a network estate, not propagating to random Internet IP addresses as previously observed in the WannaCry outbreak.
The ransomware tries to acquire several privileges (SeTcbPrivilege, SeShutdownPrivilege, SeDebugPrivilege) in order to be able to overwrite the MBR (Master boot record) with its malicious one. An interesting process enumeration takes place following this privilege acquisition. It’s not clear to us what exactly the process names are that the sample is looking for since it’s looking for hash comparisons of the process names (0x651B3005h, 0x6403527Eh, 0x2E214B44h). The ransomware writes 35 sectors from the start of disk. It gets the drive size by issuing a DeviceIOControl IOCTL_DIST_GET_DRIVE_GEOMETRY to C:. To identify the type of boot sector it issues an IOCTL to DeviceHarddisk0Dr0 (IOCTL_DISK_GET_PARTITION_INFO_EX) in order to find out the type of the boot sector on the partition (MBR/GPT/RAW). The last sector written includes the original MBR xor’ed with 0x7h. The bitcoin address is saved to sector 32.
The ransomware will set a scheduled task to reboot the machine, this is in order to trigger the execution of the malicious MBR. This would disable access to the machine completely. It’s worth noting that file encryption takes place before the reboot so even if the reboot doesn’t happen it doesn’t mean that a machine is not infected. ` /c schtasks /Create /SC once /TN “” /TR “C:Windowssystem32shutdown.exe /r /f” /ST
The dll seems to create a file in C:Windows less the extension. For example, if the sample being executed is ransomware.dll it will be C:Windowsransomware. We believe this is just an infection marker.
The ransomware drops a password dumping tool to `%UserProfile%AppDataLocalTemp[0-9]{4}.tmp`. There are two versions of that binary included in the resources of the dll; a 32-bit and 64-bit version. This tool is started with a pipe name as an argument. This pipe name is random GUID. The pipe is used to write extracted credentials back for the dll to use for propagation.
The propagation of the ransomware takes multiple forms. One approach is checking for alive machines on the local subnet and if it’s on a Domain Controller then it will try to identify machines on all DHCP ranges. Following this enumeration, it probes alive machines on TCP ports 139 and port 445. Using the credentials obtained from the password dumping tool it then tries to copy the files over these ports.
Execution follows after that using the copy of Psexec that it drops in `C:Windowsdllhost.dat`. It also tries to execute the sample using WMI if the Psexec approach fails.
- Psexec (dllhost.dat)
- `accepteula –s -d C:WindowsSystem32rundll32.exe “C:Windows%s”,#1`
- WMI execution
- ` /node:”%ws” /user:”%ws” /password:”% process call create “C:WindowsSystem32rundll32.exe “C:Windows%s” #1`
Another propagation technique it uses is trying to copy itself to `admin$` share on locally connected machines. Then triggering execution using the same techniques above (PsExec / WMI).
The ransomware will also attempt to propagate using EternalBlue exploit.
As far as our testing encryption of files only takes place on ‘C:’. As mentioned prior, encryption of the files takes place before a reboot. The dll will enumerate the C: volume encrypting files with a set of extensions. Files are mapped and encrypted data written to it.
| .3ds | .7z | .accdb | .back |
| .asp | .aspx | .avhd | .conf |
| .bak | .c | .cfg | .dbf |
| .cpp | .cs | .ctl | .docx |
| .disk | .djvu | .doc | .gz |
| .dwg | .eml | .fdb | |
| .h | .hdd | .kdbx | .ora |
| .mdb | .msg | .nrg | |
| .ost | .ova | .ovf | .pptx |
| .php | .pmf | .ppt | .pyc |
| .pst | .pvi | .py | .sql |
| .rar | .rtf | .sln | .vcb |
| .tar | .vbox | .vbs | .vmdk |
| .vdi | .vfd | .vmc | .vsv |
| .vmsd | .vmx | .vsdx | |
| .work | .xls | .xlsx | |
| .zip | .xvd | .ai |
Finally the ransomware will clear logs of it’s execution by running the following command:
- `wevtutil cl Setup wevtutil cl System wevtutil cl Security wevtutil cl Application fsutil usn deletejournal`
It’s worth noting that patching alone is not sufficient to prevent the propagation of the ransomware as it utilizes multiple techniques for spreading as described above.
References
[1] https://virustotal.com/en/file/027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745/analysis/
[2] http://www.hsc.fr/ressources/articles/win_net_srv/msrpc_srvsvc.html
[3] http://www.hsc.fr/ressources/articles/win_net_srv/msrpc_wkssvc.html
[4] https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/
Written by CDO Team
First published on 27/06/17
