Analysis of packed variation of Agent Tesla
For reverse engineering analysis, the following file was provided:
- OUTSTANDING STATEMENT.xlz.exe
A24BF02CE43A846463532E46211962EC7E883E682ABBDE61F922FCD46FC301BC
General Description
In December 2020, one of our tLab system clients, the Center for the Development of Human Resources JSC, received malicious software on their corporate email. The malware was not detected at the static, signature level by antivirus software, but at the behavioral and heuristic levels by the tLab system.
Based on the results of the initial assessment, as part of the technical support of the tLab system, the sample was sent out to our malware reverse engineering laboratory for further deep manual analysis.
The examination results revealed it was a zero-day threat. The date of creation of the sample matches the day of its discovery.
The findings were published later on Center for the Development of Human Resources JSC
The tLab system dynamic and static analysis showed that the sample is spyware and is responsible for collecting confidential user (victim) data, such as authentication data stored in browsers, VPN, FTP and email clients. Based on the nature of the attack (not massive), one can classify it as a targeted attack.
Additionally, during the analysis, we found lots of similarities with the Agent Tesla malware.
Workflow overview of the sample (OUTSTANDING STATEMENT.xlz.exe)
At stage 1, the sample unpacks a resource named dx, which is an URL-encoded base64 string that results in a PE file.
At stage 2, the library uses a second resource called hLuPu.png to convert it to a byte array. Next, an XOR operation is performed over the array with a previously known key, resulting in a gzip archive that contains a malicious payload.
At stage 3, the malicious payload is injected into the target process.
Analysis
The file was a program written in C# that contained a malicious payload. Using static and dynamic analysis, we were able to extract the payload.
On the program startup, the StudentScores form is created within the Main() method:
The control is passed to the form initialization function:
Next, the wx() function is called containing main malicious functionality:
The wx() function decodes a resource file named dx and executes the “Buta” method:
In total, there are three files in the malware resources:
dx is a URL-encoded string in Base 64 format:
The rest two files have the PNG extension and contain encoded information. The file named q.png:
The file named hLuPu.png:
This PE file appeared to be a dynamic library written in C #. The library was obfuscated with Deep Sea 4.1 and contained the method called Buta.
The Buta method takes an object as an argument:
SoapDate is a class with two lines, one of which contains the name of the png file from the resources of the first file:
The Buta method code:
The algorithm of the Buta method:
- At the beginning, the execution sleeps for 41.5 seconds.
-
The hLuPu resource becomes a Bitmap object
-
Bitmap is decoded into a byte array. This method of decoding the payload is described in the article Commodity .NET Packers use Embedded Images to Hide Payloads , following which we can uniquely identify that this sample uses the “Cyax” packer. The essence of the algorithm is to use the png image’s RGB model and generate the corresponding byte array:
-
The resulting byte array is decoded by the XOR function using the “wNspdaa” key.
-
The resulting archive is then unpacked using the gzip algorithm and the result is the final payload:
-
The payload runs a function that is the entry point:
To automate the payload extraction, we wrote the following script:
using System; |
SHA256 payload:
DE87F049D9DC99A60D457FDAC61C332BB88F5BCFF042AA395F55BCEE4A3C17E8
The payload was also written in C# and contained a set of functions for injecting code into a process also known as the “Process Hollowing” technique:
The first step is to create the RegSvcs.exe process, with the CREATE_SUSPENDED parameter (constant 0x00000004).
Next, the PEB structure containing the information of the target process is obtained by taking the 41 bytes from GetThreadContext function’s output.
After getting the PEB structure, the base address (ImageBaseAddress) of the RegSvcs.exe process is read.
Before allocating memory in the process, it is prepared by the NtUnmapViewOfSection function.
VirtualAllocEx function allocates memory for malicious code inside the RegSvcs.exe process.
The malicious code is then written to the process using the WriteProcessMemory function.
Finally, the RegSvcs.exe process is started by the ResumeThread function.
By storing the byte array used as the argument to WriteProcessMemory function, we received another PE. The functionality of this sample was similar to the functionality of the file described in the New Agent Tesla Variant Spreading by Phishing article, that lead us to assume it was another variant of AgentTesla. The sample was a stealer written in C #.
SHA256 sample:
E701BED0853C2F782B0710F7895D7DCE22A58DBB0042DB56A7D9509929C8F05E
The execution of the AgentTesla sample starts with the D() function, which checks if the stealer is already running to prevent restarting.
Then, there goes a garbage code which executes Sleep for several times. The number of Sleeps depends on the predefined parameter passed to the A.b.a() function, which appears ubiquitous in the code.
Getting the username (in this case, the username is john):
Getting the current ip address:
The main functionality is built with the help of the following functions:
All names are encoded, and after decoding one can see the paths to the data of different browsers
The string encoding algorithm lays inside the DF7A7911_002D5159_002D4174_002D9C8D_002D344C41F0E4CF class. It defines a byte array of 12005 elements:
Inside the class constructor, the array is decoded through the XOR operation using its index number and 0xAA key
The main function of the class returns a string, which is constructed by the passed arguments.
The real string values are obtained by calling lots of alike functions.
Having the decompiled code, one can write the code that will decode the strings by calling all the functions of the class.
As a result, one can get a file with all decoded lines.
Another piece of strings decoding code is related to FTP clients:
Using the tLab system, one can also observe the established Internet connection:
T&T security provides its clients with Yara rules for each malicious file. Yara rule for sample A24BF02CE43A846463532E46211962EC7E883E682ABBDE61F922FCD46FC301BC:
Identification of the sample by Yara rule on the tLab system:
Yara rule for sample C88A66CBF00B12C88E2B970B8BC220E970E8465E56098CED24E97D42BE901B94::
Identification of the sample by Yara rule on the tLab system:
Yara rule for sample DE87F049D9DC99A60D457FDAC61C332BB88F5BCFF042AA395F55BCEE4A3C17E8:
Identification of the sample by Yara rule on the tLab system:
Yara rule for sample E701BED0853C2F782B0710F7895D7DCE22A58DBB0042DB56A7D9509929C8F05E:
Identification of the sample by Yara rule on the tLab system:
There was also another sample found, similar to the previously analyzed one. The sample used a built-in resource called Wids, which was also an image with encoded data.
The resource is decoded pixel by pixel and turned into a byte array:
The result is a PE file in which a specific method is called, where keys are passed for further decoding:
The “aI” method is intended to decode the following malicious payload:
The algorithm of the "aI" method:
-
The main stream falls asleep for 65-78 seconds
-
The string "436F6D70617469626C654672616D65776F726B734D65746164617461456E7472794669656C644964" is decoded by the following algorithm:
The result is the string “CompatibleFrameworksMetadataEntryFieldId”.
-
The resource under that name turns into a Bitmap object
-
Then the resource decoding takes turn
-
The result is another PE file
The PE file has a line with parameters
Depending on the first parameter, it is injected into one of the legitimate processes. In this case, the process RegSvcs.exe
The creation process:
Another resource is being decoded and injected into the process:
The final malicious payload is exactly the same as the previously detected sample.
The analyzed two samples are similar in the way the malicious load is stored as encoded information in an image. Further unpacking differs in the algorithms, but the essence remains the same - XOR bytes.
Yara rule for the new sample:
import "pe" |
Identification of the sample by Yara rule on the tLab system:
Conclusion
The AgentTesla sample is pretty well packaged in a variety of ways and uses several unpacking steps. String coding and steganography intentionally increase the difficulty of conducting manual analysis. Besides, the sample features with a large list of software extracted from within.