Uptycs researchers identified ongoing malicious campaigns through our Docker honeypot targeting exposed Docker API.
The Uptycs Threat Research team has identified ongoing malicious campaigns through our Docker honeypot targeting exposed Docker API port 2375. The attacks are related to crypto miners and reverse shells on the vulnerable servers using base64-encoded commands in the cmdline, built to evade defense mechanisms. This article briefly discusses three types of attacks which we observed lately in our Docker honeypot.
- Coinminer attacks
- Reverse shell attacks
- Kinsing malware attacks
Case 1 – Coinminer Attacks
The coinminer attack chain involves several shell scripts to drop malicious components via deployment of legitimate Docker images on the vulnerable servers (the servers exposed to Docker API).
Malicious Shell Scripts Involved In The Campaign
The threat actors tried to run the Alpine Docker image with chroot command to gain full privileges on the vulnerable server host (a common misconfiguration). The attacker passed curl utility as an argument to the Alpine image which downloads and runs the malicious shell script (hash: fa98add22756cc2041f1dc372c709a4039cd0d6ae000454f728e95165be08abe) on the vulnerable server host as shown below (see Figure 1).
Figure 1: honeypot log – command ran by attacker on the vulnerable server
Cronb.sh (the miner script)
In the above image, the cronb.sh (hash: fa98add22756cc2041f1dc372c709a4039cd0d6ae000454f728e95165be08abe) shell script does the following activities onto the server:
- Tries to disable security monitoring agents like aliyun in the victim system.
- Downloads the xmrig coinminer onto the system.
Figure 2: Xmrig getting downloaded
3. Kills already running miner-related processes (if any).
4. Decodes a Base64-encoded tar file containing the Diamorphine rootkit.
Figure 3: base64 encoded tar file 5. Upon extraction, the rootkit gets deployed into the victim system.
Figure 4: Rootkit installation
6. The cronb.sh at last downloads and runs another shell script named cronis.sh in the system.
Figure 5: cronb.sh downloading cronis.sh
The second stage shell script cronis.sh (hash: cbb37344fdf2429306d4f608237def14465f5667080f6ee43c732d8d42fa7e5b) starts with renaming common utilities as a defense evasion tactic. The script then downloads pentesting tools like masscan and pnscan for scanning open ports on the systems in the victim’s subnet.
The script also checks if the Docker service is active or not. If the Docker service is not active, the script executes commands to start the Docker service with exposed Docker APIs (port 2375).
Lastly, the shell script downloads and runs another shell script named cronscan.
The cronscan (hash: 6826653f0d3728f75d672c3c2dc152a45ecbd34a17bc1117d01fcf3c097586cd) is a shell script that downloads and runs multiple malicious shell scripts in the system which are often used for mass scanning and banner grabbing in the campaign.
Mass scanning to find more vulnerable servers
The shell scripts which get downloaded by cronscan perform mass scanning to find more vulnerable servers. One of those shell scripts is rss.sh (hash: 2b229093689856cf1e606fcfbcb8716e53dc96fffed2fb5f6e5247d088843f4c). The commands inside rss.sh start scanning for the systems having port 6379 opened in the victim subnet. This port, if opened and unauthenticated, gives remote connection via the redis-cli utility.
As a result of scanning, once the target is found, the attacker passes the .dat file as argument to redis-cli utility. The .dat file contains the contents of cronb.sh which we discussed above.
Figure 6: command to run cronb.sh via redis-cli utility on target
Case 2 – Coinminer attack with a different flavor
The second type of the crypto miner attack we found in our honeypot involved heavy obfuscation (see Figures 7 and 8).
Figure 7:honeypot log – crypto miner attack
Figure 8: aaa.sh contents
As we can see in the above figures, the attacker used heavy obfuscation to evade static defenses. On executing the above shell script (hash: 05a65e666492dd8ec5ab0985e5395967bc7bed03e9aaca11cdb9351873093382), the Xmrig miner gets downloaded from github and mining gets started (see Figure 8).
Figure 9: xmrig getting downloaded
Case 3 – Reverse shell based attacks
The third type of attack we observed was the reverse shell based attacks where attackers tried to run a reverse shell on the vulnerable servers. The below image shows the full details of the activity, remotely done by the attacker (see Figure 9).
Figure 10: Details of the remote activity done by the attacker
As we can see in the above image, the attackers perform the following actions via cmdline
- Tried to run the alpine docker image with full privilege.
- Used base64-encoded commands to evade defense mechanism.
- Gave executable permission to the reverse shell binary using chmod utility.
- Tried to register the reverse shell binary in the cron for persistence.
We observed that the reverse shell binary used in this campaign tried to connect to the IP address ‘185[.232.169.211’ and port ‘3242’ (see Figure 8).
Figure 11: reverse shell binary connecting to C2
Case 4 – Kinsing malware attacks
The last and the most commonly seen attacks is Kinsing, a popular malware family seen in the *nix based malware attacks. The Kinsing attack chain includes various defense evasive mechanisms and commands along with a rootkit to hide malicious activity. The main objective of kinsing is to mine cryptocurrency on the vulnerable servers. In our Docker honeypot, we observed a huge magnitude of kinsing related attacks on the vulnerable servers.
Figure 12: honeypot log – kinsing malware attack
The kinsing shell script contains the Docker-related commands which kills already running miner processes (if any are present) on the victim system.
Figure 13: Docker commands to kill already running miners
Figure 14: Kinsing getting downloaded via shell script
The analysis and operation of Kinsing has already been covered in our previous blog.
About the author: Uptycs Threat Research
Docker containers have become a fundamental aspect in application development. If proper protections are not in place, these servers become vulnerable and a playground from which attackers launch and host attacks. Our in-house Docker honeypot monitors Docker related threats continuously and provides intelligence to the team to protect our customers.The EDR capabilities of Uptycs empowers security teams to detect and investigate attacks in their Docker infrastructure.
Further details, including indicators of compromise (IoCs) are available in the original post published by Uptycs.
Please vote for Security Affairs as the best European Cybersecurity Blogger Awards 2022 – VOTE FOR YOUR WINNERS
Vote for me in the sections “The Underdogs – Best Personal (non-commercial) Security Blog” and “The Tech Whizz – Best Technical Blog” and others of your choice.
To nominate, please visit: https://docs.google.com/forms/d/e/1FAIpQLSfxxrxICiMZ9QM9iiPuMQIC-IoM-NpQMOsFZnJXrBQRYJGCOw/viewform
Follow me on Twitter: @securityaffairs and Facebook
(SecurityAffairs – hacking, domain name system)
The post Vulnerable Docker Installations Are A Playhouse for Malware Attacks appeared first on Security Affairs.
If you like the site, please consider joining the telegram channel or supporting us on Patreon using the button below.