Malicious Cryptomining Shifts Malware Focus from Data Theft to Compute Power in the Cloud

In this new TEC17 episode from World Wide Technology, Mike Schmidt of WWT and Austin McBride from Cisco's Umbrella practice discuss this serious cyber threat.

Tell me about cryptomining

Before digging into cryptojacking, we first need to discuss cryptocurrencies.

Cryptocurrencies, like Bitcoin, have gained substantial popularity in the last few years due to all-time high market prices with incredible returns compared to the traditional stock market. For example, a single Bitcoin sells for close to $10,000 today up from a mere $50 five years ago. While they are not tangible assets, cryptocurrencies are traded like commodities on specialized exchanges as part of a marketplace that is generally anonymous, volatile and unregulated.

Where compute power comes into play is in the way cryptocurrencies are minted within the technology itself. While there are many articles online to explain this concept more thoroughly, think of Bitcoin technology as a payment processor similar to Visa or Mastercard. When a user makes a purchase or transfers Bitcoin to another user, the first user's balance isn't validated by a central entity like Visa, but rather across a set of individual user machines distributed around the globe. These "miner" machines serve two purposes: (1) to validate Bitcoin transactions in a distributed manner that yields a reward, and (2) to facilitate the minting of new Bitcoins into the ecosystem.

Therefore, cryptomining is the distributed process of validating transactions and minting Bitcoin at the expense of vast amounts of compute power and, ultimately, the cost of electricity.

Cryptomining technology has moved from CPU to GPU to ASIC-based hardware that is exponentially more efficient at the mining process. If an average Joe were to turn their laptop into a cryptominer using a generic CPU, they'd likely stand to make $0.01 every month in today's competitive market. But what if the average Joe had an unlimited, scalable fleet of cheap CPUs each making $0.01 a month without having to pay for it? Sound familiar?

So, then what is cryptojacking?

The main expenses cryptominers attempt to minimize are the cost of mining hardware (CapEx) and the electricity required to run it (OpEx). While hardware is a fixed cost, simple math dictates that if operating mining profits are less than the total cost of electricity, it's not worth mining. Factors like local electricity cost, current Bitcoin price and current mining difficulty are all part of that equation. If the cryptominers can find a way to run their mining processes without having to pay for electricity, that represents pure profit.

Cryptojacking is the method of maliciously infiltrating target public cloud accounts to spin up countless cheap compute instances to run cryptomining processes paid for by the target's billing account and associated credit card. From an attacker's perspective, they get access to an unlimited fleet of compute instances that can be deployed on-demand while the account owner foots the bill.

Any account on a public cloud service provider (CSP) like Amazon Web Services (AWS), Microsoft Azure and Google Compute Cloud (GCP) are susceptible to this attack. The only real requirement is that the attacker obtain permission to create compute instances with specific user data that can be executed at start-up to run the mining software. Attackers typically start small and then increase the number of compute instances over time, slowly or rapidly depending on how proactive the targeted account owner is in detecting the malicious behavior.

Because an attacker's main motivation is generating mining revenue, cloud finance groups bear the brunt of cryptojacking attacks from a corporate exposure perspective. While the focus of an attack is not sensitive data extraction or application exploitation, an attack is a canary in the coal mine that can signal the existence of much larger cloud security gaps. Potential areas to review include identity and access management (IAM), infrastructure security, central logging and event management, and a lack of behavioral analytics for cloud user access.

Four phases of a cryptojacking attack

As we discuss the phases of a cryptojacking attack, let's also review the methods that can prevent these attacks by utilizing a strong end-to-end security posture. Remember that if the security team is successful in only blocking one phase, the whole attack is thwarted. This idea is also known as defense in depth and is the cornerstone of modern security strategy.

Phase 1: Attacker steals user's cloud provider API key via exploit or social engineering.

To be able to deploy the compute instances, the first thing an attacker needs is API credentials. There are a few different methods attackers can use to obtain these, including end-user malware exploits and social engineering. Unfortunately, the most common method is the fault of the end-user by hard-coding API credentials into GitHub scripts or public cloud storage, like AWS S3, which can easily be scanned.

