This blog post was authored by Ankur Saini and Hossein Jazi
The Malwarebytes Threat Intelligence team has identified a new Remote Access Trojan we are calling Woody Rat that has been in the wild for at least one year.
This advanced custom Rat is mainly the work of a threat actor that targets Russian entities by using lures in archive file format and more recently Office documents leveraging the Follina vulnerability.
Based on a fake domain registered by the threat actors, we know that they tried to target a Russian aerospace and defense entity known as OAK.
In this blog post, we will analyze Woody Rat's distribution methods, capabilities as well as communication protocol.
Based on our knowledge, Woody Rat has been distributed using two different formats: archive files and Office documents using the Follina vulnerability.
The earliest versions of this Rat was typically archived into a zip file pretending to be a document specific to a Russian group. When the Follina vulnerability became known to the world, the threat actor switched to it to distribute the payload, as identified by @MalwareHunterTeam.
The following diagram shows the overall attack flow used by the threat actor to drop Woody Rat:
Woody Rat distribution methods
Archive files
In this method, Woody Rat is packaged into an archive file and sent to victims. We believe that these archive files have been distributed using spear phishing emails. Here are some examples of these archive files:
Follina vulnerability
The threat actor is using a Microsoft Office document (Памятка.docx) that has weaponized with the Follina (CVE-2022-30190) vulnerability to drop Woody Rat. The used lure is in Russian is called "Information security memo" which provide security practices for passwords, confidential information, etc.
The threat actor has left some debugging information including a pdb path from which we derived and picked a name for this new Rat:
A lot of CRT functions seem to be statically linked, which leads to IDA generating a lot of noise and hindering analysis. Before initialization, the malware effectively suppresses all error reporting by calling SetErrorMode with 0x8007 as parameter.
As we will see later, that malware uses multiple threads and so it allocates a global object and assigns a mutex to it to make sure no two clashing operations can take place at the same time. This object enforces that only one thread is reaching out to the C2 at a given time and that there are no pending requests before making another request.
The malware communicates with its C2 using HTTP requests. To uniquely identify each infected machine, the malware derives a cookie from machine specific values. The values are taken from the adapter information, computer name and volume information, and 8 random bytes are appended to this value to avoid any possible cookie collisions by the malware.
A combination of GetAdaptersInfo, GetComputerNameA and GetVolumeInformationW functions are used to retrieve the required data to generate the cookie. This cookie is sent with every HTTP request that is made to the C2.
To evade network-based monitoring the malware uses a combination of RSA-4096 and AES-CBC to encrypt the data sent to the C2. The public key used for RSA-4096 is embedded inside the binary and the malware formulates the RSA public key blob at runtime using the embedded data and imports it using the BCryptImportKeyPair function.
The malware derives the key for AES-CBC at runtime by generating 32 random bytes; these 32 bytes are then encrypted with RSA-4096 and sent to the C2. Both the malware and C2 simultaneously use these bytes to generate the AES-CBC key using BCryptGenerateSymmetricKey which is used in subsequent HTTP requests to encrypt and decrypt the data. For encryption and decryption the malware uses BCryptEncrypt and BCryptDecrypt respectively.
knock - This is the first HTTP request that the malware makes to the C2. The machine-specific cookie is sent as part of the headers here. This is a POST request and the data of this request contains 32 random bytes which are used to derive AES-CBC key, while the 32 bytes are RSA-4096 encrypted.
The data received as response for this request is decrypted and it contains the url path to submit (/submit) the additional machine information which the malware generates after this operation.
submit- This endpoint request is used to submit information about the infected machine. The data sent to the C2 is AES-CBC encrypted. Data sent via submit API includes:
The malware currently detects 6 AVs through Registry Keys; these AVs being Avast Software, Doctor Web, Kaspersky, AVG, ESET and Sophos.
ping - The malware makes a ping GET http request to the C2 at regular intervals. If the C2 responds with "_CRY" then the malware proceeds to send the knock request again but if the C2 responds with "_ACK" the response contains additional information about which command should be executed by the malware.
The malware supports a wide variety of commands which are classified into _SET and _REQ requests as seen while analyzing the malware. We will dive into all these commands below in the blog.
The malware uses a specific thread to communicate with the C2 and a different one to execute the commands received from the C2. To synchronize between both threads, the malware leverages events and mutex. To dispatch a command it modifies the state of the event linked to that object. We should note all the communications involved in these commands are AES encrypted.
_SET Commands
_REQ Commands
INFO command
SharpExecutor and PowerSession Commands
Interestingly, the malware has 2 .NET DLLs embedded inside. These DLLs are named WoodySharpExecutor and WoodyPowerSession respectively. WoodySharpExecutor provides the malware ability to run .NET code received from the C2. WoodyPowerSession on the other hand allows the malware to execute PowerShell commands and scripts received from the C2.
WoodyPowerSession makes use of pipelines to execute these PS commands. The .NET dlls are loaded by the malware and commands are executed via the methods present in these DLLs:
SharpExecutor and PowerSession methods
We will look at the commands utilising these DLLs below:
After creating the command threads, the malware deletes itself from disk. It uses the more commonly known ProcessHollowing technique to do so. It creates a suspended notepad process and then writes shellcode to delete a file into the suspended process using NtWriteVirtualMemory. The entry point of the thread is set by using the NtSetContextThread method and then the thread is resumed. This leads to the deletion of the malware from disk.
This very capable Rat falls into the category of unknown threat actors we track. Historically, Chinese APTs such as Tonto team as well as North Korea with Konni have targeted Russia. However, based on what we were able to collect, there weren't any solid indicators to attribute this campaign to a specific threat actor.
Malwarebytes blocks the Follina exploit that is being leveraged in the latest Woody Rat campaign. We also already detected the binary payloads via our heuristic malware engines.
Woody****Rat:
C2s:
Follina Doc:
Памятка.docx
ffa22c40ac69750b229654c54919a480b33bc41f68c128f5e3b5967d442728fb
Follina html file:
garmandesar.duckdns[.]org:444/uoqiuwef.html
Woody Rat url:
fcloud.nciinform[.]ru/main.css (edited)
The post Woody RAT: A new feature-rich malware spotted in the wild appeared first on Malwarebytes Labs.