Cisco Talos spotted the campaign when its honeypots logged a potential Docker attack from an obscure crypto mining botnet. An investigation into this attack revealed that only a few anti-malware engines had spotted earlier samples of the botnet. Even then, security firms had identified just one of the scripts used by the botnet to carry out its attacks.
The investigation also provided some insight into the infection chain. An attack began when an initial script, “pop.sh,” downloaded and ran the main bot module, “xanthe.sh.” (Cisco Talos named the attack “Xanthe” after this module.) At that point, xanthe.sh ran an initialization procedure that attempted to run two additional modules. These were as follows:
In its investigation, Cisco Talos confirmed that the Xanthe variant used SSH to spread. The threat did this by configuring the SSH daemon to be less secure and enable functionality, at which point it restarted the SSH service. The attack then used the localgo function to connect to icanhazip.com and obtain an externally visible IP address of the infected host. Xanthe used the same utility to search for client-side certificates so that it could authenticate to remote hosts.
As it’s the security firm explained in its report:
Once all possible keys have been found, the script proceeds with finding known hosts, TCP ports and usernames used to connect to those hosts. Finally, a loop is entered which iterates over the combination of all known usernames, hosts, keys and ports in an attempt to connect, authenticate on the remote host and launch the command lines to download and execute the main module on the remote system.
Researchers at Cisco Talos also found that the attack came with Docker scanning and spreading capabilities, though that functionality was commented out at the time of analysis.
Containerized environments have many more components than traditional VMs, including the Kubernetes orchestrator that poses its own set of security challenges. Can you tell which deployments or clusters are affected by a high-severity vulnerability? Are any exposed to the Internet? What’s the blast radius if a given vulnerability is exploited? Is the container running in production or a dev/test environment?
Those are not rhetorical questions. Organizations need to work to understand the risks confronting their Docker deployments and take steps to protect them against digital attackers. Towards that end, they can view Docker’s documentation to learn about some important security recommendations that they can use to their advantage. More information is available here.
About the Author: David Bisson is an information security writer and security junkie. He's a contributing editor to IBM's Security Intelligence, Tripwire's The State of Security Blog, and a contributing writer to Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.
