APT10: Tracking down LODEINFO 2022, part II

Evolution of LODEINFO backdoor shellcode

In the previous publication ‘Tracking down LODEINFO 2022, part I‘, we mentioned that the initial infection methods vary in different attack scenarios and that the LODEINFO shellcode was regularly updated for use with each infection vector. In this article, we discuss improvements made to the LODEINFO backdoor shellcode in 2022.

Kaspersky investigated new versions of LODEINFO shellcode, namely v0.5.9, v0.6.2, v0.6.3 and v0.6.5, in March, April and June, respectively. The following chart shows the evolution timeline of this malware since its discovery.

Timeline of LODEINFO releases

LODEINFO v0.5.6: multiple encryption for C2 communication with ancient crypto algorithm

This LODEINFO v0.5.6 shellcode extracted from a loader module demonstrates several enhanced evasion techniques for certain security products, as well as three new backdoor commands implemented by the developer.

After infecting the target machine, the LODEINFO backdoor beacons out machine information to the C2, such as current time, ANSI code page (ACP) identifier, MAC address and hostname. The beacon also contains a hardcoded key (NV4HDOeOVyL) used later by the age-old Vigenere cipher. Furthermore, randomly generated junk data is appended to the end of the data, possibly to evade beaconing detection based on packet size.

Vigenere cipher key and randomly generated junk data added in LODEINFO v0.5.6

In December 2021, we discovered LODEINFO v0.5.8, with a slight modification that added the LODEINFO implant version number right after the Vigenere cipher key.

The encryption function used to send data was also modified, making it even more complicated. As observed in previous variants, it takes the first 48 bytes of the SHA512 hash value of the data to be sent. Then it XORs the data using a four-byte XOR key that is equal to the elapsed running time, and prepends it before the data. The first 16 bytes to be sent are from another SHA512 hash value, this time taken from the previously mentioned hardcoded AES key (NV4HDOeOVyL). It encrypts 11 bytes at the end of a base64-encoded payload (with replaced padding from “=” to “.”) to dynamically generate the second Vigenere cipher key and the variable of the final generated data. The second key is used by the Vigenere cipher to encrypt the base64 encoded header (url-safe replaced padding from “=” to “.”).

Crypto algorithms and data flow in C2 communications

Finally, the data to be sent to the C2 is produced using the second key, the encrypted header, and the payload through the complex steps described above. The final data packet structure is as follows:

LODEINFO v0.5.6: 2-byte XOR obfuscation for backdoor command identifiers

This update included revised crypto algorithms and backdoor command identifiers that were defined as four-byte hardcoded values in previous LODEINFO shellcodes. LODEINFO v0.5.6 backdoor command identifiers are obfuscated with a two-byte XOR operation. Before comparing a command identifier, an XOR operation is applied for each command. The hardcoded XOR key differs for each command as follows:

Two-byte XOR for four-byte stack strings of backdoor command identifiers

We also observed the actor implementing new backdoor commands such as “comc”, “autorun”, and “config” in LODEINFO v0.5.6 and later versions. Twenty-one backdoor commands, including three new commands, are embedded in the LODEINFO backdoor to control the victim host.

LODEINFO v0.5.9: hashing algorithm to get API functions

Version 0.5.9 has a new hash calculation algorithm compared to v0.5.8. The hashing algorithm is used by the malware to calculate hashes for API function names, to resolve the function addresses. In this case it seems to be a custom algorithm developed by the actor. The logic of the hash calculation has an XOR operation with a two-byte key at the end and the hardcoded XOR key, which is different in each sample.

Changed hash calculation algorithm and additional two-byte XOR key in v0.5.9

This modification suggests the attacker’s goal was to evade signature-based detections and make the reverse engineering process more difficult for security researchers.

LODEINFO v0.6.2: evasion of en_US environment

In LODEINFO v0.6.2 and later versions, the shellcode has a new feature that looks for the “en_US” locale on the victim’s machine in a recursive function and halts execution if that locale is found.

Recursive call if the “en-US” locale is found

According to our own investigations, as well as open-source intelligence collected on this malware, the main targets of these attacks are Japanese entities. The aim of this feature, therefore, is to evade execution in sandboxes and on researcher machines, something that occurs most commonly in an English-language locale.

