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:
|11 bytes from the end of the payload
|base64 (url-safe and replaced padding from “=” to “.”)
|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
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/%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
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.
|Description and updates
|Implemented since version
|Presence of commands in v0.6.3 – v0.6.5
|Show embedded backdoor command list.
|Download a file from C2.
|Upload a file to C2.
|Inject the shellcode in memory. This command has been updated to support the 64-bit shellcode in v0.6.2 and later versions.
|Kill a process using process ID.
|Send malware and system information including current OS version, malware version, process ID, EXE file path, system username, current directory, C2 and Mutex name.
|Make a screenshot.
|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)
|Execute command using WMI.
|Just shows a “Not available.” message from v0.5.6 until v0.6.5.
|Get a file list.
|Delete a file.
|Move a file.
|Copy a file.
|Upload a file to C2.
|Make a directory.
|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.)
|Show process list.
|Terminate a process.
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
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