I’ve discussed Ransomware Defence in Depth and in this post I’m discussing how to defend in depth against another pesky issue Unauthorized Cryptocurrency mining.

Unauthorized cryptocurrency mining is alongside ransomware one of the major outcomes bad guys gaining access to your cloud resources are looking to achieve.

I’m going to focus on Google Cloud as that is the Cloud I know best these days but the other large Cloud providers have equivalent defences to the ones I discuss here.

Firstly you need to consider how crypto mining software gets onto your compute resources .

Google cloud discusses exploitation of GCE instances in their November Threat horizons report which provides insights into the scale of the problem.

The table below is taken from the report and lists the exploited vulnerabilities in Cloud Instances

The report also details how time critical it is when a cloud instance is compromised :

“The shortest amount of time between deploying a vulnerable Cloud instance exposed to the Internet and its compromise was determined to be as little as 30 minutes. In 40% of instances the time to compromise was under eight hours. "

Where timeline information was available, it revealed that in 58% of situations the cryptocurrency mining software was downloaded to the system within 22 seconds of being compromised, the figure (taken from the report ) below illustrates this.

There is no guarantee that protections you put in place to prevent exploitation of your cloud resources and with that the accompanying alarming bill means that you will not suffer a breach! It is however , almost guaranteed that if you do not put any protection in place, the probability that you will be subjected to a breach and suffer the consequences is very high.

As with all good security practices, defence in depth is required, thus I’m going to discuss 12 actions you need to do as a very minimum to protect your cloud resources against the threat of unauthorized cryptocurrency mining.

1. Understand the threat vectors . Read the latest threat reports to get an understanding of the threats and what measures you can take to help protect your accounts and cloud assets. At the time of writing the latest edition is the November 2021 Threat horizons report ( I also like the Microsoft Digital Defense Report but it’s sooo long ) . Many mitigations to protect against Unauthorized cryptocurrency mining are similar to those detailed in Best Practices for mitigating ransomware attacks , so please read that article as well and you can also read my own post on Ransomware Defence in Depth if you haven’t already . Reading govt advisories such as NCSC advice: Malicious software used to illegally mine cryptocurrency from the the UK NCSC which was in response to a specific bitcoin mining vulnerability which should also be on your regular reading list. Read the Security bulletins and product specific security bulletins were available such as the Compute Engine Security bulletins . Subscribe to security sites that will help you keep up to date with the current threats.

2. Understand the support options and set up a support account. If you need help, contacting support is the way to get help in a timely manner. If you suspect unauthorized access to your accounts, contacting support asap should be high up in your incident response plan.

3. Have a well documented prescriptive incident response plan. In an emergency you need to be confident it can be used in a consistent way.

4. Reduce exposure of your Compute resources ( GCE VMs, GKE Clusters) to the internet

   1. Do not grant GCE VMs a publicly accessible IP address
   2. Use private GKE clusters
   3. Implementfirewall rules to restrict inbound ( ingress rules) and outbound (egress rules) traffic to the internet
   4. Use VPC Service Controls to control communications to your Compute resources outside of a defined perimeter
      1. Use context-aware access to control access to Google Cloud services from the internet based on context-aware access attributes like IP address and a user’s identity.
      2. Configure service perimeters to control communications between Compute resources and managed Google Cloud resources. Service perimeters allow free communication within the zone ( in this context zone is the environment enclosed by the perimeter) and block all service communication outside the perimeter.
      3. Implement zero trust techniques using BeyondCorp
      4. Use Identity-Aware Proxy (IAP) . IAP’s TCP forwarding feature lets you control who can access administrative services like SSH and RDP on your backends from the public internet. The TCP forwarding feature prevents these services from being openly exposed to the internet.
      5. Read Securely connecting to VM instances . This discusses mitigations such as using Cloud NAT for outgoing communication and using a proxy load balancer for incoming communications

5. Securely manage your Compute resources

   1. Enforce Shielded VM by using the Organization policy constraint Compute Engine: Shielded VMs. Shielded VM offers verifiable integrity of your Compute Engine VM instances, to provide confidence that your instances haven’t been compromised by boot- or kernel-level malware or rootkits
   2. Restrict the images that can be used in your accounts
      1. Implement trusted image policies by configuring the Organization policy constraint Compute Engine : Define trusted image projects . This constraint defines the set of projects that can be used for image storage and disk instantiation for Compute Engine.
      2. For images used by your GKE clusters use minimal distributions that include only the software and libraries that are needed to run your application. Use managed base images , these get regularly updated with security patches. Where you can use Distroless images which contain only your application and its runtime dependencies. They do not contain package managers, shells or any other programs that are typical of a standard Linux distro.
      3. Use container analysis to provide vulnerability information for the container images in Container Registry and Artifact Registry
   3. Use OS Login to manage SSH access to GCE VMs. OS Login simplifies SSH access management by linking your Linux user account to your Google identity. It provides among other features fine grained authorisation using IAM to grant SSH access to a user’s Google identity without granting a broader set of privileges.
   4. Do not download service account keys for applications that are outside of Google cloud yet need to access Google cloud resources , use Identity federation Follow the guidance in Best practices for managing service account keys
   5. Patching .You should always patch as in many cases the attack vector is by exploiting a vulnerability that has a patch available but you haven’t got around to patching! Google cloud has services to help with this - OS patch management for GCE and for GKE Google automatically patches vulnerabilities
   6. Exploiting misconfigurations and software vulnerabilities are the most common ways of gaining unauthorized access to your compute resources so scanning for vulnerabilities & misconfigurations is something you must undertake regularly . Subscribe to Security Health Analytics premium to to get insights into misconfigurations in your compute resources . Compute Instance findings and Container findings provide insights into misconfigurations of your compute resources. Take advantage of Container scanning which is the Container Analysis automated and manual vulnerability scanning service for containers in Artifact Registry and Container Registry.  

