Iron Tiger’s SysUpdate Reappears, Adds Linux Targeting

The attacker runs rc.exe, a legitimate “Microsoft Resource Compiler” signed file , which is vulnerable to a DLL side-loading vulnerability, and loads a file named rc.dll.
The malicious rc.dll loads a file named rc.bin in memory.
The rc.bin file is a Shikata Ga Nai encoded shellcode that decompresses and loads the first stage in memory.
Depending on the number of command line parameters, different actions are performed:
Zero or two parameters: “Installs” the malware in the system, and calls Stage 1 again via process hollowing with four parameters
One parameter: Same as previous action but without the “installation”
Four parameters: Creates a memory section with the DES-encrypted malware configuration and a second Shikata Ga Nai shellcode decompressing and loading Stage 2.
It then runs Stage 2 via process hollowing.

The “installation” step is considered simple wherein the malware moves the files to a hardcoded folder.
Depending on the privileges of the process, the malware either creates a registry key or a service that launches the moved executable rc.exe with one parameter.
This ensures that the malware will be launched during the next reboot, skipping the installation part.
Analysts saw different legitimate executables being used, sideloading different DLL names, and multiple binary files names being loaded by those DLLs.

Analysts want to highlight that this is the first time Analysts observed a threat actor abusing a sideloading vulnerability in a Wazuh signed executable.
Wazuh is a free and open source security platform, and Analysts could confirm that one of the victims was using the legitimate Wazuh platform.
It is highly likely that Iron Tiger specifically looked for this vulnerability to appear legitimate in the victim’s environment.
Analysts have notified the affected victim of this intrusion but received no feedback.

Looking at the features, several of the functions found in the latest update are similar to the previous SysUpdate version:

Service manager (lists, starts, stops, and deletes services)
Screenshot grab
Process manager (browses and terminates processes)
Drive information retrieval
File manager (finds, deletes, renames, uploads, downloads a file, and browses a directory)
Command execution
Iron Tiger also added a feature that had not been seen before in this malware family: C&C communication through DNS TXT requests.
While DNS is not supposed to be a communication protocol, the attacker abuses this protocol to send and receive information.

First, the malware retrieves the configured DNS servers by calling the GetNetworkParams API function and parsing the DnsServerList linked list.
If this method fails, the malware uses the DNS server operated by Google at IP address 8.8.8.8.

For the first request, the malware generates a random number of 32 bits and appends 0x2191 to it.
This results in six bytes – four for the random number, two for 0x2191 – and encodes the result further with Base32 algorithm using the alphabet “abcdefghijklmnopqrstuvwxyz012345”.
The contacted domain name is after “TXT”; only the first four letters change as the rest of the encoded series is always the same.
This is because the random number changes every time, but the end is the same “0x2191” result.
This explains why the first DNS request always ends with “reeaaaaaa.”.
If the C&C reply matches the format expected by the malware, it launches multiple threads that handle further commands and sends information about the infected machine.

Interestingly, the code related to this DNS C&C communication is only present in samples that use it, meaning that the builder is modular and that there might be samples in the wild with unreported features.
Analysts continue monitoring this group and malware family for updates on possible variations of C&C communication protocols being abused.
In all versions, the malware retrieves information on the infected machine and sends it to the C&C encrypted with DES.
Collected machine information includes the following:

Randomly generated GUID
Hostname
Domain name
Username
User privileges
Processor architecture
Current process ID
Operating system version
Current file path
Local IP address and port used to send the network packet

Analysts noted that Stage 2 does not embed the configuration file, which is copied in memory by the previous stage.
Analysts only saw one case where there was only one stage being decrypted in memory and the configuration was hardcoded.

Interestingly, all the samples of this “new” version had a domain name as its C&C.
In the previous version of SysUpdate, the group used hardcoded IP addresses as C&C.
It is possible that this change is a consequence of the new DNS TXT records’ communication feature as it requires a domain name.

While investigating SysUpdate’s infrastructure, Analysts found some ELF files linked to some C&C servers.
Analysts analyzed them and concluded that the files were a SysUpdate version made for the Linux platform.
The ELF samples were also written in C++, made use of the Asio library, shared common network encryption keys, and had many similar features.
For example, the file handling functions are almost the same.
It is possible that the developer made use of the Asio library because of its portability across multiple platforms.

