With the world dealing with the Coronavirus crisis, cyber-criminals are taking advantage of the situation to spread new variants of ransomware via Coronavirus phishing campaigns.
The newest of these variants is the NetWalker.
Home-users, enterprises, government agencies and health organizations have reported to be attacked by NetWalker.
Two widely reported attacks using NetWalker were on the Toll Group, an Australian transportation and logistics company, and the Illinois Champaign-Urbana Public-Health District (CUPHD) website, which temporarily prevented health district employees from accessing certain files.
The attack forced the FBI and the U.S Department of Homeland Security step in, showing the severity of this crisis and how important it is to be familiar with this variant in order to prevent further attacks.
Overview of the NetWalker Payload
NetWalker ransomware was discovered in August 2019, it was initially named Mailto based on the extension that was appended to encrypted files, but analysis of one of its decryptors indicates that its name is NetWalker.
NetWalker compromises the network and encrypts all Windows devices connected to it.
When executed, NetWalker uses an embedded configuration that includes a ransom note, ransom note file names, and various configuration options.
So far, we have noticed that NetWalker spreads itself in two ways.
One way is via a VBS script that has been attached to Coronavirus phishing emails that execute the payload of the ransomware once it’s double-clicked or by opening the office documents that contain the VBS script inside.
The second method occurs through an executable file that been spread on the network, and once it has been executed by the user, without the right guards in place, it is game over.
As we see above, the file impostor claims to belong to ‘Microsoft’, pretending to be legitimate and safe.
Another indicator, is the high entropy levels this executable has. We can assume that the payload hides under the ‘.rsrc’ and ‘reloc’ sections, which tells us that the attacker tries to evade traditional AV’s mechanism from detecting this file by statically file scanning on the disk which is signature-based, by compressing the file with a unique format.
Once the file is executed, the following events flow will take place:
Process Hollowing Technique
The attacker uses a technique called Process hollowing to inject the payload into ‘explorer.exe’. Process hollowing occurs when a process is created in a suspended state then its memory is unmapped and replaced with malicious code.
Below we can see how the injection of the payload is located inside the explorer process.
After the injection of the payload to the legitimate ‘explorer.exe’ process occurred it spawned a new instance of ‘explorer.exe’ and the original executable process will be killed (58f13af3.exe). When a regular user looks at their task manager, they won’t see a suspicious behavior since the payload hides under a legitimate process.
Another verification that we have for the payload injection to the explorer is the path, which is in ‘SysWOW64’ while comparing to the real explorer process that is located in WINDOWS path we can relate that to the fact that the malicious file is 32-bit and an instance of a 32bit explorer will run through the ‘SysWOW64’ folder if the operating system is 64-bit.
Below we can see the path of the legitimate explorer.exe process, this legitimate explorer runs from WINDOWS because it’s a 64 bit operation system like it should be.
In order to maintain the persistency of the malicious file on the user’s host, the payload deletes the original executable from its location and drops it in the user ‘AppData\Roaming\’ folder and creates a registry key that will execute the file every time the host will startup.
The reason that attackers like to drop the malicious files to the ‘AppData’ is that it’s a hidden path that a regular user won’t notice that there is a malicious file in it, and you don’t have to have an administrator user to ‘write’ to this path, regular users also have ‘write’ permissions.
So far, we have seen the injection of the payload to the explorer and the persistency set to maintain the malware in the system.
The next step we see is related to the encryption technique, most of the files on the host are being encrypted and their extensions are being changed to ‘mailto[[email protected]].[generated-file-name]’ .
After we dig a little dipper to the payload, we found the config of the payload that contains the paths that will be excluded from encryption and a list of processes that were meant to be terminated if they exist.
For example, if a user will have a Word document running while the malware is being executed, it will be terminated immediately to avoid any encryption interruption.
software’s\processes that will be exclude from the encryption, for example:
*\program files*\vmware, **windows defender**,*media player, etc.
Files extensions that will be exclude, for example:
‘exe’, ‘msi’, ‘ps1’, ‘cmd’, etc.
Processes that will be killed to avoid interruption in the encryption:
Wordpad.exe, winword.exe outlook.exe, excel.exe, oracle.exe, ntrtscan.exe, *sql*, etc.
The exception of this path combined with the list of tasks to kill was meant to keep the functionality of the host while encrypting the relevant user files smoothly and allow the user to be able to pay the ransom.
Once the files encryption is complete, a ransom note with further instructions is being dropped in each folder that contains encrypted files.
The note will include a unique code and two email addresses that belong to the attackers.
When we dive into the payload memory strings to locate any signs that related to the ransomware note, we find obfuscated strings. After a deep lookup, we find the encoding type that our strings are encoded with – BASE64.
The ransomware note template after de-coding the strings with BASE64,
And the variables that will be attached to the template that includes the attacker email addresses,
Erasing Backup Copies
In order to erase all of the backup copies in the host, an instance of ‘vssadmin.exe’ has been spawned both from the first injected explorer and from the second instance that was spawned by the first one, both are running silently with the same command in order to erase the volume shadow copies and preventing backup copies from recovering.
NetWalker Variants in the Field
Another common way this ransomware is being distributed in the field is by phishing emails that are related to COVID-19 updates.
At the office, it’s common to be more aware of the kinds of emails coming through—there’s a certain vigilance about opening suspicious emails or clicking unknown links. At home, though, remote employees may let their guard down.
The attack flow starts with an email that contains an attachment that supposed to include updates and information regarding COVID-19, one of the most common ways is through an Office document such as ‘Word’ or ‘Excel’ that contains macros (series of commands and instructions that you group together as a single command to accomplish a task automatically) that will execute the ‘VBS’ script.
Double-clicking the masquerading file or opening the malicious Office document will start executing the payload by using ‘wscript.exe’ which is a service that provides scripting abilities for Windows operating system.
A new executable file will be dropped by the name ‘qwSw.exe’ in the user temporary directory ‘AppData/local/temp’, and will be executed.
Once the executable file is running, the following steps will occur:
A registry key will be set to maintain persistency of the payload on the host in the following: ‘HKLM/software/’ and ‘HKCU/software/’
All of the files will be encrypted and their extensions will be changed except for the files the attacker exclude in order to allow the host to be functional.
Vssadmin.exe service will be launched to delete shadow copies of the user backups so files won’t be restored.
A ransom note will be dropped in several locations on the host with instructions.
We see two main techniques that evolve different attack flows which will eventually lead to the same result: demanding money to recover your data.
A process hollowing doesn’t occur when the VBS script is executed as compared to the ‘EXE’ file.
The location of the created registry keys is a bit different, the VBS payload was able to set a registry key in the ‘HKCU’ and ‘HKLM’ which includes the entire machine compared to the executable which was able to reach the ‘HKCU’ – current user only.
The rest of the events are pretty much the same.
Cynet VS NetWalker
Cynet detects and prevents this attack by using several mechanisms:
Anti-Virus/AI – This alert triggers when Cynet’s AV/AI engine detects a malicious file that was dumped on the disk.
ADT – Ransomware Heuristic – This alert triggers when Cynet detects suspicious behavior which can be associated with Ransomware (such as an attempt to delete shadow copies.)
ADT – Malicious Binary – This alert triggers when Cynet detects a file that is flagged as malicious in Cynet’s endpoint scanner built-in threat intelligence database.
Memory Pattern – This alert triggers when Cynet detects memory strings which are associated with Malware or with malicious files.
In order to clean up an infected host, it crucial to revert each of the steps taken by the payload of the attack.
Be aware of phishing emails that contain an attachments
Clean the Registry for any of the manipulated values (once infected).
Delete the malicious file from the paths mentioned under (once infected).
Blacklist the SHA256 of the ransomware.
Enabling the heuristic, AV and driver mechanisms.
If necessary – format the host and install a clean version of Windows (once infected).