The fetched wbw.xml file contains an embedded PowerShell command, which executes on the victim’s machine. The command is:

It attempts to download a PowerShell script called “ 1.ps1” onto the victims machine using the System.Net.WebClient.DownloadString method. It also leverages the Set-ExecutionPolicy Bypass flag to ensure that nothing is blocked, and that no prompts or warnings will be generated during execution. 

The 1.ps1 script then downloads a crypto miner executable called xmrig.exe, as well as a config.json file, that contains config information for the miner to consume -  such as crypto wallet addresses, crypto pool endpoints, and additional configuration settings. In addition to that, the 1.ps1 script also contains a $miner_name variable which stores the new name that the crypto miner executable, xmrig.exe, will be renamed to, in this case it xmrig.exe is  renamed to “sysupdate” and then executed. 

The 1.ps1 script establishes persistence on the victim's machine in order to update the config.json file and the miner. It does so by leveraging SchTasks.exe, which allows the creation, deletion, and running of scheduled tasks on a local or a remote machine from PowerShell. More info on SchTasks.exe can be found here. The scheduled task is named “Update service for Windows Service” and it again leverages the -ExecutionPolicy bypass flag in order to avoid raising any warnings or prompts while executing, as well as the -windowstyle hidden flag to remain hidden.

Infecting Linux systems

The campaign is leveraging multiple CVEs to achieve RCE in order to infect Linux systems. Along with the Kinsing malware, which contains a crypto miner, Linux payloads also have  a remote access trojan (RAT). The targeted services include Oracle WebLogic Server, Redis, Apache Solr, PHPUnit, and Supervisor XML-RPC.

The Oracle WebLogic Server CVE-2020-14883 is also leveraged by this campaign on Linux systems. However, unlike the Windows version of this vulnerability, where the RCE happens via the  ClassPathXmlApplicationContext class, on Linux it happens via the FileSystemXmlApplicationContext class. The malicious XML file is called wb.xml, which downloads a bash script, instead of the previous wbw.xml for Windows which downloads a PowerShell script.

On Linux systems, the infection starts by achieving RCE using any of the CVEs given in the table below to download a bash script file onto the victim’s machine.

While the bash script file name varies between s.sh , p.sh, sup.sh, d.sh, ex.sh, r.sh, spr.sh, tf.sh or wb.sh - they all do pretty much the same thing.

The bash script kills any competing miners that might already exist on the system and disables security and logging features. It then downloads the Kinsing malware (written in Golang), establishes persistence using the crontab, and then starts mining crypto.

Once executed on the victim’s machine, the Kinsing malware creates a second process called kdevtmpfsi in the /tmp directory, which is the xmrig crypto miner, and executes it. The Kinsing malware constantly monitors the kdevtmpfsi process to ensure that it’s running.

Decoding Command & Control IP address 

The way the malware communicates to the C2 server is by decoding the C2 IP address at runtime using a function called getActiveC2CUrl. The getActiveC2CUrl function uses a RC4 stream-cipher to XOR plaintext hex data with a plaintext key that are both stored within the binary. 

Due to the nature of how strings are stored within a Golang binary,  where all static strings are basically concatenated with one another resulting in one big string blob, the plaintext key and hex data can be easily hidden within the massive string. After some reversing of the getActiveC2CUrl function, the location in memory and length of both the key and the hex data can be found.

The getActiveC2CUrl function hex decodes the C2 hex data, and then, along with the key, they are both passed into a second function called RC4. The custom RC4 function uses the function func (c *Cipher) XORKeyStream(dst, src []byte) internally from the rc4 golang package to generate the C2 IP address.

Now that both the C2 hex data and the key are obtained, the getActiveC2CUrl function can be further reverse engineered and rewritten in Golang in order to calculate the active C2 IP address.

RAT Capabilities

The Kinsing malware has remote access trojan (RAT) capabilities that can be found in a function called doTask() within the binary. The doTask function contains a few interesting function calls that it executes based on a given input

• runTaskWithScan()

• updateTask()

• startCmd()

• execTaskOut()

• masscan()

• socks()

• backconnect()

• runTaskWithHttp()

• downloadAndExecute()

One of these interesting functions is startCmd() that allows for an arbitrary command to be executed on the victim's machine.

The bash scripts that are then downloaded from the original distribution IP 194.38.20.199 as a result of hitting the /get endpoint of the C2 are called ph.sh and spre.sh. These two files are different from the initial infecting bash script that we looked at before, they each have a different purpose and contain additional infection vectors.

We will first examine the ph.sh script, it downloads a rootkit called libsystem.so from the 194.38.20.199/libsystem.so endpoint in addition to the existing Kinsing malware on the victim’s machine. The ph.sh script then preloads this rootkit into /etc/ld.so.preload

The ph.sh script also establishes a second persistence mechanism, in addition to the already existing cron jobs that were previously injected by the initial script. It does this by registering a system service that will periodically reinfect the host.

If you would like to know more about the libsystem.so rootkit that the ph.sh script installs and its inner workings, Trend Micro wrote a fantastic blog about this specific rootkit that can be found here

The second interesting bash script file that gets fetched due to a /get response from the C2 endpoint is spre.sh. Its purpose is to spread the infection to additional hosts by finding ssh credentials for any hosts that the victim has access to by examining  ~/.ssh/config , ~/.bash_history,  and  .ssh/known_hosts. The spre.sh script will then attempt to ssh into the discovered hosts using the obtained creds that were found and infect them as well.

Another interesting C2 endpoint that the infected machine requests for instructions, is the /mg endpoint. When the infected machine makes a GET request to the /mg endpoint, the C2 responds with a few characters, then immediately the infected machine will start communicating with a third IP address, 95.181.179.88, which seems to be responsible for giving mining commands to the infected machine in the form of a JSON-RPC payload over HTTP.

What to do

To mitigate these threats, the Akamai SIRT advises to monitor processes on your systems for abnormally high resource consumption and suspicious network activity. Abnormal high CPU usage for a given process may be an indicator of cryptomining activity.

The Akamai SIRT also recommends you frequently check the cron jobs that are registered under the crontabs on your systems to ensure that the cron jobs are not communicating to any unknown IP addresses, which is a common technique for Linux malware to establish persistence, and the discussed campaign is no exception.

On Windows systems the same should be done with PowerShell using the SchTasks.exe /Query to display any scheduled tasks that might have been created by this campaign. Also check the running processes on your Linux systems and ensure that processes with the name kinsing or kdevtmpfsi are not running and that a process called sysupdate is not running on your Windows systems.

Add strong authentication to your systems where possible, weak passwords can be easily brute forced. Also ensure services that are targeted by the discussed campaign which include Oracle WebLogic Server, Redis, Apache Solr, PHPUnit, and Supervisor XML-RPC are not internet facing if they don't need to be, which highly reduces the risk that these services will get infected. For example, if a Redis instance is only used by internal systems it does not need to be internet facing. 

The Akamai SIRT also recommends checking your systems against the Indications of Compromise (IOC) provided in the IoCs section below to ensure that your systems are not already infected.  In addition to that, patch your systems regularly and follow best practices.

Indications of compromise (IOC)

IPs

Files