LODEINFO v0.6.2: generating user agent for C2 communications

The function responsible for generating the user agent for C2 communication has also been updated from v0.6.2. The malware generates the user agent string using the following hardcoded formatted string, where the %s is substituted with the version number of the installed chrome.exe application:

“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/%sSafari/537.36″.

The malware gets the version number of the installed chrome.exe from the EXE file present at one of the following file paths:

• C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
• C:\Program Files\Google\Chrome\Application\chrome.exe
• C:\Users\Administrator\AppData\Local\Google\Chrome\Application\chrome.exe

Otherwise, if none of these files exists on the system, the malware uses the hardcoded version 98.0.4758.102 to create the following user agent string:

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36

LODEINFO v0.6.2: supporting the injection of the 64-bit shellcode in ‘memory’ command

Based on our deep analysis of this version, we discovered a very interesting update in the shellcode loading scheme implemented from version v0.6.2, in the function that handles the ‘memory’ command.

Checking the OS architecture and the next shellcode architecture

During the memory injection process, performed using the function responsible for the memory command, the malware checks the first byte of the second stage shellcode to determine the shellcode architecture using a magic hex value. If the first byte is 0xE9, the architecture is 32-bit, and if it is 0x8D, the architecture is 64-bit. After the check is completed, if the first byte was 0x8D, it gets replaced with 0xE9 in order for the shellcode to execute properly. In the function shown below, the malware checks the OS architecture of the infected machine and handles the appropriate loading scheme according to OS architecture and shellcode architecture.

Memory injection of the 64-bit shellcode was supported in v0.6.2

In the shellcode injection process, it uses the basic Windows APIs such as VirtualAllocEx(), WriteProcessMemory() and CreateRemoteThread() for memory injection of the 32-bit shellcode and NtAllocateVirtualMemory(), NtWriteVirtualMemory() and RtlCreateUserThread() for supporting the memory injection of the 64-bit shellcode.

LODEINFO v0.6.3: reducing backdoor commands

As for updates implemented in the LODEINFO backdoor commands, the obfuscation method using two-byte XOR encryption for backdoor command identifiers as well as the debug strings remained untouched up to version 0.5.6. However, in version 0.6.3, the actor removed some of the unnecessary backdoor commands to improve the efficiency of the backdoor. The number of backdoor commands was reduced from 21 in v0.6.2 to 11 in v0.6.3. The modifications to the C2 command list are shown in the table below.

Conclusions

LODEINFO malware is updated very frequently and continues to actively target Japanese organizations. At the time of writing this report, in September 2022, we detected v0.6.6 and v0.6.7 with new TTPs.

One of the core modifications of the LODEINFO shellcode was support for Intel 64-bit architecture, to expand the targeted victim environments. The updated TTPs and improvements in LODEINFO and related malware, such as the implementation of the Vigenere cipher, complex infection flow with fileless malware, partial XOR encryption, C2 communication packets with a unique data structure and variable length, and password-protected documents, indicate that the attacker is particularly focused on making detection, analysis and investigation harder for security researchers.

For this reason, it becomes more and more difficult to keep track of this actor. That is why we believe it is important to emphasize collaboration within the security research community, to share our results and findings about LODEINFO and related malware attacks.

Indicators of compromise

Malicious document

da20ff8988198063b56680833c298113

LODEINFO zip implant

89bd9cf51f8e01bc3b6ec025ed5775fc

LODEINFO loader with an embedded BLOB

LOADERINFO loader without a BLOB

Binary of LODEINFO with a one-byte XORed shellcode

Implants that contain LODEINFO loader and a one-byte XORed shellcode

15b80c5e86b8fd08440fe1a9ca9706c9
6780d9241ad4d8de6e78d936fbf5a922

SFX file

76cdb7fe189845a0bc243969dba4e7a3
edc27b958c36b3af5ebc3f775ce0bcc7

Hardcoded C2s

103.175.16[.]39
172.104.72[.]4
172.104.112[.]218
172.105.223[.]216
202.182.108[.]127
45.77.28[.]124
5.8.95[.]174
www.dvdsesso[.]com