Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

An In-depth Look at MailTo Ransomware, Part Two of Three


In Part One of this series, we discussed how MailTo ransomware installs itself on the victim's system and then initialized itself with configuration options and persistence via the registry. Today we're going to continue our deep dive by looking into how MailTo executes and injects itself into the system.

Injection and Explorer.exe (1)

After the MailTo ransomware has finished initializing, it begins the process of starting a new “explorer.exe” instance and injecting a copy of itself into it. Two different methods of execution transfer can be used but in either case, it maps itself into the process in the same way.

The ransomware maps itself into an instance of “explorer.exe” by using the API function “NtMapViewOfSection” and then manually fixes its relocations rather than using the Windows API “LoadLibrary” or “LdrLoadDll”. This method has the advantage of not being linked in the “PEB->InLoadOrderModuleList” member and being mapped outside of the expected memory range (above the executable mapped image base).

ManualMappedFigure 1 – Manually Mapped Ransomware Inside Explorer.exe


The next step after the ransomware has mapped itself into the “Explorer.exe” process, is to transfer execution to the ransomware. The ransomware has two different methods to do this. The first method we will call “Debug Injection” and the second method “APC Injection”. Debug Injection is used if the operating system is newer than Windows 2000. APC injection is used if debug injection fails or the minimum operating system version requirements are not met.

Debug Injection

With the Debug Injection method, the ransomware first uses the function “CreateProcessW” with the “DEBUG_ONLY_THIS_PROCESS” creation flag. Creating the “Explorer.exe” process in this state allows the ransomware to suspend the process and modify its memory. This is when then ransomware calls “NtMapViewOfSection” to copy itself to the process and fix its relocations. Afterward, it calls “NtGetContextThread” to receive the thread context of the main thread for “Explorer.exe”. It then sets the instruction pointer (EIP) to the mapped ransomware’s selected entry point. “ContinueDebugEvent” is then called to continue the execution of “Explorer.exe” and the following call is to “DebugActiveProcessStop” which finally detaches the ransomware’s debugger from the process.

DebugInjectionFigure 2 – Method Used for Debug Encryption


APC Injection

With this method, the ransomware will begin by starting the “Explorer.exe” process as a suspended process using the “CreateProcess” Windows API function and “CREATE_SUSPENDED” flag. The ransomware then manually maps itself into “Explorer.exe” using the same method described in Debug Injection. To transfer execution however, the ransomware will use the undocumented “NtQueueApcThread” Windows API function and lastly call “NtResumeThread” to continue the process from its suspended state.

APCThreadInjectionFigure 3 – Method Used for APC Injection


Purpose of Injected Routine / Explorer.exe (1)

The main purpose of the injected routine inside of “Explorer.exe” is to perform file encryption of shared network drive, network paths, and local disk drives. The ransomware also performs uninstallation and deletes shadow copies. The routine also will create a second “Explorer.exe” instance if the “useKill” option in the configuration is set to true. The second “Explorer.exe” instance is injected into using the same discussed techniques and will serve the purpose of killing processes, services, and scheduled tasks.

InjectedRoutine01Figure 4 – Entry Point for Injected Ransomware


Explorer.exe (2)

The second “Explorer.exe” is started from the first “Explorer.exe” injection routine and is responsible for killing processes, services, and scheduled tasks. Each of these objectives is achieved in their own thread.

Kill Processes

MailTo kills processes listed in the ransomware configuration under the field “kill->prc”. Many of the listed names appear to be processes that could potentially be performing an operation on a file that could prevent the ransomware from encrypting the file.

Process killing in MailTo works using the Windows API function “NtQuerySystemInformation” and more specifically, with the “SystemProcessInformation” class which is used to return a list of all currently running processes on the system.

KillProcessesFigure 5 – Method Used to Kill Processes


These processes are iterated over and have their image names hashed with CRC32. The CRC32 hash is compared against its own process image name hash and two other hard-coded hashes. A list of mostly wildcarded process names resides in the ransomware’s configuration file (see Part One). The image base name of the iterated processes is compared with each of the wildcarded process names in the configuration (found under ‘kill->prc’).

