Cybercriminals are targeting vulnerable Docker servers by deploying two containers: a standard XMRig miner and the 9Hits viewer application—an automated traffic exchange system.
Cado Security researchers have discovered a new campaign targeting vulnerable Docker servers, deploying two containers – a regular XMRig miner and the 9hits viewer application. This is the first documented case of malware deploying the 9Hits Traffic Exchange viewer application as a payload.
For your information, 9hits is a platform where members buy credits for traffic generated on their website and can run the viewer app to visit requested websites in exchange for credits.
Researchers suspect that the attackers discovered the honeypot via Shodan or a similar service, as their IP isn’t included in common abuse databases, or they may be using a different server for scanning.
Further probing revealed that the attacker is likely using a script to set the DOCKER_HOST variable and run the regular CLI to compromise the server. They fetch off-the-shelf images from Dockerhub for their 9hits and XMRig software, a common attack vector for campaigns targeting Docker.
Generally, attackers use a generic Alpine image to break out of a container and run malware on the host. In this campaign, however, they do not try to exit the container and run it with a predetermined argument.
The spreader initiates the infection using a custom command to invoke a Docker container, including configuration/session identifiers. The nh.sh process is the entry point, and after the attacker adds their session token, it allows the 9hits app to authenticate with their servers and fetches a list of sites to visit. Once the app has visited the site, the session token owner is awarded a credit on the 9hits platform.
It is worth noting that the session token system is designed to work in untrusted contexts, allowing the app to be run in illegitimate campaigns without the risk of the attacker’s account being compromised.
9hits, a headless Chrome app, is used to visit various websites, including adult and pop-up sites. In 2017, Chrome 59 introduced Headless mode, allowing users to run the browser in an unattended environment without visible UI, making it popular for browser automation with projects like Puppeteer or ChromeDriver.
According to Cado Security’s blog post, interestingly, the attacker disabled the app’s ability to visit crypto-related sites. The -o option in XMRig deployments specifies a mining pool, typically a public pool with the owner’s wallet address, but in this case, it appears private, preventing campaign statistics analysis.
Further, as seen in the image below, the dscloud domain is used for dynamic DNS, updated by the Synology server with the attacker’s IP. The address resolves to 2736.82.56, the same IP that infected the honeypot.
Exposure to Docker hosts remains a common entry vector for attackers, emphasizing the importance of maintaining system security to prevent malicious use of systems. The campaign significantly impacts compromised hosts by exhausting CPU resources, causing legitimate workloads to fail.
Additionally, it could potentially leave a remote shell on the system, causing a more serious breach. This highlights the ongoing trend of attackers seeking new strategies to exploit compromised hosts.
RELATED ARTICLES
- Change your password: Docker suffers breach; 190k users affected
- Hackers Exploit Adobe ColdFusion Vulnerabilities to Deploy Malware
- Threat actors hijacking Bitbucket and Docker Hub for Monero mining
- OracleIV DDoS Botnet Malware Targets Docker Engine API Instances
- Kinsing Crypto Malware Targets Linux Systems via Apache ActiveMQ Flaw