Exposed Google Cloud API Keys Leak Sensitive Gemini Data Across Thousands of Endpoints

The rapid integration of Generative AI into production environments has created a new attack surface that many organizations are failing to secure. Recent research from Truffle Security has uncovered a disturbing trend: nearly 3,000 Google Cloud API keys are currently exposed in public client-side code, potentially granting unauthorized access to sensitive Google Gemini endpoints.

At Security Arsenal, we see this as a critical failure in secret management. It is not just a "misconfiguration"; it is an open door to proprietary data and AI models.

The Threat: When Project Identifiers Become Access Keys

The core of the issue lies in how API keys are misunderstood. Many developers treat Google Cloud API keys—specifically those starting with the AIza prefix—as simple project identifiers used for billing or low-level service routing. Consequently, they embed these keys directly into client-side JavaScript or mobile applications to facilitate easy access to Google services.

However, when the Gemini API is enabled on a project, these same keys transform into authentication tokens. Attackers can extract these keys from public repositories or client-side bundles and use them to query the Gemini API. Depending on the permissions associated with the key, this could lead to:

• Data Exfiltration: Accessing private prompts, responses, or training data associated with the endpoint.
• Resource Hijacking: Using the victim's quota to generate content or run models (LLMjacking).
• Privilege Escalation: If the key has broader scopes beyond the specific AI service.

Deep Dive: Attack Vectors and TTPs

The Misconfiguration

The vulnerability stems from a lack of scoping. Google Cloud allows API keys to be restricted by Application, IP address, or API. In these incidents, the keys were likely generated with broad permissions or no application restrictions, allowing them to be used from anywhere by anyone who possesses the string.

The Attack Chain

1. Discovery: Attackers scan public GitHub repositories, npm packages, or decompose mobile application bundles (APK/IPA) to search for the regex pattern associated with Google API keys.
2. Validation: The attacker tests the key against the Google Cloud discovery API to confirm it is active and which services are enabled.
3. Exploitation: The attacker issues requests to the Generative Language API (Gemini) using the stolen key to extract information or abuse the service.

TTPs (Tactics, Techniques, and Procedures)

• Tactic: Credential Access
• Technique: Unsecured Credentials (Credentials in Files)
• Technique: Steal Web Session Cookie (if keys are stored in local storage)

Detection and Threat Hunting

Identifying exposed keys requires a two-pronged approach: scanning your public and private codebases, and monitoring cloud logs for abuse.

1. Secret Scanning with Python

You can automate the discovery of these patterns in your local repositories using a Python script. This script scans for the common AIza prefix.

import os
import re

def scan_for_api_keys(directory):
    # Regex pattern for Google Cloud API keys starting with AIza
    pattern = re.compile(r'AIza[A-Za-z0-9\-_]{35}')
    
    for root, dirs, files in os.walk(directory):
        for file in files:
            if file.endswith(('.js', '.ts', '.py', '.java', '.go', '.txt', '.env')):
                file_path = os.path.join(root, file)
                try:
                    with open(file_path, 'r', encoding='utf-8') as f:
                        for line_num, line in enumerate(f, 1):
                            if pattern.search(line):
                                print(f"[!] Potential key found in {file_path} (Line {line_num})")
                except Exception as e:
                    pass

if __name__ == "__main__":
    scan_for_api_keys("./your-code-directory")

2. Hunting for Abnormal API Usage with KQL

If you are ingesting Google Cloud logs into Microsoft Sentinel, you can hunt for suspicious usage patterns indicative of API key abuse, such as a sudden spike in requests from an unusual ASN or location.

let GoogleCloudLogs = GoogleCloudActivityLogs;
// Look for successful API calls to generative language endpoints
GoogleCloudLogs
| where ProtoPayload.serviceName == "generativelanguage.googleapis.com"
| where ProtoPayload.methodName contains "generate"
| extend KeyName = tostring(ProtoPayload.authenticationInfo.principalSubject)
| project Timestamp, SrcIpAddr, KeyName, ProtoPayload.methodName, ProtoPayload.resourceName
| summarize Count=count() by KeyName, SrcIpAddr, bin(Timestamp, 1h)
| where Count > 100 // Threshold for anomalous volume
| order by Count desc

3. Auditing Public Repositories with Bash

For a quick check of your public repositories (if cloned locally), use grep to hunt for the specific prefix.

grep -r "AIza[A-Za-z0-9_-]\{35\}" . --include="*.js" --include="*." --include="*.html"

Mitigation Strategies

To secure your Google Cloud environment against this threat, immediate and long-term actions are required.

Immediate Actions

1. Key Rotation: Assume any key found in client-side code is compromised. Revoke (delete) the exposed key immediately in the Google Cloud Console (APIs & Services > Credentials).
2. Audit IAM Permissions: Review the IAM roles associated with the service accounts linked to these API keys. Ensure they follow the principle of least privilege.

Long-Term Configuration

1. Implement Application Restrictions: In the Google Cloud Console, edit your API keys and add "Application restrictions.