Part 1: Information Leakage Risks when Using Google Cloud

According to the latest report from the Cyber Security Action Team at CMC Telecom, 86% of recently compromised Google Cloud accounts were used to mine cryptocurrency. Hackers deployed cryptocurrency mining software within just 22 seconds of successfully breaching an account. When a Google Cloud account is hijacked for crypto mining, users face astronomical billing charges (potentially reaching billions of VND) in a very short span of time, alongside the risk of losing business-critical data.

Primary Attack Vectors

• Weak or missing passwords for user accounts and API connections (48%). This remains a highly prevalent oversight among users who fail to implement rigorous credential protection. Threat actors can easily brute-force, guess, or harvest these credentials to gain unauthorized access to GCP accounts.
• Vulnerabilities in third-party software deployed on the cloud (26%). Many organizations run third-party software to manage or interface with GCP without conducting routine audits or upgrading to the latest patched versions. This exposes security gaps that hackers can exploit to infiltrate the system.
• Credential leakage within code repositories on GitHub (4%). Developers occasionally expose sensitive credentials by mistakenly committing GCP configuration files or credentials to public repositories on GitHub. Threat actors constantly scan public platforms to harvest these credentials and abuse GCP resources.

Service Accounts: A Primary Target for Hackers

A Service Account is a special type of identity on Google Cloud Platform (GCP) used to authenticate and authorize applications and system-level services. Service accounts can be created and managed directly by users or managed automatically by Google.

One of the most common methods to allow an external application to authenticate as a service account is to generate a service account key and use it to acquire OAuth 2.0 access tokens. There are several typical vectors through which hackers compromise service accounts:

• Searching and harvesting service account private keys from publicly exposed source code or files on the Internet. These keys are typically JSON or P12 files containing private cryptographic credentials. If a hacker acquires these files, they can immediately authenticate and access the GCP environment as that service account.
• Exploiting security vulnerabilities in applications or virtual machines running with attached service accounts. Once inside these compromised workloads, threat actors can read service account access tokens directly from environment variables or the instance metadata server, utilizing them to call Google APIs and execute unauthorized tasks.
• Employing phishing or social engineering tactics to trick administrators into revealing service account credentials. Attackers impersonate Google support staff or reputable organizations to direct users to credential-harvesting landing pages.

Cryptojacking: The Consequences of Service Account Compromise

Exposing a Service Account provides threat actors with a direct entry point into the GCP environment, allowing them to abuse compute resources to mine cryptocurrency. This technique is formally known as Cryptojacking. To weaponize a compromised service account for unauthorized mining, hackers typically:

• Use the leaked secret keys of the service account to authenticate with tools such as gcloud or gsutil. Once authenticated, they create high-performance virtual machines or hijack existing instances on GCP to run cryptocurrency mining software. They may also call Google APIs to provision additional costly cloud resources.
• Exploit existing application-level vulnerabilities to gain shell access on instances. They then fetch access tokens via the metadata server using the attached service account to download and run optimized mining scripts.

Root Causes of Service Account Key Leaks

The root cause of service account compromise lies in the insecure management and storage of service account keys. Common scenarios leading to exposure include:

• Using Terraform to provision GCP resources while failing to encrypt or omit hardcoded service account keys from state files or configuration code.
• Accidentally committing and pushing service account keys to GitHub or other public source control platforms.
• Sharing service account keys over insecure messaging and communication channels (e.g., Zalo, Facebook, Telegram, etc.).
• Reusing a single service account key across multiple distinct applications, staging, or production environments.

This represents a severe threat vector that can incur catastrophic financial and operational damage. In Part 2, CMC will outline critical remediation steps and robust long-term preventive measures.

Part 2: Remediation and Preventive Measures

Immediate Incident Response

If you suspect or confirm that a service account key has been compromised, perform the following recovery actions immediately:

1. Disable or Delete the compromised service account: Navigate to IAM & Admin > Service Accounts > Select the suspected service account > Click Disable or Delete.
2. Audit all actions taken by the compromised identity: Navigate to IAM & Admin > Audit Logs > Set Resource Type to “Service Account” > Filter by the specific service account’s email > Review the recorded API calls and operations.
3. Purge unauthorized GCP resources created by the threat actor. For instances running under Compute Engine, you can do this via:
   • The Google Cloud Console: Navigate to the VM Instances page, select the unauthorized VMs, and click Delete.
   • The Google Cloud CLI (gcloud): Execute the `gcloud compute instances delete` command specifying the target VM names. You can use flags like `–zone`, `–quiet`, and `–delete-disks` to control the cleanup process. For example:

     gcloud compute instances delete vm1 vm2 vm3 --zone us-central1-a --quiet --delete-disks all

