How to Investigate a Compromised AWS Account: A Practical Guide
Cloud security incidents can begin with something as small as an unusual API call, a new access key, or unexpected network activity. This practical guide explains how to investigate a potentially compromised AWS account using IAM, CloudTrail, GuardDuty, VPC Flow Logs, and Security Hub—from detecting suspicious activity and building an incident timeline to containment, remediation, and preventing future incidents.
Cloud security incidents rarely begin with someone “hacking the server.” In many AWS environments, the first sign of a compromise can be something much smaller: an unusual API call, a login from an unexpected location, a new IAM access key, or a resource that suddenly appears in an account.
Understanding how to investigate these events is an important skill for anyone working with AWS.
This article walks through a practical approach to investigating a potentially compromised AWS account using native AWS security services.
1. Start With the Identity
When suspicious activity is detected, the first question should be:
Who performed the action?
AWS Identity and Access Management (IAM) controls access to AWS resources. Users, roles, and applications can perform actions through AWS APIs, and those actions can be recorded by AWS CloudTrail.
For example, suppose an administrator notices that an S3 bucket policy was changed unexpectedly.
Instead of immediately deleting resources, start by identifying the API activity associated with the change.
CloudTrail can provide information such as:
- The API action that was performed
- The time of the action
- The AWS region
- The identity that made the request
- The source IP address
- The user agent
- Whether temporary credentials or long-term credentials were used
This information creates the initial timeline of the incident.
2. Build a Timeline
Incident investigation becomes much easier when events are arranged chronologically.
For example:
10:02 AM — Successful authentication10:05 AM — New access key created10:07 AM — S3 bucket policy modified10:11 AM — EC2 instance launched10:15 AM — Large number of API requests
Individually, some of these events may not appear dangerous.
Together, however, they can reveal a pattern.
A timeline helps investigators answer questions such as:
- When did the suspicious activity begin?
- Which identity was involved?
- What happened immediately before the first suspicious action?
- Which resources were affected?
- Is the activity still happening?
3. Check GuardDuty Findings
Amazon GuardDuty continuously analyzes AWS data sources for indicators of potentially malicious activity.
For example, GuardDuty can identify suspicious behavior involving:
- Compromised credentials
- Unusual API activity
- Malicious IP addresses
- Suspicious network communication
- Potentially compromised EC2 instances
A GuardDuty finding should not automatically be treated as proof that an account has been compromised.
Instead, use it as an investigation lead.
For example:
GuardDuty Finding ↓Identify affected resource ↓Check CloudTrail ↓Identify IAM identity ↓Review activity ↓Determine scope
This combination is much more useful than looking at a security alert in isolation.
4. Investigate IAM Changes
Attackers who obtain valid credentials may attempt to increase their access.
Therefore, investigators should check for unexpected changes to:
- IAM users
- IAM roles
- Policies
- Access keys
- MFA settings
- Trust relationships
- Permission boundaries
One particularly important area is newly created access keys.
If an access key appears shortly before suspicious activity, investigate:
- Who created the key?
- Which identity owns it?
- Where was it used?
- What API calls were made?
- What resources were accessed?
The goal isn't simply to find the compromised credential. The goal is to understand what the credential was used to do.
5. Look at Network Activity
If an EC2 instance or another workload may be involved, investigate its network behavior.
VPC Flow Logs can provide information about network traffic associated with interfaces in your VPC.
Useful questions include:
- Is the instance communicating with an unexpected destination?
- Did outbound traffic suddenly increase?
- Are unusual ports being accessed?
- Did communication begin around the same time as the suspicious API activity?
Network logs become much more valuable when correlated with CloudTrail and GuardDuty findings.
6. Contain the Incident
Once there is reasonable evidence of compromise, the next objective is containment.
The exact response depends on the incident.
For compromised credentials, possible actions include:
- Disable or rotate affected credentials
- Review and reduce excessive permissions
- Revoke unnecessary sessions
- Investigate where the credentials were used
For a potentially compromised workload, containment may involve:
- Isolating the workload
- Restricting network access
- Preserving relevant evidence
- Removing unauthorized resources
A common mistake is to immediately delete everything suspicious.
That may stop the activity, but it can also destroy valuable evidence.
Before making destructive changes, consider what information is needed to understand the incident.
7. Use Security Hub for Centralized Findings
AWS Security Hub can aggregate security findings from AWS security services and supported third-party sources.
This can provide a more centralized view of security issues.
A simplified architecture looks like this:
AWS Environment │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ CloudTrail GuardDuty VPC Flow Logs │ │ │ └──────────────┼──────────────┘ ↓ Security Hub ↓ Investigation ↓ Response
The important concept is correlation.
One service may tell you that something unusual happened.
Another may tell you who performed the action.
Another may provide network evidence.
Together, these sources can produce a much clearer picture.
8. Don't Forget the Root Cause
Stopping the immediate activity isn't the end of the investigation.
After containment, ask:
How did this happen?
Possible causes include:
- Exposed access keys
- Excessive IAM permissions
- Missing MFA
- Poor secrets management
- Publicly exposed resources
- Vulnerable applications
- Misconfigured security controls
- Credentials stored in source code
Fixing the root cause is what prevents the same incident from happening again.
For example, if an access key was accidentally committed to a public repository, simply rotating that key isn't enough. The organization should also review how secrets are stored and whether similar credentials have been exposed elsewhere.
9. A Simple SOC Investigation Workflow
The overall process can be remembered as:
DETECT ↓IDENTIFY ↓TIMELINE ↓INVESTIGATE ↓CONTAIN ↓REMEDIATE ↓DOCUMENT ↓IMPROVE
Each stage has a different purpose.
Detect the suspicious activity.
Identify the affected identity and resources.
Timeline the events.
Investigate the evidence.
Contain the active threat.
Remediate the underlying problem.
Document what happened and what actions were taken.
Improve the environment so the same issue is less likely to happen again.
Final Thought
AWS provides many individual security services, but effective cloud security isn't about knowing the name of every service.
It's about knowing how the evidence connects.
CloudTrail can show what happened. GuardDuty can identify suspicious behavior. IAM can explain the permissions behind an action. VPC Flow Logs can provide network context. Security Hub can help centralize findings.
The real skill is turning those pieces of information into an investigation.
For anyone learning AWS security, try building this workflow in a controlled environment rather than only reading about it. Create a test account, generate legitimate activity, examine the logs, and learn what normal behavior looks like before investigating abnormal behavior.
That is where AWS security starts becoming a practical skill rather than just a list of services.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article