APT10: Tracking down LODEINFO 2022, part II

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

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

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

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:

Offset Description Crypto algorithm
0x00 11 bytes from the end of the payload Vigenere cipher
0x0C A delimiter N/A
0x0D Message header

Offset Description
0x00 The first 16 bytes of SHA512 value calculated from the hardcoded AES key.
0x10 Size of base64 encoded payload
0x15 A byte of unknown data
base64 (url-safe and replaced padding from “=” to “.”)

Vigenere cipher

0x29 Message payload:

Offset Description
0x00 XORed the first 48 bytes of SHA512 value calculated from the following AES encrypted data (offset 0x36), the XOR key equals the elapsed running time.
0x30 XORed size of encrypted data
0x35 1 byte XOR key for size of encrypted data (offset 0x30)
0x36 Encrypted data by AES CBC mode with the hardcoded AES key “88 8C A3 F2 87 36 CC 12 A5 90 18 56 13 B7 C0 A7 E1 07 D4 5C 7D 47 37 AD AB A3 8C C2 12 E3 03 AC” and IV “83 01 36 C9 3A 2D 13 29 23 56 78 A1 F1 0C D1 75”. The data contains elapsed running time, current time, ANSII Code Page, MAC address, host name, etc.
base64 (url-safe with replaced padding from “=” to “.”)

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

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

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/%s Safari/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

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

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.

Command Description and updates Implemented since version Presence of commands in v0.6.3 – v0.6.5
command Show embedded backdoor command list. v0.1.2 Available
send Download a file from C2. v0.1.2 Available
recv Upload a file to C2. v0.1.2 Available
memory Inject the shellcode in memory. This command has been updated to support the 64-bit shellcode in v0.6.2 and later versions. v0.1.2 Available
kill Kill a process using process ID. v0.1.2 Available
cd Change directory. v0.1.2 Available
ver Send malware and system information including current OS version, malware version, process ID, EXE file path, system username, current directory, C2 and Mutex name. v0.1.2 Available
print Make a screenshot. v0.3.1 Available
ransom Encrypt files by a generated AES key, which is also encrypted with RSA using the hardcoded RSA key.

(Shows a “Not available.” message in v0.3.5)

v0.3.8 Available
comc Execute command using WMI. v0.5.6 Available
config Just shows a “Not available.” message from v0.5.6 until v0.6.5. v0.5.6 Available
ls Get a file list. v0.1.2 Removed
rm Delete a file. v0.3.1 Removed
mv Move a file. v0.4.8 Removed
cp Copy a file. v0.4.8 Removed
cat Upload a file to C2. v0.1.2 Removed
mkdir Make a directory. v0.4.8 Removed
keylog Check for Japanese keyboard layout.

Save keystrokes, datetime and active window name. Uses 1-byte XOR encryption and a file %temp%\%hostname%.tmp.

(Shows a message “Not available.” in v0.3.5.)

v0.4.1 Removed
ps Show process list. v0.4.6 Removed
pkill Terminate a process. v0.4.6 Removed
autorun Set/delete persistence. v0.5.6 Removed


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


LODEINFO zip implant


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


SFX file


Hardcoded C2s


Leave a Reply

Your email address will not be published. Required fields are marked *