As organizations were scrambling to deal with the lockdowns associated with the global COVID-19 pandemic, a new wave of ransomware attacks began. The ransomware, called ProLock, is a successor to PwndLocker, a ransomware strain that emerged late in 2019.
PwndLocker’s distribution was short-lived, primarily because it was discovered that the keys needed to decrypt files could be recovered from the malware itself without paying a ransom. The retooled ProLock ransomware, which emerged in March, resulted in the opposite problem: in May, the Federal Bureau of Investigation issued an alert warning that victims who had paid the ransom demanded by ProLock’s operators had received a faulty decryptor that corrupted files it “decrypted.”
The faulty debugging may be connected to the unusual way in which ProLock encrypts files: it skips files smaller than 8,192 bytes, and starts encrypting larger files after the first 8,192 bytes. The result is files that are partially readable, and partially encrypted.
Sophos initially encountered ProLock when it was caught by Intercept X’s CryptoGuard component on a customer network in mid-March. The malware uses a Powershell-based dropper that extracts Windows executable code from an accompanying graphics file—or at least, a file with a graphics format extension. And all of its malicious activities are concealed within legitimate Windows processes.
According to the FBI “flash”, victims of ProLock have included healthcare organizations, government agencies, financial institutions, and retailers. Victims are directed to contact the ProLock operators through a Tor-based ( .onion) web portal or a ProtonMail email address. Following the current trend in ransomware set by Maze, ReVil, and other established extortion operations, the ProLock actors “instruct victims to pay the ransom in several days, threatening to release the victims’ data on social media and public websites,” the FBI reports.
Picking the locks
ProLock has gained access to victims’ networks in several ways, with some leveraging third-party exploitation. In May, Oleg Skulkin, Senior Digital Forensics Analyst at Group-IB, told BleepingComputer that evidence he had uncovered showed some ProLock victims were infected through scripts executed by the QakBot banking trojan.
The FBI also cited Qakbot as one of ProLock’s means of initial access, as well as phishing emails and improperly configured Remote Desktop Protocol (RDP) servers, and remote access connections over RDP with stolen user credentials. The earliest detection of ProLock by Sophos was on a customer’s compromised server, most likely through an exploit of a Remote Desktop Protocol connection.
The ProLock actors use their access to conduct some network reconnaissance, as well as to potentially steal data before launching their ransomware attack. They then use the stolen or compromised credentials, built-in Windows tools and scripts to propagate the ransomware across the network.
When the time came to release the ransomware, we found in the case we analyzed that four files were dropped onto targeted systems, downloaded from a remote server (IP addresses are in the Indicators of Compromise file posted to SophosLabs’ GitHub).
C:\ProgramData\WinMgr.bmp C:\ProgramData\WinMgr.xml C:\ProgramData\clean.bat C:\ProgramData\run.bat
Chain of destruction
ProLock malware depends on Windows batch scripts, the Windows Task Scheduler (through the schtasks.exe command line utility) and PowerShell to launch its attack.
The ransomware chain is set off with the execution of run.bat, which creates a scheduled Windows task to execute clean.bat using the contents of WinMgr.xml to configure the task. When it is launched by the scheduler, clean.bat executes a base64-encoded PowerShell script that extracts the ProLock executable file encoded into the image file WinMgr.bmp, loads it into memory, and executes it—passing parameters that control the encryption. (When executed without the Powershell script, the executable runs—but doesn’t encrypt any files.)
The usual suspects
One of the ProLock samples we examined hides some of its contents with a self-modifying section of code, which conceals text strings and other elements from analysis. As is common in malware development, the ProLock program is deliberately set not to allow debugging, to make it more difficult for researchers to run it in a controlled fashion.
The malware decodes the self-modifying section, imports DLLs and sets up the functions it will use. Then it launches a new thread and puts the first thread to sleep—an anti-analysis trick.
The malware traverses the registry looking for security policy settings that might cause trouble. For some reason, it switches some of Internet Explorer’s security policy settings, turning off the mapping of Universal Naming Convention paths to IE’s “Intranet” zone and turning on automatic intranet mapping. (The list of registry changes is included in the indicators of compromise file on SophosLabs’ Github here.) Then it starts hunting for applications and services that might get in the way of total data destruction.
Using a function call to Windows’ CreateToolhelp32snapshot.dll, the malware takes a snapshot of all running processes, and begins checking them against a list (which can be found here on SophosLabs’ GitHub), shutting down the ones that match the list with Windows’ taskkill.exe utility (through a ShellExecuteA function call). The processes include common desktop applications (including Microsoft Office applications), databases, the Firefox browser and Thunderbird mail client, and a number of security software components. These sorts of processes are stopped by ransomware in order to make sure no user files are locked open—allowing the malware to encrypt them without resistance.
Then, using net.exe, the ransomware code attempts to shut down a list of more than 150 services associated with enterprise applications, security software, and backups. A full list of the processes and services targeted by the ransomware is posted on SophosLabs’ GitHub here(services) and here (processes). Again, the goal is to prevent anything from interfering when the encryption begins. These service shutdown commands are issued with Windows’ net.exe utility.
Next, to prevent local file recovery, ProLock deletes the “shadow copy” of local files by executing the following commands to vssadmin.exe (Windows’ Volume Shadow Copy Service):
delete shadows /all /quiet resize shadowstorage /for=c: /on=c: /maxsize=401MB resize shadowstorage /for=c: /on=c: /maxsize=unbounded
All of this effort is extremely noisy, and processor intensive. And then the disk-intensive part begins.
Semi-random mayhem
With all of the guards out of the way, the ransomware begins to check what media is mounted and traverses the directory structure of any local or network-mapped drives. It skips over executable files (including .php files for websites), and leaves applications intact. All of this malicious activity is executed through the powershell.exe process.
As it reads each file, it checks the length. If the file is under 8,192 bytes (0x2000 in hexidecimal), it skips the file. Otherwise, it begins encrypting the file, starting after the 8,192nd byte. After encrypting a file, the extension .prolock is appended to its file name (for example, a_very_large_text_file.txt becomes a_very_large_text_file.txt.prolock.)
As the malware finishes the encryption of the contents of each folder, it writes a file to the folder named [HOW TO RECOVER FILES].TXT. This contains the ransom note.
When all the folders have been traversed, the ransomware sounds the system alert tone, and drops a ransom note on the desktop.
The ransom note itself is hard-coded into the ransomware as a text string—including the .onion website address and the victim’s “user ID”. In fact, across the ProLock samples we examined, the ransom notes were exactly the same, including the “user ID”—despite other differences in the code. Given that these samples came from separate sources, that would suggest that multiple ProLock victims were given the same “user ID,” which wouldn’t matter in any case because of the targeted way ProLock is deployed.
Triple indemnity
As with other targeted ransomware attacks, ProLock’s encryption of files should be considered just the final act in the attack. The attackers need to have gained administrative credentials to spread the malware, which means that they’ve had largely unfettered access to victims’ data. While we’ve seen no direct evidence thus far of data theft, the tools used to gain access by ProLock’s actors give them wide access to network resources and data. And it’s possible that other malware (such as QakBot) has also taken root—malware that ProLock would leave untouched.
Even if victims pay, there’s the chance (thanks to the broken decryptor) that data will be lost or made more expensive to recover. Bringing in the expertise of a ransomware response team may be required to recover.
There are several concrete steps that organizations can take to prevent these types of attacks. Protecting remote network access is key to stopping these types of targeted attacks, by putting RDP access behind a virtual private network and using multi-factor authentication for remote access. As with all ransomware threats, maintaining offline backups and malware protection for both desktops and servers also hardens defenses against attacks like ProLock. And up-to-date endpoint protection tools (such as Intercept X and CryptoGuard) can be effective in blunting attacks that get past other defenses, or at least minimizing the damage done by an intrusion.
Sophos now blocks variants of ProLock as Troj/Agent-BEKP and Troj/Ransom-FVU, and through heuristic analysis by Sophos ML, as well as through CryptoGuard.
Acknowledgements
SophosLabs wishes to acknowledge the contributions of Hajnalka Kópé , Anand Aijan, Andrew Brandt, Rahul Dugar, and Gabor Szappanos.