Researchers have detailed how Docker containers are becoming a prime target for cryptojackers at a time when fraudulent cryptocurrency mining is a lucrative business.
Cybercriminals are turning away from ransomware deployments in their droves in favor of cryptocurrency malware.
Known as cryptojacking, these malware variants will plunder the CPUs of infected machines in order to steal computational power in order to mine for virtual coins such as Ethereum (ETH) and Monero (XMR), of which these cryptocurrencies are then sent to wallets controlled by attackers.
The problem is becoming more widespread. In recent times, prison sentences have been issued to cryptojacking operators, universities have closed down networks to stop cryptocurrency mining operations, routers have become enslaved for cryptojacking purposes, and one in three organizations have reported crypojacking attacks.
Docker containers are standard units of software which package up code and all dependencies linked to them to increase the speed of applications moving from one computing environment to another.
These lightweight tools can be useful tools within the application development-deployment lifecycle and according to Docker, over 3.5 million applications have been placed in containers using such technology.
However, while Docker increases in popularity with IT professionals, cybercriminals are also exploring how the container technology can be exploited for their own ends.
Researchers from Threat Stack shared insight with ZDNet into how cryptojacking attacks are now taking place against containers used by the enterprise.
The first stage of the attack is to identify front-facing systems and websites vulnerable to remote code injection attacks. A command is sent through the application layer -- often by way of manipulating a text field on a domain or via an exposed API in a website URL -- or by "probing an embedded shell console commonly found on code reference websites," according to the researchers.
The injected code then filters down to the back-end operating system and eventually finds its way to the container environment.
The second phase of such attacks initiates when the container is spun up. In recent attacks spotted, the code is executed and commands are sent directly to the shell within a Docker container.
"While restricted to the container's reduced view of the host operating system, the attacker can now arbitrarily run untrusted code," Threat Stack says.
In stage three, a cryptomining malware is downloaded through a wget command. In attacks which have been observed to date, CNRig has been used to infect machines.
The payload uses the CryptoNight algorithm, which is written in C++, and is compatible with Linux CPUs. Based upon the XMRig Monero rig, CNRig also contains automatic update capabilities.
Threat Stack says that the speed of this stage suggests that automatic scripts are in place to execute the payload, which is followed by the change of permissions on the CNRig executable to make sure it operates without any need for further authentication.
The cryptojacking payload runs out of the /tmp directory.
CNRig will then attempt to establish three connections; two to create a secure pathway between the infected machine and the attacker's mining pool, and one out to a CDN. However, in the cases currently on record, these attempts are not always successful due to networking layer protections and firewalls.
Threat Stack told ZDNet that the company has detected an "increasing number of attackers targeting container orchestration tools like Docker and expect to see this trend to continue as more organizations deploy containers.'
The attack vector is an interesting one and not immediately apparent in connection to cryptojacking. However, when money is to be made, attackers often prove themselves resourceful and innovative.
In order to protect themselves against such threats, the company says that enterprise players should make sure underlying files are not writable from containers; soft and hard limits are set on CPU consumption, and alerts should be enabled for when interactive shells are launched,