In Part One of this series, we discussed how MailTo ransomware installs and configures itself on the victim's system and in Part Two we discussed how the malware, executes and injects itself into the system. In this post, we take a look at what makes ransomware different than other malware and gives it its deadly bite, encryption.
Just before the encryption routine begins, the MailTo ransomware performs the following tasks:
We found that the ransomware uses this implementation of curve25519:
This is implemented to create a key to be used with a ChaCha stream cipher to encrypt files. It is not possible to decrypt any encrypted files without the private key of the ransomware owners.
MailTo encrypts the following locations using a ChaCha stream cipher:
The MailTo ransomware has three main threads that kick off the encryption, each thread having its own purpose. One of these threads is aimed at encrypting the local drive while the other two are targeted towards encrypting shared network locations.
The first thread created for the encryption process serves the roll of encrypting the local disk drives via the API function “GetLogicalDriveStringsW”. This function will return a list of drives and shared network locations. This routine will begin creating threads for every file and directory to encrypt on the found drives. It attempts to connect with the network locations using the current user’s access token and via the API functions “WNetUseConntectionW” and “WNetAddConnection2W”.
The second thread created will again perform “GetLogicalDriveStringsW” to get a list of drives as well as shared network locations. In this thread, the drives are filtered for only network drives. Before connecting to the network locations, the ransomware call “ImpersonateLoggedOnUser” in order to attempt to gain access to the network locations using different access tokens collected from logged-in users.
The third thread will act similar to the second created thread in terms of impersonating all currently logged on users but will collect shared network drives in a different manor. “GetNetShares” and “WNetEnumResourceW” are used to iterate over shared network drives and paths. “GetNetShares” will also pick up hidden network shares such as “IPC$” and “Admin$”.
When it comes to encrypting an individual file, the ransomware is quite robust in ensuring that it will encrypt that file. When we say this, we mean if a process or service has a hold on a file that the ransomware wants to encrypt, the ransomware will kill that process or service in order to do so. If the ransomware does not have access to a file or network path, it will iterate all duplicated access tokens of users logged onto the machine and use that token in an attempt to encrypt the file. If the ransomware was shut down and only partially encrypted a file, but later executed again, it will check the last four bytes of the file for a CRC32 hash of their public ECC key. If the four bytes match the CRC32 hash of their public key, the ransomware will know that the file was fully and successfully encrypted.
When the MailTo ransomware has finished encrypting, it will open notepad with a ransomware note.
Figure 1 – Ransomware Note
After the ransomware note has been displayed, MailTo deletes the following entries from the system if they exist:
Shadow copy deletion occurs after MailTo uninstalls itself from the system. “vssadmin.exe” is used with the following command for shadow copy deletion:
“vssadmin.exe delete shadows /all /quiet”
Shadow copy deletion using this simple vssadmin command is typical of many ransomware. Interestingly, shadow copy deletion also occurs one additional time during the execution of the injected entry point of Explorer.exe (2).
Figure 2 – DeleteShadowCopies() call inside of Explorer.exe (2)
The MailTo ransomware is complex ransomware which effectively does its job of encrypting files. What makes MailTo tricky is its ability to leave no stone unturned when it comes to encrypting files. The ransomware has been designed in a careful way to ensure that its privileges are exhausted to the fullest extent by enumerating every logical drive and network share through impersonated user accounts. The ransomware also makes sure that it destroys any handles to files that are not its own. Even if a service or process is making changes to a file, the ransomware will eliminate that process/service and encrypt the file. The ransomware also sets up a persistent registry key and only removes it once the encryption has been complete.
MailTo does its best to minimize its detection vectors by deleting itself, hiding its imports, and injecting into processes using stealthy techniques. MailTo avoids the use of suspicious Windows APIs as much as it can by using the undocumented windows functions and keeping away from the Windows crypto API. Even though MailTo has its flaws such as with service termination, this ransomware will successfully encrypt files on a system and mapped network drives without the possibility of decrypting them without the ransomware private key.
MailTo is getting more and more popular, so stay safe and keep offline or unconnected backups of your important data.
An In-depth Look at MailTo Ransomware, Part One
An In-depth Look at MailTo Ransomware, Part Two
MailTo Sample SHA256: 58e923ff158fb5aecd293b7a0e0d305296110b83c6e270786edcc4fea1c8404c