Runbook 03 — Enterprise AWS Incident Response & Attack Path Investigation

Runbook Information

Item	Value
Module	Module 02 — AWS Cloud Penetration Testing
Runbook	03 — Enterprise AWS Incident Response & Attack Path Investigation
Audience	SOC Analysts, Cloud Incident Responders, DFIR Teams, Cloud Security Engineers
Assessment Type	Enterprise Incident Response & Cloud Forensics
Estimated Duration	4–24 Hours
Frameworks	NIST SP 800-61, MITRE ATT&CK, AWS Security Incident Response Guide, CIS AWS Foundations Benchmark

Objective

This runbook provides a structured methodology for investigating security incidents in AWS enterprise environments.

It enables responders to:

Detect cloud attacks
Contain incidents safely
Preserve forensic evidence
Identify attack paths
Determine root cause
Eradicate threats
Recover securely
Produce executive incident reports

Enterprise Scenario

CloudNova Technologies has been contacted by FinSecure Bank Ltd after their Security Operations Centre (SOC) detected unusual AWS activity.

Security alerts include:

New IAM Administrator created
CloudTrail disabled
Suspicious AssumeRole activity
New EC2 instance launched
Secrets Manager accessed
Large Amazon S3 downloads
GuardDuty High Severity Findings

Management requires an immediate investigation to determine:

What happened?
How the attacker gained access?
What resources were affected?
Whether customer data was compromised.
How future attacks can be prevented.

Incident Response Lifecycle

Preparation

↓

Detection

↓

Identification

↓

Containment

↓

Evidence Collection

↓

Attack Path Analysis

↓

Root Cause Analysis

↓

Eradication

↓

Recovery

↓

Lessons Learned

↓

Executive Reporting

Phase 1 — Preparation

Objectives

Verify incident readiness.

Review:

AWS Accounts
Emergency Contacts
IAM Break Glass Accounts
Incident Response Plan
CloudTrail Logging
Security Hub
GuardDuty
AWS Config
Security Lake

Deliverables

Incident Activation Record
Initial Timeline

Phase 2 — Detection

Determine how the incident was discovered.

Possible detection sources:

GuardDuty
Security Hub
CloudTrail
CloudWatch Alarms
AWS Config
SIEM
Amazon Detective
Security Lake
User Reports

Document:

Detection Time
Alert Source
Severity
Initial Scope

Deliverables

Incident Detection Report

Phase 3 — Initial Identification

Determine:

Compromised Account
AWS Region
Services Impacted
IAM Identities
Public Exposure
Business Criticality

Questions

Which AWS account was affected?
Is the incident ongoing?
Is production impacted?

Deliverables

Incident Scope Document

Phase 4 — Evidence Collection

Collect evidence before making changes.

Sources include:

CloudTrail Logs
CloudWatch Logs
GuardDuty Findings
Security Hub Findings
AWS Config Timeline
EC2 Metadata
VPC Flow Logs
Kubernetes Audit Logs
Lambda Logs
S3 Access Logs

Evidence should remain read-only wherever possible.

Example Commands

CloudTrail

aws cloudtrail lookup-events

GuardDuty

aws guardduty list-findings

Security Hub

aws securityhub get-findings

AWS Config

aws configservice get-resource-config-history

CloudWatch Logs

aws logs describe-log-groups

Deliverables

Evidence Inventory
Timeline of Events

Phase 5 — IAM Investigation

Review:

New Users
New Roles
New Policies
Access Keys
AssumeRole Activity
PassRole Activity
Trust Policy Changes

Commands

aws iam list-users

aws iam list-roles

aws iam get-role

Questions

Were administrator accounts created?
Were trust relationships modified?
Were credentials exposed?

Deliverables

IAM Investigation Report

Phase 6 — EC2 Investigation

Review:

New EC2 Instances
Security Groups
IMDS
User Data
IAM Roles
EBS Snapshots
Systems Manager

Determine:

Was malware deployed?
Was an attacker operating from EC2?

Deliverables

EC2 Investigation Report

Phase 7 — Amazon S3 Investigation

Review:

Public Buckets
Bucket Policies
Object Downloads
Cross-Account Access
Sensitive Data Access
Versioning
Encryption

Questions

Was customer data accessed?
Were backups downloaded?
Was data modified?

Deliverables

Amazon S3 Investigation Report

Phase 8 — Amazon EKS Investigation

Review:

Kubernetes Audit Logs
RBAC Changes
Service Accounts
IRSA
Secrets
Privileged Pods
New Deployments
CronJobs

Commands

kubectl get pods -A

kubectl get clusterrolebindings

kubectl get events -A

Determine:

Was a container compromised?
Was Kubernetes used for lateral movement?

Deliverables

Kubernetes Investigation Report

Phase 9 — Lambda Investigation