ShouldKillProcessesFigure 6 – Method Used to Compare Whitelisted Processes


If the comparison results in a match, the ransomware will call the “OpenProcess” and “NtTerminateProcess” Windows API functions to terminate the process.

Kill Services

MailTo has the capability to kill listed services for what appears to be the same reason as with killing processes as again, the listed services appear to be common services which could be performing an operation on a file which would stop the ransomware from being able to encrypt the file the service is operating on. The listed services can be found in the configuration under the field “kill->svc”.

Services are killed throughout three functions in this ransomware.

  • Iterate all the currently running services and match them against the configuration blacklist.
  • Iterate all dependent services on the matched service.
  • Stop the dependent services from running as well as the originally matched service.

The expected outcome of this capability is for the services in the blacklist to be stopped. However, this does not happen and with further inspection, it was discovered that the malware author made a critical mistake that prevented any services from being stopped. Simply put, service killing in this sample does not work.

The mistake in question is related to step one of the process of iterating all the currently running services and match them with the blacklist. That part never takes place. In fact, we even discovered code to perform that step one but it simply was not used. When the time comes for the ransomware to kill services, it tries to begin with step two, which does not make sense because there is no matched service for step two to work with. What happens is step two is given the value zero which is supposed to be a handle to a service. Step two will check if the given value is zero and if this comparison is true, step two will simply return right there and then, consequentially doing nothing as step three is never performed. The mistake is that step two is always given the value zero.

*StartRoutine() is a wrapper for CreateThread()

InjectedEntryPoint_Anotated_KillServiceByHandle - CopyFigure 7 – Failed Implementation of Stopping Services


The code “if (!lpThreadParameter)” checks to see if the parameter (“lpThreadParameter”) is zero which as we can see in the above image will always evaluation as true.

FailedServiceKillingFigure 8 - Failed Implementation of Stopping Services (2)


The below image is a part of a function which performs the first step of the process for stopping services. This function shows the correct usage for continuing to step two of the process for stopping services. At the bottom of the image, you can see the code “StartRoutine(KillServiceByHandle, param);” the “param” will contain a handle to a service that was matched against the configurations blacklist. This means that step two will be able to correctly function and move onto step three where the service will be stopped as well as other services which depend on the matched service.

KillServices_Figure 9 – Correct Implementation That Should Have Been Used to Stop Services.


Kill Scheduled Tasks

The MailTo ransomware makes use of the “CoCreateInstance” Windows API function to get access to the ITaskService interface which will then lead to getting access to the ITaskFolder interface through the ITaskService->lpVtble->GetFolder() function.

KillScheduledTasks01Figure 10 – Initializing ITaskService and ITaskFolder


The ITaskFolder interface is used in conjunction with other functions to iterate over task names, paths, and arguments, then compare them to a blacklist of words in the configuration.

TasksFigure 11 – Iterating Non-Disabled Schedules Tasks and Comparing Against Blacklists


If any of the words in the configuration are a part of the task name, path, or arguments, the scheduled task will be stopped, disabled, and then deleted.

KillTaskScheduleFigure 12 – Deleting Tasks

MailTo is now all set to begin encryption.



So in this part of our deep-dive analysis, we saw how MailTo inserts itself as a running process and kills various processes and services to ensure the best environment to begin to take your data hostage. In our next part, we will look at how MailTo gets to business encrypting your valuable files.

Full Series

An In-depth Look at MailTo Ransomware, Part One
An In-depth Look at MailTo Ransomware, Part three

Latest SpiderLabs Blogs

Welcome to Adventures in Cybersecurity: The Defender Series

I’m happy to say I’m done chasing Microsoft certifications (AZ104/AZ500/SC100), and as a result, I’ve had the time to put some effort into a blog series that hopefully will entertain and inform you...

Read More

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More