Responders Traced a Hybrid Cloud Attack from AWS to a Phishing-Infected Home Computer
Summary
A case study details how investigators traced repeated AWS compromises to a phishing-infected home computer, using cloud and on-premises logs, forensics, and threat intelligence. The extent of earlier data access remains unknown.
Key points
- Investigators first noticed missing OS logs on production EC2 instances and found attacker-installed reverse shells in forensic images.
- CloudTrail records linked an IAM user’s GetPasswordData operations to the compromised instances; attackers used the resulting administrator access to install shells and delete logs.
- The attackers accessed S3 buckets and sensitive RDS databases, but tampered audit policies and limited log retention left the initial scope of data access and exfiltration unknown.
- After credentials were rotated and instances recovered, attackers reused the privileged IAM user to exfiltrate data from an RDS database and alter its audit policies.
- VPC Flow Logs and public threat intelligence helped link attacker command-and-control infrastructure to a compromised on-premises jump server.
- Further forensics connected a later reverse shell to an employee’s RDP session and revealed malware on the employee’s personal computer, along with the phishing messages that initiated the attack.
- The case study highlights how combining cloud and on-premises logs, endpoint forensics, and threat intelligence helped responders uncover the attack path.
Article Details
- Attack Vectors
- Social-engineering and phishing messages initiated the attack, and a malicious payload ran on an employee’s personal computer.
- Attackers compromised an on-premises jump server and installed reverse shells that communicated with attacker C2 infrastructure.
- Attackers used a compromised privileged AWS IAM user to access EC2 instances, S3 buckets, and sensitive RDS databases.
- Attackers obtained local administrator passwords through the AWS GetPasswordData operation, enabling access to targeted EC2 instances.
- A compromised AWS credential was reused after rotation, with attackers regaining access through the compromised jump server.
- Defensive Notes
- Rotate compromised privileged credentials and quarantine affected EC2 instances; recover instances from verified secure backups.
- Restore tampered audit and logging policies, enable additional telemetry such as VPC Flow Logs, and add SIEM detection rules.
- Investigate beyond the cloud environment, including jump servers, employee endpoints, and connections to identified C2 IP addresses.
- Use retained internal logs and public threat intelligence to correlate infrastructure and identify related attacker systems.
- Review access to sensitive databases and storage, and account for log-retention gaps when assessing incident scope and possible data exfiltration.
MITRE ATT&CK
Vendors
Amazon Web Servicesfirst began investigating the attack when a cloud engineer working on an EC2 instance in the production AWS environment noticed that local OS logs were missing from the instance. In attempting to figure out whatCitrixwas able to correlate the creation of the new reverse shell to a dev-ops employee’s RDP session from a Citrix VDI. Unfortunately, the VDI is ephemeral by design and was long-gone by the time of the investigation.
Products
AWS CloudTrailthe incident. By cross-referencing the creation timestamps of identified attacker reverse shells and AWS CloudTrail logs, of which only a portion was retained in the organizational SIEM for the relevant timeframe ofAWS Secrets ManagerAttempts to investigate access to the AWS Secrets Manager secret which stored the new credential revealed no unusual access – the key was only accessed from known IP addresses by users belonging to dev-ops and cloudCitrix VDIwas able to correlate the creation of the new reverse shell to a dev-ops employee’s RDP session from a Citrix VDI. Unfortunately, the VDI is ephemeral by design and was long-gone by the time of the investigation.EC2organization’s security team first began investigating the attack when a cloud engineer working on an EC2 instance in the production AWS environment noticed that local OS logs were missing from the instance. InRDSvisibility was not possible due to log retention limitations, access to S3 buckets and highly sensitive RDS databases was identified. The full scope of this access and exactly what data was exfiltrated remainsS3IAM user’s activities. While full visibility was not possible due to log retention limitations, access to S3 buckets and highly sensitive RDS databases was identified. The full scope of this access and exactly whatVPC Flow LogsIn addition, tampered logging policies were restored, additional logging including VPC Flow Logs were configured, and specific detection rules were added to the SIEM. As weeks went by since these initial eradication and