Security Incident

A Security Incident is any event that actually or potentially jeopardizes the confidentiality, integrity, or availability of your information systems or data.

Common AWS Security Incidents

• Credential Compromise: leaked access keys, stolen session tokens
• Data Exposure: public S3 buckets, misconfigured security groups exposing databases
• Unauthorized Access: root account usage, privilege escalation, lateral movement
• Malware/Cryptomining: compromised EC2 instances running unauthorized workloads
• DDoS Attacks: volumetric or application-layer attacks on public endpoints
• Supply Chain: compromised dependencies, malicious Lambda layers, container image tampering

AWS Resources for Incident Response

• AWS Security Incident Response: managed service (launched re:Invent 2024) with triage and investigation support
• AWS Abuse Reports: report compromise to AWS via the abuse form
• GuardDuty: automated threat detection and initial triage
• Detective: investigation and root cause analysis
• CloudTrail: forensic evidence of API activity

How It Goes Wrong in Practice

The archetypal AWS incident starts with an access key committed to a public Git repository. Automated scanners, both benevolent and hostile, watch public repositories continuously, so exposure to abuse is measured in minutes, not days. The typical attacker playbook is depressingly consistent: quiet reconnaissance calls to see what the key can do, then either resource abuse (large EC2 instances for cryptomining, often in regions the victim never uses) or persistence (new IAM users, new access keys, modified trust policies) followed by data access. The first symptom is frequently the bill.

The second way incidents go wrong is the response itself destroying the investigation. A well-meaning engineer terminates the compromised instance, which discards memory and, with it, most of the volatile evidence; another deletes the attacker's IAM user, erasing the easiest pivot for understanding what that principal touched. The disciplined sequence is contain without destroying: isolate the instance with a restrictive security group, snapshot volumes before any cleanup, deactivate rather than delete compromised credentials, and only then eradicate. Equally damaging is tunnel vision on the initial finding: responders disable the leaked key and close the ticket, missing the second access key the attacker created on day one specifically to survive that response. Every credential-compromise response must include a sweep for attacker-created identities, keys, roles, and trust policy changes.

A Practical Check

When a specific access key is suspected, CloudTrail event history lets you reconstruct what it did without any prior setup, since event history is enabled by default and searchable for the past 90 days of management events per region, at no charge for viewing:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE

The same command pivots on other attribute keys as the investigation widens: AttributeKey=Username to follow a principal, AttributeKey=EventName to find every occurrence of a call like ConsoleLogin, or AttributeKey=EventSource to isolate activity against one service. Note the documented limitations: one attribute filter at a time, single region per query, management events only. Run it in every region, because attackers count on you checking only your home region. For anything older than 90 days or for data events, you need your own trail or a CloudTrail Lake event data store, which is why those belong in the baseline before the incident, not after.

Frequently Asked Questions

What is the difference between a security event and a security incident? An event is any observable occurrence: a login, an API call, a GuardDuty finding. An incident is an event, or a pattern of them, that actually or potentially harms confidentiality, integrity, or availability. The distinction matters operationally: events get filtered and triaged in volume, incidents trigger a declared response with roles, timelines, and a post-incident review.

How far back can I investigate if I prepared nothing? CloudTrail event history gives you 90 days of management events per region by default, which is a genuine safety net. It does not include data events such as S3 object reads, so questions like "which objects did the attacker download" are unanswerable without a trail or event data store configured beforehand. The honest rule: your investigative reach is decided before the incident.

Should I involve AWS during an incident? Yes, through the channels that fit the situation: AWS Support for operational help, the abuse form when AWS resources are attacking you or yours are being abused, and the AWS Security Incident Response service if you subscribe to it for triage and investigation support. AWS can act on its side of the shared responsibility model, but the investigation of your configurations, identities, and data remains yours to run.