A previously unknown malware loader named SVCReady has been discovered in phishing attacks, featuring an unusual way of loading the malware from Word documents onto compromised machines.
More specifically, it uses VBA macro code to execute shellcode stored in the properties of a document that arrives on the target as an email attachment.
According to a new report by HP, the malware has been under deployment since April 2022, with the developers releasing several updates in May 2022. This indicates that it is currently under heavy development, likely still at an early stage.
However, it already supports information exfiltration, persistence, anti-analysis features, and encrypted C2 communications.
SVCReady starts with an email
The infection chain begins with a phishing email carrying a malicious .doc attachment.
However, contrary to the standard practice of using PowerShell or MSHTA via malicious macros to download payloads from remote locations, this campaign uses VBA to run shellcode hiding in the file properties.
As shown below, this shellcode is stored in the properties of the Word document, which is extracted and executed by the macros.
By splitting the macros from the malicious shell code, the threat actors attempt to bypass security software that may normally detect it.
“Next the shellcode, which is located in the document properties, is loaded into a variable. Different shellcode is loaded depending on if the architecture of the system is 32 bit or 64 bit,” explains HP’s report.
The appropriate shell code is loaded tino memory from where it will use the Windows API function “Virtual Protect” to acquire executable access rights.
Next, the SetTimer API passes the address of the shellcode and executes it. This action results in a DLL (malware payload) dropping into the %TEMP% directory.
A copy of “rundll32.exe”, a legitimate Windows binary, is also placed in the same directory under a different name and is eventually abused to run SVCReady.
The new SVCReady malware loader
The SVCReady malware begins by profiling the system via Registry queries and Windows API calls and sends all gathered information to the C2 server via an HTTP POST request.
Communication with the C2 is encrypted using an RC4 key. HP analysts comment that this function was added in May during one of the malware’s updates.
The malware also makes two WMI queries on the host to figure out if it’s running on a virtualized environment and enters sleep for 30 minutes if it does to evade analysis.
The persistence mechanism currently relies upon creating a scheduled task and a new registry key, but due to errors in the implementation, the malware will not launch after a reboot.
The second information gathering phase begins after all that, and it involves screenshots, extracting “osinfo”, and sending everything to C2.
SVCReady connects to the C2 every five minutes to report its status, receive new tasks, send stolen information, or validate the domain.
The functions supported by SVCReady at this time are the following:
- Download a file to the infected client
- Take a screenshot
- Run a shell command
- Check if it is running in a virtual machine
- Collect system information (a short and a “normal” version)
- Check the USB status, i.e., the number of devices plugged-in
- Establish persistence through a scheduled task
- Run a file
- Run a file using RunPeNative in memory
Finally, the malware can also fetch additional payloads. HP analysts have observed one case on April 26, 2022, where SVCReady dropped a Readline stealer payload on the infected host.
Links to TA551
HP reports seeing links to past TA551 (Shatak) campaigns such as lure images used in the malicious documents, resource URLs used for fetching the payload, etc. Previously, the phishing gang used these domains to host Ursnif and IcedID payloads.
TA551 has been linked to various malware operators and even ransomware affiliates, so the relation to SVCReady is currently unclear and could be a distribution partnership.
However, since the malware appears to be in an early development phase, testing it via TA551 seems unlikely, so it might be the group’s own malware project.
Source: www.bleepingcomputer.com