Prevention Tips: Never store hard-coded API credentials in scripts/files; require social engineering training for employees, anti-malware for end-users and anti-phishing for email; and scan public cloud storage accounts for sensitive information and credentials.

Phase 2: Attacker tests the stolen API key's IAM permissions by deploying instances.

The attacker's next step is to test the API credentials to confirm the associated IAM permissions allow deployment of compute instances. Many organizations attempt to build IAM permissions with least-privilege to avoid attacks like these, but if the attacker steals the credentials of a network or server admin, then they most likely still have access to building compute instances.

After configuring a strict IAM permissions policy, the main method of prevention is to utilize machine learning technology called User/Entity Behavioral Analytics (UEBA) that will trigger an alert when API calls processed from specific end-users seem atypical.

Prevention Tips: Build IAM permission policies with least privilege; utilize tools like AWS Access Advisor to periodically review user access history for tighter IAM policy; and use UEBA tools to build user baseline activity so abnormal activity triggers an alarm to review.

Phase 3: Attacker can deploy an unlimited amount of compute instances without restriction.

Once the attacker knows the API key allows them to deploy compute instances, the next step is to spin up a few small compute instances to confirm there are no established rate limits. Attackers are also checking what instance types they can deploy as compute power varies greatly between a t1.micro and a c4.x4large in AWS, for example. Attackers are looking to maximize profit, so if they can turn up hundreds of the highest tier compute instances and not have to pay the bill, they are strongly motivated to do so at the expense of the target account.

Prevention Tips: Limit what instance types can be deployed in IAM policies; create guardrails for the number of instances that can be deployed at a time as well as restricting CSP region; create billing alerts to quickly detect the recent surge of compute power in the cloud environment; use UEBA tools to detect abnormal user behavior; and utilize cloud asset management tools like AWS Config to continuously monitor instance inventory.

Phase 4: Compute instances are deployed with cryptomining software enabled at start up.

At this point, the attacker knows exactly what they can get away with in the affected user's cloud account. The next step is to deploy compute instances with simple start-up scripts that automatically download, install and run cryptomining code. When these compute instances fully start up, they will immediately begin the mining process and consume compute credits while reaching out to their central mining pool via DNS to obtain monetary rewards.

This communication between instance and mining pool is key, as without it the attacker won't get any credit for their cryptomining compute tasks. While the affected cloud account continues to pay for instances in this scenario, the attacker becomes disincentivized if they cannot obtain a cash payout and may move on to another victim.

Prevention Tips: Configure tight network Security Groups (SG) and Network Access Control Lists (NACL) that only allow very specific traffic in and out of the cloud compute environment; utilize a DNS security toolset like Cisco Umbrella that catalogues and blocks malicious DNS entries tied to cryptomining to stop communication between compute instance and the web pool; and use a next-generation firewall (NGFW) at the cloud ingress/egress that can also detect this communication path.

Conclusion

Cryptojacking has become the "low-hanging fruit" of the cloud malware world and should not be taken lightly. As previously stated, a successful cryptojacking attack has much larger security implications for an organization's public cloud security posture and needs to be examined thoroughly. While CSPs create environments that make it simple for customers to deploy services quickly, the flipside is that attackers who obtain the same credentials have an unlimited supply of on-demand resources to deploy at the organization's expense.

While on-premise data centers are considered high trust by most security teams, public cloud is viewed as low trust and needs to be treated as such. Security strategies of least-privilege access, defense in depth and behavioral analytics should be mandatory facets of cloud security design. These require the combined efforts of development, operations and security teams working together to deploy, manage and secure resources in the cloud.

If you'd like to learn more, listen to our TEC17 podcast where I talk to Cisco security engineer Austin McBride about cryptojacking and how Cisco's Umbrella DNS security suite can help prevent this type of attack (among many others).

WWT also offers a Cloud Security Workshop focused on security strategy planning and optimization. The workshop includes a tools rationalization discussion to help organizations discover gaps in their existing security architecture and build a roadmap for a stronger security posture. Reach out to your local WWT representative to learn more.