Crypsis Group discovered a custom-written, new ransomware variant, now dubbed PwndLocker, during a client engagement beginning in early February. Crypsis Group forensic examiners have been analyzing this recently publicized variant for the past month; in our observations, this ransomware shows significant deviations from any ransomware behaviors and characteristics our analysts have traditionally encountered. It was developed entirely as location-independent code (shellcode) and implements its own custom encryption algorithm. This is unique, as location-independent code is traditionally reserved for secondary downloaders, or stealth-oriented implants, as it can be time consuming to create and challenging to implement correctly. In this case, the use of location-independent code appears to be a countermeasure for automated detection tools. This ultimately prevents the victim from identifying the ransomware before encryption takes place.
However, Crypsis determined that the lack of asymmetric encryption being used in the ransomware made it plausible decryption was possible without requiring the threat actor’s decryption key—this has now been validated in a recent article in Bleeping Computer.
- Location-independent code (shellcode)
- Non-continuous and overlapping functions using conditional jumps
- Pulls string from its own (executing) segments as if they were on the stack
- Initial execution via scheduled task
- Xor decoding stub
- Allocates a segment that is used to store local AND global variables
- Resolves a number of APIs and stores their pointers
- Elevates its privileges
- Kills a large variety of whitelisted process and services
- Deletes its original files via hard-coded paths, indicating there is no or limited persistence on the part of the threat actor
- Contains a blacklist of keywords for files to skip encryption, including some references to AV products
For the Experts – Technical Details:
Based on Crypsis’s current analysis, it appears that the ransomware was pre-placed on the system by the threat actor. The ransomware consists of a batch script and fake AVI file with a legitimate AVI file header. Execution of the ransomware begins via the batch script, which contains an encoded PowerShell command that copies and executes the next stage out of the fake AVI file.
The base64 string contained here is nearly 8,000 characters long.
VirtualAlloc, Memset, and CreateThread are dynamically resolved so executable code can be loaded into the PowerShell process.
The code is copied out of a fake AVI file with a valid AVI header. On the left is the fake avi file; the right shows a legitimate avi file.
Immediately upon execution, a small decoding stub is executed that decodes the rest of the code segment via xor.
Before the real work begins, a number of API functions need to be resolved. To support this VirtualAlloc, LoadLibraryA, and GetProcAddress are resolved via the PEB. A new segment is then created via VirtualAlloc that will be used to save both local and global variables. This segment will be used by the main thread, and later on by file recursion and encryption threads.
Next, a chain of functions are executed resolving various API pointers, which will be needed. Notably, only the last argument (module name for LoadLibrary, and function name for GetProcAddress etc.) is pushed onto the stack. Instead of pushing all the arguments on the stack explicitly, the call instruction is abused such that the address of the following “instruction” is placed on the stack, but this address actually refers to an argument of the API function to be called in the next part of the chain. This technique is used throughout execution of the ransomware for loading string arguments.
CloseHandle, CreateFileW, and CreateThread are implicitly placed on the stack before a handle to kernel32 is explicitly pushed.
At the end of the chain, DeleteFileA is used to delete four files related to the malware's execution: the original avi file, two batch files (one of which launched the original PowerShell command), and an xml file.
Next, it attempts to give itself debug privileges, after which it calls a function that enumerates all running processes (via calls to CreateToolhelp32Snapshot, and Process32First/Next), checks them against an extensive blacklist of processes and services, and terminates them using taskkill and net stop commands.
The main encryption loop receives a list of drive letters, creates a new thread for each one, and then waits for them to finish. Finally, it attempts to delete any volume shadows associated with the drives using vssadmin, and then exits by calling ExitProcess.
Some secondary information from the main thread is copied over into an offset farther down in the working memory segment (targeted drive letter, resolved API addresses, the virtual base of the code segment, and other variables).
The thread then begins its recursion loop, which isn't that different from what would be expected of other ransomware. There are a number of checks against different lists of blacklisted keywords in the file path, including a handful of different antivirus products, the ransom note that is produced in each directory processed, and critical system directories and file extensions.
Additionally, it specifically checks for paths ending in .bac or .bak and, if found, deletes them by calling DeleteFileW.
If the current path passes all of these checks, a new thread is created for it, which carries out the encryption of the file data.
For some unknown reason, the threat actor opted to implement their own "encryption" algorithm instead of using the Windows Cryptographic APIs. As stated above, the characteristics of the encryption algorithm led us to believe decryption was possible. This was proven correct by a recent Bleeping Computer article.
Due to the prolific growth of ransomware, threat actors are attempting novel approaches to differentiate themselves and collect profit. The ransomware and its corresponding encryption algorithm were custom created by the threat actor, leaving open the possibility for error on the part of the attacker as they test their tool on the victim. Crypsis found no evidence of successful data exfiltration or of the ransomware spreading to other devices on this victim’s network. Crypsis observed the threat actor attempting to contact the victim, leading to the assumption that they may have been trying to confirm the successful encryption of data with the victim themselves.
We are in the early stages of evaluating this variant, and more will likely come to light in the coming weeks and months. Crypsis will continue to update this blog with additional best practices and technical tips.
Best Practices to Defend Against PwndLocker Now!
- Regularly take and test backups; ensure the backups are stored off network and are protected so threat actors cannot gain access and destroy the backups to prevent recovery
- Adopt account administration best practices across the organization including:
- Requiring unique and complex passwords that are at least 15 characters in length so they cannot be easily brute forced
- Integrating multi-factor authentication for all remote access and business email accounts to greatly reduce the organization’s attack surfaces
- Limiting the use of privileged accounts and not reusing local administrator account passwords to prevent initial access by attackers and lateral movement across the network
- Disable any direct external Remote Desktop Protocol (RDP) access:
- Ensure all external remote administration is conducted through an enterprise-grade multi-factor VPN
- Segregate networks, leveraging secure VLANS, and move away from flat networks
- Leverage external logging to lengthen the amount of log data available
- Understand where sensitive data lives and create strong access control to that data, which can be monitored and audited granularly
- Institute a robust employee security awareness culture and training program that is tailored to employee roles and responsibilities
- Conduct employee and leadership security training bi-annually to ensure continuous security awareness
- Make the training incrementally harder, to train on more sophisticated tactics
- Have a tested and comprehensive Incident Response and Remediation Plan (IRRP)—be ready to respond should an incident occur; test the plan and review it regularly, so that you know what to do and whom to turn to should an incident occur.