Full Report
A recent incident revealed attacker activity stemming from a leaked long-term AWS access key (AKIA*) belonging to a user in an organization’s AWS management account. Over a 150-minute period, five IP addresses abused the credentials to perform both well-known and novel cloud a...
Analysis Summary
# Incident Report: Exploitation of Leaked AWS Access Key Leading to Persistence-as-a-Service
## Executive Summary
An incident was identified where a publicly exposed long-term AWS access key (AKIA*) from an organization’s management account was leveraged by five distinct IP addresses over 150 minutes. Attackers used these credentials to perform novel techniques, including creating a "persistence-as-a-service" infrastructure via AWS Lambda and API Gateway, ultimately establishing long-term persistence even after the initial key was revoked.
## Incident Details
- Discovery Date: Not explicitly stated, but activity was observed over a 150-minute period.
- Incident Date: Activity spanned a 150-minute period (specific start time not provided).
- Affected Organization: Undisclosed Healthcare Organization (Inferred from associated links/context, but not explicitly stated in text provided).
- Sector: Undisclosed (Assumed Tech/Cloud-centric given AWS context).
- Geography: Undisclosed (AWS Environment).
## Timeline of Events
### Initial Access
- Date/Time: During a 150-minute window.
- Vector: Leaked long-term AWS access key (AKIA*).
- Details: Credentials belonged to a user in the organization’s AWS management account.
### Lateral Movement
- Details: Attackers performed SES enumeration, created new IAM users with admin permissions, and generated temporary STS credentials. They utilized AWS services (Lambda, API Gateway, Identity Center) to move beyond the compromised key.
### Data Exfiltration/Impact
- Details: While direct impact data is unknown ("Impact Unknown"), the establishment of persistence mechanisms suggests objectives beyond simple one-time data access, including long-term control.
### Detection & Response
- Detection: Detection occurred after the activity started (implied by the reporting of the 150-minute period).
- Response Actions: The primary immediate response was key revocation, which was partially bypassed by the established persistence mechanisms.
## Attack Methodology
- Initial Access: Abusing a leaked, long-term AWS access key (AKIA*).
- Persistence: Established "persistence-as-a-service" infrastructure using an AWS Lambda function triggered by an API Gateway to dynamically generate new IAM users on demand. Modified AWS Identity Center (SSO) configurations to extend session lifetimes and bypass MFA.
- Privilege Escalation: Created new IAM users assigned administrative privileges.
- Defense Evasion: Disabled integrations with several organization-level services using `DisableAWSServiceAccess` to weaken monitoring and policy enforcement.
- Credential Access: N/A (Credentials were leaked, not actively stolen; however, new admin users were created).
- Discovery: SES enumeration was observed.
- Lateral Movement: Used compromised credentials to deploy new infrastructure (Lambda/API Gateway) for persistent access.
- Collection: Not explicitly detailed, but implied during the 150-minute window.
- Exfiltration: Not explicitly detailed.
- Impact: Establishment of long-term, resilient persistence mechanisms across multiple AWS components.
## Impact Assessment
- Financial: Unknown.
- Data Breach: Unknown volume/type, but high potential exists given admin access was established.
- Operational: Moderate potential disruption due to service integrations being disabled (`DisableAWSServiceAccess`).
- Reputational: Unknown.
## Indicators of Compromise
- Network Indicators: Five distinct IP addresses (Specific IPs not provided in text).
- File Indicators: N/A.
- Behavioral Indicators: SES enumeration, IAM user creation with admin scope, STS credential generation, use of `DisableAWSServiceAccess`.
## Response Actions
- Containment: Revocation of the original compromised access key (though persistence mechanisms survived revocation).
- Eradication: Further steps beyond key revocation would be necessary to dismantle the Lambda/API Gateway persistence mechanism and re-enable disabled organizational services.
- Recovery: Re-enabling disabled AWS organization services and auditing all newly created IAM users/roles.
## Lessons Learned
- Long-term access keys should be treated as highly sensitive, requiring robust protection mechanisms beyond standard rotation policies.
- The incident demonstrated an advanced attacker capability in leveraging cloud-native services (Lambda, API Gateway, SSO) to build resilient, reusable persistence mechanisms ("persistence-as-a-service") that survive the revocation of the initial ingress credential.
- Attackers successfully bypassed standard MFA protection via Identity Center configuration modification.
## Recommendations
- Implement stringent policies restricting the use of long-term access keys, favoring session-based credentials (e.g., IAM roles with STS assumed roles).
- Enable and enforce MFA across all management and administrative accounts, specifically reviewing AWS Identity Center configurations for potential bypass vectors.
- Deploy continuous monitoring focused on unusual AWS service modifications, especially API calls related to Lambda deployment, API Gateway creation, and the use of `DisableAWSServiceAccess`.
- Review and restrict permissions related to modifying organization-level service integrations.