1. Executive Summary
At VinCSS, I recently wrote an analysis related to the samples of the Mustang Panda (PlugX) group. These samples are all uploaded from Vietnam. You can read the Vietnamese or English blog post of this analysis.
However, in all the uploaded log.dll
files, there is one file that is not related to the Mustang Panda group’s attack technique, it is marked as the following picture:
2. Analyze log.dll
This file’s size is smaller than other files. The original name is imageres.dll
, it exports a lot of functions have the same address, but the only one most notable is the LogInit
function:
Analyze LogInit
‘s code in IDA, I see it build path to the mpengindrv.db
file:
Next, read the content of mpengindrv.db
into the allocated memory region and decrypt it by using RC4 with the decryption key is “A5A7F7E2B00C4A2B87FC0123F933EBD6
“. After successful decryption, call the decrypted payload to execute:
3. Hunting and decrypting
Trying to hunt mpengindrv.db
file on VT, I found the only file uploaded from Vietnam and at the same time as the log.dll
file above:
Using CyberChef to decrypt file, we found that the file after decryption is a PE file, but we will see that immediately after the MZ
signature is the opcode of the call command (0xE8
):
Save the decrypted file to disk, perform disassembly first bytes, and see that there are two calls as follows:
The above information reminds me of the ReflectiveLoader technique that I have analyzed in this article. Static analysis the decrypted file, which is a Dll with the original name Lotes.dll
, exporting one function is ReflectiveLoader
.
However, the unusual point is that, its Imports Table information is wrong, the names of sections are also confusing characters:
4. Analyze Lotes.dll
Load the Dll file into IDA for analysis, the code in the ReflectiveLoader
function is similar to the code here, but it has been modified a bit related to processing import table . It first reads the NumberOfSymbols
value from the File Header
and stores it in a variable. This variable will be used as the xor_key
. Then, when processing the import table , it uses the obtained xor_key
value to decode the names of the dlls, as well as the names of the API functions that the malicious code will use:
Based on the above information, it is easy to recover the information of the Import Table:
After completing the Loader process, it will call the entry point of the Dll file to execute:
The code at DllEntryPoint
will call DllMain
, and then calls the function f_decrypt_and_parse_beacon_config
. The reason I know this is a CobaltStrike Beacon is because the f_decrypt_and_parse_beacon_config
function will perform decode the config with a hard-coded value of 0x2e
(as xor_key). The value 0x2e
is used in Beacon version 4.
Based on this info, I used the script 1768.py by Mr. Didier Stevens to extract the configuration information of the CobaltStrike Beacon. The result shows that this is an SMB Beacon:
End.
m4n0w4r
[…] 0day in {REA_TEAM}[QuickNote] CobaltStrike SMB Beacon Analysis […]