Full Report
Wiz Threat Research discovered a malicious campaign where attackers are using leaked or stolen cloud access keys to access cloud environments and deploy ECS clusters. The attacker was observed abusing accidentally exposed AWS access keys and trying to gain a permanent foothold...
Analysis Summary
# Incident Report: Bapak Campaign Leveraging Stolen Cloud Keys
## Executive Summary
Wiz Threat Research uncovered a malicious campaign dubbed "Bapak" where threat actors leveraged leaked or stolen AWS access keys to gain unauthorized access to cloud environments. The primary impact involved resource hijacking, specifically deploying numerous Amazon ECS clusters, likely for illicit activities such as crypto-mining. Response efforts involved analyzing the deployment patterns and understanding the source of the exposed credentials.
## Incident Details
- Discovery Date: January 15, 2025 (Date of Public Disclosure/Research Publication)
- Incident Date: Ongoing campaign prior to January 15, 2025
- Affected Organization: Multiple organizations with publicly exposed AWS access keys.
- Sector: Undisclosed (Broad, targeting cloud environments)
- Geography: Inferred link to Indonesia based on object naming conventions.
## Timeline of Events
### Initial Access
- Date/Time: Ongoing before Jan 15, 2025
- Vector: Abuse of leaked or stolen cloud access keys (AWS API Keys).
- Details: Keys were commonly exposed via client-side scripts, accessible `.env` files, or uploads to public code repositories.
### Lateral Movement
- Date/Time: Following initial access
- Vector: Valid Credential Abuse
- Details: Attackers used the compromised keys to make API calls, starting with validation calls like `GetCallerIdentity`. They then attempted to establish persistence by creating new users and importing their own SSH keys.
### Data Exfiltration/Impact
- Date/Time: Following persistence establishment
- Vector: Resource Hijacking and Deployment
- Details: Attackers deployed multiple ECS clusters, typically named "bapak1" or "entot1," signaling intent for resource utilization (e.g., crypto-mining or network scanning).
### Detection & Response
- Date/Time: Prior to Jan 15, 2025
- Vector: Cloud Threat Research Analysis (Wiz)
- Details: The campaign was discovered through proactive research identifying the characteristic deployment of ECS clusters with specific naming conventions.
## Attack Methodology
- Initial Access: Abuse of valid, unprotected AWS access keys found in public repositories.
- Persistence: Attempted creation of new IAM users and importing the actor's own SSH keys.
- Privilege Escalation: Not explicitly detailed, but maintaining access via long-lived keys implies persistent authorization.
- Defense Evasion: Minimal detail provided, relying on the inherent trust associated with valid but exposed credentials.
- Credential Access: Credential theft focused on locating and stealing existing, accidentally exposed API keys.
- Discovery: Initial API calls following access likely included standard cloud enumeration techniques (e.g., `GetCallerIdentity`).
- Lateral Movement: Movement occurred within the compromised AWS environment via authorized API calls.
- Collection: Not the primary focus; focus was on resource maximization.
- Exfiltration: No evidence of traditional data exfiltration noted; impact was focused on resource hijacking.
- Impact: Deployment of ECS clusters for unauthorized computational use (crypto-mining/scanning).
## Impact Assessment
- Financial: Potential hidden costs associated with unauthorized cloud resource consumption (crypto-mining).
- Data Breach: No specific customer/sensitive data breach details provided; impact centered on infrastructure compromise.
- Operational: Potential performance degradation or security posture issues due to rogue infrastructure deployment.
- Reputational: Limited public reputational damage based on research publication premise, but internal impact likely significant for affected organizations.
## Indicators of Compromise
- Behavioral indicators: Repeated API calls validating credentials, followed quickly by `CreateCluster` API calls for ECS.
- Naming Indicators: Newly created ECS clusters consistently named "bapak1" or "entot1".
## Response Actions
- Containment measures: (Inferred) Disabling or rotating the compromised access keys.
- Eradication steps: (Inferred) Deleting unauthorized compute resources (ECS clusters) and newly created IAM users/SSH keys.
- Recovery actions: (Inferred) Reviewing access key exposure posture.
## Lessons Learned
- Leaked credentials remain a primary, low-effort entry vector into cloud environments.
- Accidental exposure of access keys via code repositories provides attackers with immediate, high-privilege access.
- Attackers quickly pivot from simple access to establishing persistence (new users/keys) and deploying infrastructure for resource monetization.
## Recommendations
- Implement strict policies preventing AWS access keys, secrets, and `.env` files from being committed to any public or internal source code repositories.
- Utilize tools for continuous monitoring of public code repositories for accidental key leakage.
- Implement strong IAM policies, favoring Principle of Least Privilege, and enforce MFA for all users, even service accounts where applicable.
- Configure granular alerts for suspicious activity such as creating new users or deploying primary compute resources shortly after access validation.