Crypto-currency malware running in your cloud environment

05 December 2018
6 minute read
Best practice

Crypto-currency malware running in your cloud environment

05 December 2018
6 minute read

Management and governance of cloud assets is a big, and growing, area for ITAM professionals to tackle. As more assets sit in the cloud, they need managing in more ways than ever before – making it a fantastic opportunity for ITAM to grow as a discipline and an industry. Equally, security is hugely important in a cloud world and so these two areas, ITAM and Security, need to work together more closely than ever before to keep organisations safe.

This latest security breach is a great example of that.


Crypto currencies such as Bitcoin and Ethereum have been big news for a while now – with some reaching a high of $20,000 per “coin”. If these digital currencies could easily be produced on any computer, that would be the same as a bank continuously printing more money – leading to devaluation until the currency becomes worthless. To this end, the coins must be “mined” – a process that requires a lot of power, both computing and electrical. The Digiconomist site estimates that each Bitcoin transaction consumes 727 KWh of energy, and that 52 – 73 TWh of energy are consumed overall each year. Bitcoin, if it were a country, would rank 39 globally in terms of energy consumption – ahead of Austria, Chile, and the Czech Republic.


A new technology with little regulation and the chance to “literally” create money has, of course, attracted a less savoury element. One strategy is to use other people’s computers and energy to mine these coins – reducing the criminals’ costs and maximising their profits.

This attack is used to mine “Monero” coins – a crypto-currency, known for its secrecy, that was used during the WannaCry malware attack.


We’ve seen malware that targets individual PCs and browsers to mine coins, but Juniper Networks have discovered criminals targeting public cloud infrastructure – specifically, those running Docker containers.

Docker provides APIs (Application Programme Interface) which allow programs to manage the service. Remote access requires Docker to be configured to listen on specific TCP (Transmission Control Protocol) ports, namely 2375 and 2376. By default, the access these ports provide is unencrypted and unauthenticated.

Unencrypted and unauthenticated means easy access to the Docker container management interface. This attack uses scripts to create a new container, infected with the “Minero” miner, which not only starts mining the crypto-currency but also actively seeks to spread the infection to other Docker containers.

2. Infection Diagram, courtesy of Juniper Networks

What it means for ITAM

From a financial perspective, this attack uses cloud resources which you will be paying for. Many organisations don’t have a good understanding of their cloud infrastructure and spend, an environment perfect for malware. Depending on the services and providers you use, this malware may cause costs to be higher than expected or credit to be used faster than planned.

If you don’t know what cloud resources are being used, where, and by whom, and you can’t accurately predict your cloud bill – how are you going to notice this? This technological cuckoo will happily roost in your cloud until you finally find it or Bitcoin crashes completely, whichever comes first. Although containers, by their very nature, may be short lived, if those being used for crypto-mining are in an unmonitored/forgotten cloud, they may survive for a long time.

Securing ports of cloud containers most likely sits with the security team, and rightly so. However, this is a great example of how communication between multiple teams is required to keep ITAM successful. You need to have the communication channels in place in order to identify and talk to the right people about a risk like this. It also shows the importance of ITAM keeping up to date on “non-ITAM” or “ITAM adjacent” topics – the more you know, the better prepared you can be.

Containers are a relatively new technology and perhaps not something that would impact “traditional” ITAM too much…but you can see here the need for ITAM to know enough to ask if they’re being used within the business and to be aware of potential problems.

There are other issues too. If these attackers can do this, with an automated script, what else could they – or others – do? Allowing malicious strangers access is never a good idea. Your organisation currently has, I imagine, plenty of security in place to prevent intrusion of your on-premises infrastructure…the same is needed for the cloud. Public cloud providers such as Microsoft and Amazon spend a huge amount of time, effort, and money on ensuring their infrastructure is secure…but that only applies to what they can control. Things that customers do/install/configure in the cloud need securing and protecting just like on-premises, perhaps even more so.

There’s also the reputational risk. If your organisation is found to be infecting others with this malware, no matter how unwittingly, that has the potential to cause some real issues for the business…especially those in certain sectors.

So much of what we’re saying now is about fostering relationships between ITAM and other parts of the business, about elevating ITAM to something more than it has been more, about gaining C-Level focus and attention for ITAM, and this is another example of WHY you should do this and another opportunity TO do this.

An ITAM function that can confidently state what is in the cloud, where it is, and why it was created will be integral to managing situations like this. Even better if ITAM can track when cloud resources should be decommissioned to prevent wasted spend and/or malware infection.

Further Reading

Juniper post –

Bitcoin energy consumption –

Monero –

Can’t find what you’re looking for?