6. Protect the doorway to your applications . Cloud Armor provides Denial of Service and Web Application Firewall (WAF) protection for applications and services hosted on Google Cloud, on your premises, or hosted elsewhere. The post https://cloud.google.com/blog/products/identity-security/cloud-armor-waf-rule-to-help-address-apache-log4j-vulnerability discusses how to use Cloud Armor as part of your defence in depth mitigation against the log4j vulnerabilities that was made public at the end of 2021. The log4j vulnerabilities (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2021-44228+ ) are yet another attack vector . It can be used to introduce malware that can be used to undertake unauthorized cryptomining and also introduce ransomware to your compute resources.

7. Detect anomalous activity

   1. Set alerts on activities such as starting up GCE and GKE clusters Compute Engine audit logging information and kubernetes engine how to configure audit log example filters for your admin activities
   2. Use the Security Command Center
      1. Use ETD to monitor for dubious activity
   3. Use Cloud IDS to help detect network-based threats such as malware.

8. Secure software supply chain

   1. Implement Software Supply chain mitigations by using features such as Binary Authorization . Binary authorization requires images to be signed by trusted authorities during the development process and then enforce signature validation when deploying. follow the guidance detailed in Help secure software supply chains on Google Kubernetes Engine
   2. Shift left so implement security earlier in your ci/cd process. The white paper Shifting left on security: Securing software supply chains discusses this . Help secure software supply chains on Google Kubernetes Engine is a nice example of how to do this for GKE

9. Securely Manage accounts & account credentials

   1. Restrict who can access your cloud environment configure the Organization policy constraints
      1. Identity and Access Management: Domain restricted sharing to restrict the Cloud Identity or Google Workspace customer IDs whose principals can be added to IAM policies.
      2. Identity and Access Management: Allowed AWS accounts that can be configured for workload identity federation in Cloud IAM
      3. Identity and Access Management:Allowed external Identity Providers for workloads in Cloud IAM
      4. Enforce uniform MFA to company-owned resources
   2. Have a robust process in place to disable accounts or remove assigned roles when employees leave the role that required access to the resources or leave the company
   3. Manage groups carefully to avoid adding non corporate accounts to groups used in IAM policies . The Set organization-wide policies for using groups - Google Workspace Admin Help article discusses this
   4. Regularly audit your user and group configurations. There are Audit logs for Google Workspace to assist you with this task

10. Implement Least privilege

    1. Use Cloud IAM to manage permissions .
       1. Use workload identities with your GKE clusters
    2. Use the org policy Restricting service account usage : disable_service_account_default_grants to disable the automatic default role granted to service accounts
    3. Use role recommendations to help you identify excess permissions . Define a regular schedule to check these permissions.

11. Manage service account & encryption keys carefully

    1. Monitor keys for usage , Use Service account insights to get visibility into notable patterns in resource usage. For example, permission usage in your project, or identifying unused service accounts. View recent usage for service accounts and keys to see when your service accounts and keys were last used to call a Google API ( authentication activities).
    2. Rotate your encryption keys managed by Cloud KMS keys regularly. Service accounts that Google-managed key pairs are automatically rotated
    3. Avoid downloading keys to remote machines if you can
    4. Service accounts are an important resource when working with Google cloud so follow best practices when working with them see Best practices for using and managing service accounts and Best practices for securing service accounts
    5. If you really must download keys make sure you have a key rotation process in place . Understand the mitigations third parties have in place such as Github Secret scanning which warns you about exposed secrets . Maybe you could avoid using external repositories and put processes in place to prevent their use. Google Cloud provides private git repositories for this use case.
       1. You should put in place preventive measures to stop keys from being committed to your git repo. One open-source tool you can use is git-secrets . This is configured as a git hook when installed
       2. Use Secret management solutions like Hashicorp vault and Secret manager ensuring least privilege is applied and you rotate your secrets regularly

12. Implement a disaster recovery plan . In case of unauthorized access to your cloud resources you need to ensure that not only is the threat vector used to access your resources closed off but that your environment is reconstructed from a known good state I’d like to give a huge thanks to my colleague Ido for reviewing this list despite replacing my “s’s” with “z’s” !