Vulnerable Docker Installations Are A Playhouse for Malware Attacks

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:

1. Tries to disable security monitoring agents like aliyun in the victim system.
2. 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

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.

 

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

rss.sh

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

Conclusion

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.

https://www.uptycs.com/blog/vulnerable-docker-installations-are-a-playhouse-for-malware-attacks?hs_preview=roycVWho-72459548548

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

Pierluigi Paganini

(SecurityAffairs – hacking, domain name system)

The post Vulnerable Docker Installations Are A Playhouse for Malware Attacks appeared first on Security Affairs.