Intezer - Technical Analysis: Pacha Group Deploying Undetected Cryptojacking Campaigns on Linux Servers


Cybersecurity DNA

Technical Analysis: Pacha Group Deploying Undetected Cryptojacking Campaigns on Linux Servers

Ignacio Sanmillan
28.02.19 | 5:47 pm


Cryptomining malware, also known as cryptojacking or cryptocurrency mining malware, refers to software developed to take over a computer’s resources and use them for cryptocurrency mining without a user’s explicit permission.

There are several reports documenting this newer malware breed and how it has become more popular in the last few years.

Antd is a miner found in the wild on September 18, 2018. Recently we discovered that the authors from Antd are actively delivering newer campaigns deploying a broad number of components, most of them completely undetected and operating within compromised third party Linux servers. Furthermore, we have observed that some of the techniques implemented by this group are unconventional, and there is an element of sophistication to them. We believe the authors behind this malware are from Chinese origin. We have labeled the undetected Linux.Antd variants, Linux.GreedyAntd and classified the threat actor as Pacha Group.

String Reuse from Antd and GreedyAntd

Technical Analysis

Infrastructure Overview:

Based on our findings Linux.GreedyAntd’s operations closely resemble previous cryptojacking campaigns deployed by Pacha Group in the past. A resumed overview of the current infrastructure is as follows:

The attack chain commences by intruding into a given vulnerable server. Based on the services the compromised servers were publicly exposing, we can assume the attackers opted to launch a brute-force attack against services like WordPress or PhpMyAdmin, or used a known exploit for an outdated version of alike services. The following is an overview of the open services and known vulnerabilities found in one of the compromised systems:

Once the attackers are able to break into a given compromised server, they will run a series of stages in their attack chain.

Main Dropper:

Once a system is compromised the first implant that will be executed is a UPX packed statically linked stripped ELF.

This ELF binary is the main component in the intrusion stage and it is worth dedicating a separate section to. We will refer to this binary as the ‘first stage’ or ‘main dropper’ throughout the blog.

This binary is responsible for various tasks. One of the first actions it will take is to assure that the current compromised server is not infected by other cryptominers by using a technique similar to that of a ‘bot kill’ approach (as known in the DDoS scene) killing any other cryptominer that is currently running in the system. The following list contains the file names belonging to known foreign cryptominers:

We recognized that one of the file names in this list is the Korkerds miner reported by TrendMicro as well as other known miners such as DDG or XMRig. This reinforces the assumption that the list is indeed a blacklist of file names of known miners operating in the wild.

Processes with a filepath residing in ‘/tmp/’, ‘/usr/tmp’ or ‘/dev/shm’ will be killed. We concluded that the purpose of this aggressive behavior is intended to discover further miner processes or malware that were not covered in the initial miner process blacklist.

We have also noticed that some implants were checking for potential JBOSS compromised servers by attempting to access specific paths in order to detect and restrict potential operational webshells or dropped binaries by removing all available file permissions to them. There is a github project called JexBoss regarding JBOSS serialization vulnerabilities that uses these same paths, suggesting that authors behind other cryptomining campaigns could be using it to spread their infrastructures, answering why these paths are being searched for:

As previously mentioned, evaluation of the current system in order to know if it is already compromised has been accomplished. Furthermore, there may be a chance that the current system is already compromised by the same group. In order to figure out whether this is the case all process names are checked again with the end goal of recognizing any familiar process names used by the same group and if found, the process will terminate. This could potentially work as a possible vaccine to be used by some miner-protection solutions against this specific miner:

After the first stage has completed an initial reconnaissance for the running processes, it proceeds to create a random string to rename itself. It also overwrites some known memory locations where the original process name resides and overwrites them with a fake process name (in this case ‘[kworker/1:7]’). An example of such memory locations is argv[0]:

Furthermore it will fork itself and detach from its parent to become an independent process running on a different session as a means to create a fresh new process:

Lastly, the current session username is checked and the control flow will diverge accordingly:

As demonstrated in the previous screenshot, the main difference is that if the file was executed as root, persistence mechanisms would be enforced.

Persistence Mechanisms:

The applied persistence mechanisms consist mainly of a given dropped implant saved as ‘mand’ followed by installing a Systemd service which will grant its persistence in the system. In addition, the timestamp of the dropped implants will be replaced as for the one of ‘/usr/bin/find’ as a means to make the dropped file unnoticed in the filesystem.

A Systemd unit file will be decoded and dropped as ‘systemd-mandb.service’ masquerading the genuine mandb service. The following is the decoded Systemd unit file:

It is important to highlight that this persistence measure will make the intrusion harder to spot for the untrained eye since it is not the average cron-job that most Linux malware tend to use. Furthermore we spotted other components of this campaign dropping and installing initrd scripts as well as the following one:

After persistence measures have been enforced, several components will be downloaded to the current compromised system to remain with the attack chain:

Multi-Stage Architecture:

The following diagram is a simplified version of the various components that make up the malware’s main infrastructure:

We can assume that the main reason for having such a broad infrastructure involving a large number of components is to make it more resilient to server shutdowns as well as to provide a factor of modularity. Furthermore, having this amount of components interconnected with each other also implies to invest a much greater effort in order to clean a given compromised system.

These components will run according to a small protocol involving the main dropper and all remaining components executed via a shared named pipe. This execution protocol is the following:

The majority of the secondary stagers create (or just open if it already exists) a named pipe on execution with write permissions in which they write their pid to:

On the other hand, the main dropper serializes each stager by reading and logging the contents of the named pipe therefore retrieving each stager’s pid. This way the main dropper acts as a manager for each active stager in the system:

The first stage’s main threat will continue execution attempting to update the available stagers by downloading them in intervals on an infinite loop:

In addition, a timed routine will be executed by triggering a SIGALRM signal also in intervals, handling this signal via sigaction sycall, and therefore pivoting control of execution to its correspondent signal handler intermittently. This same technique has been spotted in various components of this malware’s infrastructure:

This installed signal handler is mainly used to drop further artifacts using embedded one-liner python scripts such as the following:

This script will drop further stages as well as further scripts. The following is an example of such scripts:

GreedyAntD Miner Client

The deployed miner instance is a XMRig variant. We can confirm this via code reuse:

We can also confirm the miner shares code with other components from the same infrastructure, also based on code reuse:

It uses the Stratum mining protocol and connects to a XMRig proxy in order to conduct the mining operation. We assume the reason to use this specific protocol is to prevent to deploy its clients with encoded configurations containing the target wallet address they will be mining to, instead they connect to already configured proxies:

The following are the Proxies that interacts with:

Furthermore, we can also confirm it is using Stratum by sniffing the Miner’s stream to these proxies:

We notice that the client and server are exchanging information encoded as json-rpc strings, which is commonly used in stratum mining protocol.

Highlighted are the different cryptocurrency mining algorithms that the client supports. These names can be seen in the main XMRig-proxy GitHub repository:

The following screenshot is a process list view on htop of a compromised system. Highlighted are some of the malicious processes related to the campaign:

Connections with Linux.HelloBot

Among the artifacts hosted in GreedyAntd’s servers, we managed to find a single component not related to the same cryptojacking operation just previously discussed and leveraged by Pacha Group. This file was hosted on a compromised third party server and its main purpose was to drop a xmr-stak json configuration. This json file was the following:

When we analyzed this binary for code reuse connections we found it shared a significant amount of code with Linux.HelloBot, a Chinese bot discovered by Intezer along with MalwareMustDie in January 2019:

After analyzing the code connections we came to the realization that both samples were sharing the same instance of some static libc implementation:

Library similarities tend to not be as relevant in some specific scenarios in regards to finding connections between threat actors. However, in this case these library similarities seem to be relevant enough to consider a potential link between these two threat actors. Especially since from viewing all different x86 libc versions in our database, it only matched with Linux.HelloBot’s statically linked libc. In addition, this libc instance has identical code in both samples which implies it was compiled with the same compilation flags. This reinforces that the particular libc instance may be a potential link to connect these binaries with a single author, also taking into account that both of them have indicators that suggest they have Chinese origin.


This cryptominer use case is another example of an undetected Linux malware operating in the wild. After conducting more research we concluded that the approach of interconnecting all second-stagers to a manager (this being the main dropper) via IPCs is successful for anti-dynamic analysis. In order for any of the secondary-stages to run successfully they will need to be present with the main dropper in a given system. This implies that behavior and dynamic analysis will fail if any of the second-stager components are analyzed independently without tampering the original sample. This may explain why the majority of the components in this malware’s infrastructure remain practically undetected:


By Ignacio Sanmillan

Nacho is a security researcher specializing in reverse engineering and malware analysis. Nacho plays a key role in Intezer's malware hunting and investigation operations, analyzing and documenting new undetected threats. Some of his latest research involves detecting new Linux malware and finding links between different threat actors. Nacho is an adept ELF researcher, having written numerous papers and conducting projects implementing state-of-the-art obfuscation and anti-analysis techniques in the ELF file format.

Register to our free community

© 2019 All rights reserved