Some parameters can be passed to the binary (note that “Boolean” refers to Boolean data that is sent to the C&C):

The persistence is ensured by copying a script similarly named as the current filename to the /usr/lib/systemd/system/ directory, and creating a symlink to this file in the /etc/ystem/system/multi-user.target.wants/ directory.
Thus, this method only works if the current process has root privileges.
The content of the script is:

[Unit]
Description=xxx
[Service]
Type=forking
ExecStart= -x
ExecStop=/usr/bin/id
[Install]
WantedBy=multi-user.target

After running the code dependent on the parameters, if the operator has not chosen a GUID with the “-f” parameter, the malware generates a random GUID and writes it to a file similarly named as the current file, with a “d” appended to it.
Then, the malware retrieves information on the compromised computer and sends it to the C&C.

The following information is sent to the C&C, encrypted with a hardcoded key and DES CBC algorithm:

GUID
Host name
Username
Local IP address and port used to send the request
Current PID
Kernel version and machine architecture
Current file path
Boolean (0 if it was launched with exactly one parameter, 1 otherwise)
For the DNS C&C communication version, the malware retrieves the configured DNS server by reading the content of the /etc/resolv.conf file, or uses the DNS server operated by Google at IP address 8.8.8.8.

Another interesting part of this campaign is the fact that some of the malicious files are signed with a certificate with the following signer: “Permyakov Ivan Yurievich IP”.
Looking for that name in search engines brings results from the official VMProtect website.
The email address linked to the Authenticode certificate also links to that domain name.
VMProtect is a commercial software intended to make analysis of code extremely difficult by implementing a custom virtual machine with non-standard architecture.
The software has been used by multiple APT and cybercrime groups in the past to obfuscate their malware.

When searching on malware repositories for other files signed by the same certificate, Analysts find multiple files named “VMProtectDemo.exe”, “VMProtect.exe”, or “VMProtect_Con.exe”, which suggests that an official demo version of VMProtect is also signed by this certificate.
It appears that the threat actor managed to retrieve the private key allowing him to sign malicious code.
As of this writing, the certificate is now revoked.

Using stolen certificates to sign malicious code is a common practice for this threat actor, as Analysts already highlighted in 2015 and in all recent investigations.
Interestingly, the threat actor not only signed some of its malicious executables with the stolen certificate, but also used VMProtect to obfuscate one of them.

In late January 2023, a Redline stealer sample (detected by Trend Micro as TrojanSpy.Win32.REDLINE.YXDA1Z, SHA256: e24b29a1df287fe947018c33590a0b443d6967944b281b70fba7ea6556d00109) signed by the same certificate was uploaded.
Analysts do not believe that the stealer is linked to Iron Tiger, considering that the network infrastructure is different, and previous reports document the malware’s goals to be centered on committing cybercrime than data theft.
This could mean other users managed to extract the same private key from the VMProtect demo version, or it was sold in the underground to different groups, Iron Tiger among them.

Analysts did not find an infection vector.
However, Analysts noticed that one of the executables packed with VMProtect and signed with the stolen certificate was named “youdu_client_211.9.194.exe”.
Youdu is the name of a Chinese instant messaging application aimed for use of enterprise customers.
Its website mentions multiple customers in many industries, some of them in critical sectors such as government, energy, healthcare, or banking.
But they also have other customers in industries such as gaming, IT, media, construction, and retail, apparently all located inside China.

The properties of the malicious file also match the usual Youdu version numbering.
However, the legitimate files are signed with a “Xinda.im” certificate instead of the stolen VMProtect certificate.

As seen in the product name identified in the malicious file’s properties, Analysts searched for possible products named “i Talk” but did not find any that could be related to this investigation.
However, Analysts found traces of files from the legitimate Youdu chat application signed by Xinda.im being copied to folders named “i Talk” on one victim’s computer.
This suggests that some chat application named “i Talk” might be repackaging components from the official Youdu client along with malicious executables.
It appears that a chat application was used as a lure to entice the victim into opening the malicious file.
This would be consistent with the tactics, techniques, and procedures (TTPs) of two previous Iron Tiger campaigns from 2020 and 2021: a documented compromise of a chat application widely used by the Mongolian government, and a supply chain attack on Mimi chat, a chat application used in parts of South East Asia.