Introduction
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 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:
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:
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:
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:
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:
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:
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.
Conclusion
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:
IOCs:
185.165.169.6
185.10.68.100
4d1a6151166048ea066c6b5918fbb02a43ed357e3e7eb75bc73970a97008337e
chn
206287e22445431ccab0a574f3002e28d1aaffa5153ba66f2a754d1f92b90a78
chn.unpacked
9119d47ee2b6e7bf94245699fec1432042e30255d9f64289f8e0aca56570eab3
ofd
096f8f387200fa70dddb2bfe5a77a50c88acb155d4f296f1fa6cb09109053246
ofd.unpacked
ee0ab03909ca433deb9161e831512c5bd6c64ffbc9332c3eea14b85b996ba882
rlr
1161fbe0a9ae1c5e0792d23682b602990af31c6847865220cf4f2f91981d426c
rlr.unpacked
3c3379284417070983da222f8ea347a4166c28a2ba3445e19f92b10b9b539573
_j.jpg
9ff1bf60e35912141c74728738c3af105d06ea8fa9c0cbd7a4b196ec1cdc9e22
j.jpg
dafac060867643d27a81e99e3753d155658e5f4a7f359317e0e8609fc7d14373
jm
069a87fbd966df854f55d82fc98f89ef394cee59b352fba5fb402887892a4161
jm.unpacked
84165c21fc144894c5fe674cfd06edafd4b95d52abf86afef4d61db91099bf8a
jpp
544e71e3a7ff1f1f0e902cef00156aa157790f7c3450870ca9272936443e05af
jpp.unpacked
a9656439d1ac3881c1ba9e0f2fd462b8a4469bf79035233517eae65ed6afafd0
jrd
e43d381c43749d7d267d207273ef3b634bfaeb0ff76f8e2cd6e0b27c6e3b07c8
jrd.unpacked
3c3379284417070983da222f8ea347a4166c28a2ba3445e19f92b10b9b539573
_j.sh
b6455e0335ad99028656b5b847fd5d530bc079b2524b2ecbf4f06d5e69473e7d
lmmml
39904faf4a620aa3a9e9ece3022f0bced20ef7684e0f352f99267e7c462d227c
lmmml.unpck
910fea37c73fc328522e04c77d1ad555c990f0376960770698bd3590c5b1b485
nvn
81b8860ecf21a73de8663188962fb1dae5a5c17e7b6f4ac41e0198d12497838f
nvn.unpacked
371f52a238d4be6eb8d7fd0130684f4286681f09adb61fbca3bdfacef8c747f7
sds
b72074b6c75b4fe5ea74e2db716f488a356d9d879c6d3aa5e9ed4bb786993761
sds.unpacked
42a423b6107f2186964ac9a1e7882a50f6b5cb9f96926dd2a69b1fc5eaba81d6
lmmml.1
e9a06f7183f7e06d8e414e16caae769a3859fcca20acae735f6744712f84b3e5
sss
4f9e77b4e0d80ea74ba861ab54b7360df7b823f24fd9cedb1fd44a29da70b11f
sss.unpacked
0940472a185099df2f814bcedbc1c913a7075168ab90d63249c6301849c1d93f
dld
6ff5e36d2999f8593cc4daa5e7c633abe0f28b0cba9da0339fc8d3cb7f6090a3
dld.unpacked
c70423e5d44cc31df70a69d65e56be1621956bccec2a3a68a69195ecccd4e881
_jj.jpg
452ed9cf53aed0afdc7900ca855f652a7c1585c2b03b27e6f3224fb6204da25a
_jj.sh
6f3add7ec36a710973d09b814082e105b848cd78f2769ba6bbc946f59f463457
ldl
045d7afaf53692607e7433a4fe8f19b2e3790414c649c8630086039d88935a02
ldl.unpacked
0940472a185099df2f814bcedbc1c913a7075168ab90d63249c6301849c1d93f
olo
6ff5e36d2999f8593cc4daa5e7c633abe0f28b0cba9da0339fc8d3cb7f6090a3
olo.unpacked
7ae8c6c65955fb9340b07afd380bbf3383b5030a92ba204cd61ca21c13a955e8
_z.jpg
9e049a51741f22403a9c08d3d7625ad4761cbfda5a8a051f6e8195e0f6a8e9cd
z.jpg
7ae8c6c65955fb9340b07afd380bbf3383b5030a92ba204cd61ca21c13a955e8
_z.sh
9e049a51741f22403a9c08d3d7625ad4761cbfda5a8a051f6e8195e0f6a8e9cd
z.sh
Cceddd7e9a7ddb4991776239cb0b941d061ac21db00b1021a8c45660f52e56b7
E2e07782dbfddeb95661c7360db5113c9b035cfb8e43e038106bd0f537553b36
40d8d89aa19ca4121ab583758692752964402923917da766f39a32cbc8bdd6dd
The post Technical Analysis: Pacha Group Deploying Undetected Cryptojacking Campaigns on Linux Servers appeared first on Intezer.
Article Link: https://www.intezer.com/blog-technical-analysis-pacha-group/