Review:

Execution Roles
Environment Variables
Deployment History
Event Sources
CloudWatch Logs

Determine:

Were functions modified?
Were malicious Lambda functions deployed?

Deliverables

Serverless Investigation Report

Phase 10 — Attack Path Analysis

Build the complete attacker timeline.

Example

Phishing

↓

Developer Credentials

↓

IAM User

↓

PassRole

↓

Administrator Role

↓

EC2 Launch

↓

Secrets Manager

↓

Amazon S3

↓

Customer Records

Identify:

Entry Point
Escalation
Persistence
Lateral Movement
Data Access

Deliverables

Enterprise Attack Path Diagram

Phase 11 — Root Cause Analysis

Determine:

Initial Weakness
Failed Security Control
Missing Detection
Business Impact

Example

Finding	Root Cause
Public EC2	Weak Security Group
IAM Escalation	Excessive PassRole
S3 Exposure	Public Bucket Policy
Kubernetes Compromise	Privileged Pod

Deliverables

Root Cause Analysis Report

Phase 12 — Containment

Contain the incident safely.

Examples:

Disable compromised IAM users
Rotate credentials
Stop malicious EC2 instances
Remove public Security Groups
Disable compromised Lambda functions
Block malicious IPs
Isolate Kubernetes Nodes
Suspend cross-account trust

Containment should minimize business disruption while preventing further attacker activity.

Deliverables

Containment Actions Log

Phase 13 — Eradication

Remove attacker access.

Examples:

Delete unauthorized IAM users
Remove malicious access keys
Delete rogue Lambda functions
Remove unauthorized Kubernetes objects
Delete malicious EventBridge rules
Patch vulnerable workloads
Remove persistence mechanisms

Deliverables

Eradication Report

Phase 14 — Recovery

Safely restore services.

Review:

IAM Permissions
CloudTrail
GuardDuty
Security Hub
Workload Integrity
Application Testing
Monitoring

Validate that:

Services function normally.
No attacker access remains.
Security controls are restored.

Deliverables

Recovery Validation Report

Phase 15 — Lessons Learned

Conduct a post-incident review.

Questions

How did the attacker gain access?
What worked well?
Which controls failed?
How can detection improve?
Which processes should change?

Deliverables

Lessons Learned Document
Improvement Plan

Executive Dashboard

Metric	Result
Incident Severity
Detection Source
AWS Accounts Impacted
IAM Users Compromised
EC2 Instances Affected
S3 Buckets Accessed
EKS Clusters Impacted
Customer Data Exposed
Time to Detect
Time to Contain
Time to Recover

Incident Timeline Template

Time	Event
09:05	GuardDuty generated High Severity finding
09:08	Suspicious AssumeRole detected
09:12	New Administrator IAM user created
09:20	Large S3 download initiated
09:30	Incident declared
09:42	Compromised account disabled
10:15	Recovery activities started

Investigation Checklist

Investigation Area	Status
CloudTrail Reviewed	☐
GuardDuty Reviewed	☐
Security Hub Reviewed	☐
AWS Config Reviewed	☐
IAM Investigated	☐
EC2 Investigated	☐
Amazon S3 Reviewed	☐
Amazon EKS Reviewed	☐
Lambda Reviewed	☐
VPC Flow Logs Reviewed	☐
Attack Path Built	☐
Root Cause Identified	☐
Containment Completed	☐
Recovery Validated	☐
Executive Report Delivered	☐

Deliverables

At the completion of the investigation, provide:

Incident Summary
Incident Timeline
Evidence Inventory
IAM Investigation Report
EC2 Investigation Report
Amazon S3 Investigation Report
Amazon EKS Investigation Report
Lambda Investigation Report
Attack Path Analysis
Root Cause Analysis
Containment Report
Eradication Report
Recovery Validation Report
Executive Dashboard
Executive Incident Report
Lessons Learned Report
Security Improvement Roadmap

Success Criteria

The incident response engagement is considered successful when:

The incident is fully contained.
All evidence has been preserved.
The attack path has been reconstructed.
Root cause has been identified.
Persistence mechanisms have been removed.
Business services have been safely restored.
Executive stakeholders understand the incident, business impact and remediation priorities.
Preventive and detective controls have been strengthened to reduce the likelihood of recurrence.

Key Takeaways

Enterprise AWS incident response requires coordinated investigation across IAM, networking, compute, storage, Kubernetes and serverless services.
CloudTrail, GuardDuty, Security Hub, AWS Config and Security Lake provide the foundation for cloud forensic investigations.
Attack path reconstruction helps explain how individual security weaknesses led to business impact.
Effective incident response balances rapid containment with careful evidence preservation and thorough root cause analysis.
Mature organizations continuously improve their cloud security posture through post-incident reviews, strengthened monitoring and recurring security assessments.