Mass Exposure of Active AWS Access Keys

Technical Analysis

The exposure involves long-lived static AWS IAM access keys (Access Key ID + Secret Access Key pairs) discovered in publicly accessible sources such as GitHub repositories, container images, CI/CD logs, or misconfigured storage buckets. Because AWS does not automatically expire or invalidate leaked keys, attackers scanning public code repositories can harvest and weaponize these credentials to assume full account privileges, including S3 data exfiltration, EC2 instance provisioning for cryptomining, and IAM privilege escalation. The scale (9,300+ valid keys spanning four years) indicates systemic failures in secrets management, credential rotation, and secret-scanning enforcement across many organizations. Many AI agent frameworks and RAG pipelines rely on AWS credentials embedded in environment variables, configuration files, or automation scripts to access S3 buckets, Bedrock, SageMaker, or Lambda functions—if such keys leak via the same misconfigurations (e.g., committed to public repos by agent developers or CI pipelines), attackers could hijack agent infrastructure, exfiltrate proprietary data/model artifacts, or run unauthorized inference workloads at the victim's expense.

Affected Systems

AWS accounts and IAM users with static access keys; organizations using public or improperly secured GitHub/GitLab repositories, CI/CD pipelines, container images, or logging systems that may embed AWS credentials; any AWS-integrated service including S3, EC2, Lambda, Bedrock, and SageMaker

Indicators of Compromise

• N/A - no specific hashes, IPs, or domains provided; indicators are exposed AWS Access Key IDs (format: AKIA[0-9A-Z]{16}) found in public code repositories, logs, and configuration files

Remediation Steps

1. 1

   Rotate and Revoke Exposed Keys

   Immediately identify and deactivate/rotate any AWS access keys that may have been committed to public repositories, shared logs, or container images.

2. 2

   Enable AWS Secrets Manager / Parameter Store

   Migrate away from static, long-lived IAM keys to short-lived credentials via IAM roles, AWS STS, or Secrets Manager for both applications and AI agent workflows.

3. 3

   Implement Secret Scanning

   Deploy automated secret-scanning tools (e.g., GitHub secret scanning, TruffleHog, git-secrets) across all repositories and CI/CD pipelines, including those used for agent/RAG deployment scripts.

4. 4

   Enforce Least Privilege IAM Policies

   Audit IAM permissions attached to exposed keys and restrict scope; use resource-based policies and service control policies (SCPs) to limit blast radius.

5. 5

   Enable CloudTrail Monitoring and Alerts

   Set up anomaly detection for unusual API calls, new resource creation, or access from unexpected geographies tied to IAM key usage.

6. 6

   Audit Agent and Automation Configurations

   Review AI agent, RAG pipeline, and automation tool configurations for hardcoded AWS credentials and replace with vault-based or role-based authentication.