4. Contact CMC Telecom Support immediately to report the breach so that our team can coordinate directly with Google to limit financial liabilities and secure your tenant.

Long-term Preventive Strategies

To prevent service account credential leaks in the future, implement the following best practices:

• Minimize the use of static service account keys. We strongly recommend using keyless authentication alternatives such as Workload Identity Federation(*), Service Account Impersonation(**), or directly attaching service identities to resources running your workloads. These methods significantly reduce the security risks associated with storing static keys.

  (*) Workload Identity Federation is a feature that allows workloads running outside of GCP (e.g., on-premises or in other clouds) to authenticate securely as a service account. By linking an external Identity Provider (IdP) with a GCP service account, external workloads can exchange their federated tokens for short-lived GCP access tokens, eliminating the need to store static keys.

  (**) Service Account Impersonation allows a user or another service account to dynamically act on behalf of a target service account. This allows you to delegate privileges temporarily and control access without distributing or managing static, long-lived service account keys.

• Enforce the Principle of Least Privilege (PoLP). Grant service accounts only the minimum IAM roles and permissions necessary to execute their designated tasks. This minimizes the blast radius and prevents lateral movement if an identity is compromised.
• Limit key counts and enforce short lifespans. Only generate keys when absolutely necessary, establish strict expiration windows, and implement automated rotation policies. Ensure unused or expired keys are immediately deleted.
• Encrypt and secure keys in transit and at rest. Utilize specialized key and secret management tools like Cloud KMS, Cloud Secret Manager, secure Cloud Storage buckets, or secure Cloud Build pipelines. Never exchange keys over insecure channels.

  Integrating Cloud Secret Manager with Infrastructure as Code:

  Cloud Secret Manager is a secure GCP service designed to store, manage, and audit sensitive secrets such as passwords, API keys, and certificates. You can use it to store Service Account keys securely and retrieve them dynamically via Terraform. Here is a quick implementation flow:

  Step 1: Provision the secret and upload the key payload securely to Cloud Secret Manager.

  Step 2: Programmatically read the secret value within your Terraform configurations:

  Use the google_secret_manager_secret_version data source block to reference the latest version of the secret at runtime:

  resource "google_secret_manager_secret_version" "my_service_account_key" {
    secret  = "my-service-account-key"
    version = "latest"
  }

• Conduct continuous Security Awareness Training. Empowering your engineering team is critical. Ensure your developers and administrators are fully trained on secure coding practices, key hygiene, and the severe risks of committing credentials to source control platforms like GitHub.
• Enforce Organization Policies and Quotas to restrict anomalous resource usage across GCP:

  Configuring Organization Policies

  Step 1: Navigate to the Organization Policies page in the Google Cloud Console.

  Step 2: Select the target organization node, folder, or project where you want to apply the restriction.

  Step 3: Search for and select the Restrict Resource Locations constraint.

  Step 4: Click Edit to customize the policy definition.

  Step 5: Specify allowed or denied geographic regions and zones. Use filter prefixes such as in:, not-in:, has:, or not-has:. For example: `in:us-locations`, `not-in:asia-southeast1-a`, `has:europe`, `not-has:southamerica`. This prevents attackers from spinning up resource-intensive instances in unmonitored regions.

  Step 6: Click Save to enforce the policy.

  View Detailed Documentation

  Enforcing Service Quotas

  Step 1: Navigate to the Quotas & System Limits page in the GCP Console.

  Step 2: Select the specific project you want to restrict.

  Step 3: Filter by service, for example: Compute Engine API.

  Step 4: Locate the metric you want to limit, such as VM Instances or CPU quotas.

  Step 5: Click Edit Quotas to adjust the maximum limit.

  Step 6: Set a safe maximum capacity threshold aligned with your daily operations (e.g., 10).

  Step 7: Click Submit Request to save and apply the new quota limit.

  View Detailed Documentation

CMC Telecom is committed to partnering with you to audit your security posture, review IAM configurations, and assist in setting up robust, optimized Policies and Quotas.