Runbook 02 Enterprise SOC Security Monitoring

Module: 13 – Security Operations Centre (SOC)

Enterprise Lab: 02

Estimated Time: 6–8 Hours

Difficulty: ⭐⭐⭐⭐⭐

Estimated Cost: This is primarily an investigation and assessment runbook. Existing AWS logging, Detective, Security Hub, GuardDuty, CloudWatch, Security Lake, Athena, and data-transfer usage may incur charges.

🎯 Objective

As a Tier-2 Cloud SOC Analyst at CloudNova Technologies, you have been assigned to investigate a suspected multi-stage AWS security incident affecting a production account.

Your objective is to validate the initial alert, correlate evidence from multiple AWS security services, reconstruct the attacker’s activity, determine the incident scope, identify affected identities and resources, preserve investigation evidence, and recommend containment, eradication, and recovery actions.

By completing this runbook, you will learn how to:

Review and validate incoming SOC alerts
Classify incident severity and priority
Review Amazon GuardDuty findings
Analyse AWS Security Hub findings
Investigate entities using Amazon Detective
Search AWS CloudTrail activity
Analyse IAM identity activity
Review EC2 and network activity
Analyse VPC Flow Logs
Review Amazon Inspector findings
Review AWS Config changes
Correlate evidence across AWS services
Build an incident timeline
Determine the initial access method
Identify privilege escalation and persistence
Assess the blast radius
Preserve investigation evidence
Recommend containment actions
Recommend eradication and recovery actions
Produce technical and executive incident reports

🏢 Business Scenario

CloudNova Technologies operates a customer-facing application in its production AWS account.

At 02:15 UTC, the Security Operations Centre receives a high-severity GuardDuty finding involving an IAM identity. Within the next 30 minutes, multiple additional security events are detected.

The alerts indicate:

An IAM user logged in from an unusual geographic location
MFA was not used
A new access key was created
An administrative policy was attached to the identity
A production security group was opened to the Internet
An EC2 instance communicated with a suspicious external IP address
Sensitive S3 objects were downloaded
CloudTrail configuration was modified
High-severity GuardDuty and Security Hub findings were generated

The SOC Manager has escalated the case to Tier 2 for investigation.

Your responsibility is to determine:

Whether the activity is malicious
How the attacker gained access
Which resources were affected
Whether data was accessed or exfiltrated
Whether persistence was established
Whether additional AWS accounts are affected
What actions must be taken immediately

📋 Prerequisites

Complete:

Enterprise Runbook 01 — Build an Enterprise AWS Security Operations Centre

Required access:

AWS Security Account
Production AWS Account
Log Archive Account
GuardDuty
Security Hub
Amazon Detective
AWS CloudTrail
CloudWatch Logs
VPC Flow Logs
AWS Config
Amazon Inspector
IAM Access Analyzer
Amazon Security Lake or Amazon Athena, where available
AWS CLI
Visual Studio Code or Obsidian

🏗 Investigation Architecture

Incoming SOC Alert

        │
        ▼

Alert Validation and Triage

        │
        ▼

Security Hub and GuardDuty

        │
        ├── Amazon Detective
        ├── AWS CloudTrail
        ├── VPC Flow Logs
        ├── AWS Config
        ├── Amazon Inspector
        ├── CloudWatch Logs
        └── Security Lake / Athena

        │
        ▼

Evidence Correlation

        │
        ├── Identity Activity
        ├── Network Activity
        ├── Resource Changes
        ├── Data Access
        └── Defensive Evasion

        │
        ▼

Incident Timeline and Scope

        │
        ▼

Containment Recommendations

        │
        ▼

Eradication and Recovery

        │
        ▼

Technical and Executive Reporting

Mission Information

Field	Value
Incident ID	CN-SOC-2026-013
Detection Time	02:15 UTC
Affected Environment	Production AWS Account
Initial Severity	High
Assigned Team	Cloud SOC Tier 2
Incident Category	Suspected IAM Credential Compromise
Investigation Status	Open
Business Service	CloudNova Customer Portal

Step 1 — Open the Incident Record

Create an incident record before beginning the investigation.

Record:

Incident ID
Date and time detected
Alert source
Initial finding title
AWS account ID
AWS Region
Affected resource
Assigned analyst
Initial severity
Current status

Use the following status:

Open — Investigation in Progress

Incident Record

Field	Analyst Entry
Incident ID
Alert Source
Detection Time
AWS Account
AWS Region
Affected Identity
Affected Resource
Assigned Analyst
Initial Severity
Current Status

Step 2 — Review the Initial Alert

Navigate to:

AWS Console

↓

Amazon GuardDuty

↓

Findings

Review the high-severity finding that initiated the investigation.

Capture:

Finding ID
Finding type
Severity
First seen
Last seen
Affected account
Affected Region
Affected IAM principal or resource
Source IP address
API action
Threat intelligence details

Questions:

What behaviour triggered the finding?
Is the activity expected for this identity?
Has the source IP appeared previously?
Is the source country associated with normal business activity?
Is the finding active or historical?

AWS CLI

aws guardduty list-detectors

Record the detector ID, then run:

aws guardduty list-findings \
  --detector-id YOUR_DETECTOR_ID

Retrieve finding details:

aws guardduty get-findings \
  --detector-id YOUR_DETECTOR_ID \
  --finding-ids YOUR_FINDING_ID

Step 3 — Validate the Alert

Determine whether the alert is:

True Positive
Benign True Positive
False Positive
Inconclusive

Validate:

The identity exists
The source IP is accurate
The API call occurred
The account and Region are correct
The activity is not part of approved maintenance
The user was not travelling or using an approved VPN
The event was not generated by authorised automation

Alert Validation Worksheet

Question	Answer	Evidence
Did the event occur?
Is the identity valid?
Is the activity authorised?
Is the source IP trusted?
Was MFA used?
Is there related suspicious activity?
Is escalation required?

Step 4 — Classify Incident Severity

Use the CloudNova severity model.

Severity	Definition	Example
Critical	Confirmed compromise with major business impact	Administrative access, data exfiltration, service disruption
High	Likely compromise affecting sensitive resources	Privilege escalation, malicious EC2 activity
Medium	Suspicious activity requiring investigation	Unusual API calls, repeated failed logins
Low	Limited risk or informational event	Policy drift, minor control failure

Consider:

Privileges of the affected identity
Sensitivity of accessed data
Number of affected resources
Evidence of persistence
Evidence of data access
Business service criticality
Cross-account impact
Regulatory impact

Record:

Incident Severity:

Incident Priority:

Justification:

Step 5 — Review Security Hub Findings

Navigate to:

AWS Console

↓

AWS Security Hub

↓

Findings

Filter by:

AWS Account
Resource ID
IAM identity
Source IP
Time range
Severity
Workflow status

Review findings from:

GuardDuty
Inspector
AWS Config
IAM Access Analyzer
Security Hub controls

Update the workflow status to:

NOTIFIED

or:

IN_PROGRESS

Record:

Related findings
Affected resources
Compliance failures
Duplicate findings
Finding timestamps
Remediation status

AWS CLI

aws securityhub get-findings \
  --filters '{
    "SeverityLabel": [
      {
        "Value": "HIGH",
        "Comparison": "EQUALS"
      }
    ]
  }'

Step 6 — Investigate with Amazon Detective

Open the GuardDuty finding in Amazon Detective.

Review:

IAM user or role profile
EC2 instance profile
Source IP address
API call volume
Geographic activity
Newly observed behaviour
Associated findings
Related AWS resources
Network connections
Historical activity

Determine:

Whether the activity is new for the identity
Whether the identity accessed unusual services
Whether multiple identities used the same IP
Whether the affected EC2 instance communicated with known malicious infrastructure
Whether suspicious activity occurred before the first alert

Record:

Earliest Suspicious Activity:

Primary Entity:

Related Entities:

Observed Behaviour:

Detective Assessment:

Step 7 — Review CloudTrail Authentication Events

Search CloudTrail for authentication activity.

Review:

ConsoleLogin
AssumeRole
GetSessionToken
CreateAccessKey
UpdateAccessKey
DeactivateMFADevice
DeleteVirtualMFADevice

Navigate to:

AWS Console

↓

CloudTrail

↓

Event History

Filter by:

Username
Event name
Source IP
Access key ID
Time range

AWS CLI

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=YOUR_USERNAME

Search for console logins:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin

Document:

Login time
Source IP
User agent
MFA status
Login result
AWS Region
Access key ID
Session issuer

Step 8 — Review IAM Privilege Changes

Search for:

AttachUserPolicy
AttachRolePolicy
PutUserPolicy
PutRolePolicy
CreatePolicyVersion
SetDefaultPolicyVersion
AddUserToGroup
UpdateAssumeRolePolicy
CreateRole
PassRole

Determine:

Whether privilege escalation occurred
Which policy was attached
Who initiated the change
Whether the change was authorised
Whether the identity gained administrative access
Whether the identity could assume additional roles

AWS CLI

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AttachUserPolicy

Review the affected identity:

aws iam list-attached-user-policies \
  --user-name YOUR_USERNAME

Review inline policies:

aws iam list-user-policies \
  --user-name YOUR_USERNAME

Step 9 — Review Access-Key Activity

Review:

Access-key creation time
Access-key last-used information
Services accessed
Regions accessed
Whether the key is still active
Whether the key was used from multiple IP addresses

AWS CLI

aws iam list-access-keys \
  --user-name YOUR_USERNAME

aws iam get-access-key-last-used \
  --access-key-id YOUR_ACCESS_KEY_ID

Do not deactivate or delete the key during the evidence-review stage unless emergency containment has been authorised.

Record:

Access Key	Status	Created	Last Used	Service	Region

Step 10 — Review EC2 Security Changes

Search CloudTrail for:

AuthorizeSecurityGroupIngress
AuthorizeSecurityGroupEgress
ModifyInstanceAttribute
AssociateIamInstanceProfile
ReplaceIamInstanceProfileAssociation
RunInstances
StartInstances
StopInstances
CreateImage
CreateSnapshot

Review the affected security group.

AWS CLI

aws ec2 describe-security-groups \
  --group-ids YOUR_SECURITY_GROUP_ID

Identify:

Open ports
Source CIDR ranges
Time of modification
User or role that made the change
Resources attached to the security group
Whether production systems were exposed

Pay particular attention to:

0.0.0.0/0

::/0

and sensitive ports such as:

Step 11 — Analyse VPC Flow Logs

Navigate to:

AWS Console

↓

CloudWatch Logs

↓

VPC Flow Log Group

Review traffic associated with the affected EC2 instance.

Search for:

Suspicious source IP addresses
Repeated connection attempts
Unusual outbound ports
Connections to known malicious infrastructure
Large outbound data transfers
Rejected traffic
Connections outside normal business regions

Example CloudWatch Logs Insights query:

fields @timestamp, srcAddr, dstAddr, srcPort, dstPort, action, bytes
| filter srcAddr = "SUSPICIOUS_IP" or dstAddr = "SUSPICIOUS_IP"
| sort @timestamp asc

Search by EC2 private IP:

fields @timestamp, srcAddr, dstAddr, srcPort, dstPort, protocol, packets, bytes, action
| filter srcAddr = "EC2_PRIVATE_IP" or dstAddr = "EC2_PRIVATE_IP"
| sort @timestamp asc

Record:

First connection
Last connection
Direction
Source and destination
Destination port
Bytes transferred
Action
Related EC2 instance

Step 12 — Review EC2 Instance Activity

Review:

Instance ID
AMI
Instance launch time
Public and private IP addresses
IAM instance profile
Security groups
Subnet
CloudWatch metrics
Systems Manager status
Recent configuration changes
Inspector findings
GuardDuty findings

AWS CLI

aws ec2 describe-instances \
  --instance-ids YOUR_INSTANCE_ID

Review CloudWatch metrics for:

CPU utilisation
Network in
Network out
Disk activity
Status-check failures

Questions:

Was the instance behaving abnormally?
Was there a sudden increase in network output?
Was a new IAM role attached?
Was the instance launched by the attacker?
Was the instance used for scanning or cryptocurrency mining?

Step 13 — Review Amazon Inspector Findings

Navigate to:

AWS Console

↓

Amazon Inspector

↓

Findings

Filter by:

Instance ID
Severity
Package
CVE
First observed
Last observed

Determine:

Whether a known vulnerability may have been exploited
Whether the vulnerability was remotely exploitable
Whether exploit code is available
Whether the vulnerability existed before the incident
Whether patching was overdue

AWS CLI

aws inspector2 list-findings \
  --filter-criteria '{
    "resourceId": [
      {
        "comparison": "EQUALS",
        "value": "YOUR_INSTANCE_ID"
      }
    ]
  }'

Step 14 — Review S3 Data Access

Search CloudTrail data events for:

GetObject
ListBucket
PutObject
DeleteObject
PutBucketPolicy
PutBucketAcl
PutPublicAccessBlock
DeletePublicAccessBlock

Determine:

Which bucket was accessed
Which objects were accessed
Whether sensitive data was involved
Number of objects downloaded
Source IP address
Identity used
Volume of data transferred
Whether bucket permissions changed

Example CloudWatch Logs Insights query:

fields @timestamp, eventName, userIdentity.arn, sourceIPAddress, requestParameters.bucketName, requestParameters.key
| filter eventSource = "s3.amazonaws.com"
| filter eventName in ["GetObject", "ListBucket", "PutBucketPolicy", "DeletePublicAccessBlock"]
| sort @timestamp asc

Create an affected-data register.

Bucket	Object or Prefix	Action	Identity	Source IP	Sensitivity

Step 15 — Review CloudTrail Tampering

Search for:

StopLogging
DeleteTrail
UpdateTrail
PutEventSelectors
DeleteEventDataStore
UpdateEventDataStore
PutInsightSelectors

AWS CLI

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=StopLogging

Determine:

Whether logging was interrupted
How long logging was unavailable
Who made the change
Whether log-file validation remained enabled
Whether alternate logs captured activity
Whether this was an attempt at defence evasion

Record:

CloudTrail Tampering Confirmed: Yes / No

Logging Interruption:

Affected Trail:

Initiating Identity:

Business Impact:

Step 16 — Review AWS Config Changes

Navigate to:

AWS Console

↓

AWS Config

↓

Resource Timeline

Review configuration changes for:

IAM users and roles
Security groups
EC2 instances
S3 buckets
CloudTrail trails
KMS keys
Network resources

Determine:

What changed
When the change occurred
Previous configuration
Current configuration
Whether the resource became non-compliant

AWS CLI

aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup \
  --resource-id YOUR_SECURITY_GROUP_ID

Step 17 — Review IAM Access Analyzer Findings

Navigate to:

AWS Console

↓

IAM Access Analyzer

↓

Findings

Review:

Public S3 access
External role trust
Cross-account access
Externally shared KMS keys
Externally shared secrets
Unintended resource policies

Determine whether the attacker created or modified external access paths.

AWS CLI

aws accessanalyzer list-findings \
  --analyzer-arn YOUR_ANALYZER_ARN

Step 18 — Search Security Lake or Athena

Where Amazon Security Lake is configured, query centralised security telemetry.

Review:

CloudTrail events
VPC Flow Logs
Security findings
Route 53 resolver logs
EKS audit logs, where applicable

Correlate events by:

AWS account
IAM principal
Source IP
Resource ID
Access key ID
Time range

Example investigation logic:

Identity

↓

Source IP

↓

API Calls

↓

Privilege Changes

↓

Resource Changes

↓

Network Activity

↓

Data Access

Document query references and evidence locations.

Step 19 — Determine the Initial Access Method

Evaluate possible initial access paths:

Compromised password
Compromised access key
MFA bypass
Exposed credential in code
Phishing
Compromised third-party integration
Misconfigured role trust
EC2 instance-profile credential theft
Federated identity compromise

Record:

Most Likely Initial Access Method:

Supporting Evidence:

Alternative Hypotheses:

Confidence Level:

Use:

High Confidence
Medium Confidence
Low Confidence

Step 20 — Identify Privilege Escalation and Persistence

Review whether the attacker:

Attached an administrative policy
Created a new IAM user
Created a new access key
Added a user to a privileged group
Modified a role trust policy
Created a backdoor role
Created a new Lambda function
Modified an existing Lambda function
Created an EC2 key pair
Modified a security group
Created scheduled automation
Created or modified Secrets Manager secrets

Document all persistence mechanisms.

Technique	Resource	Evidence	Status

Step 21 — Determine Incident Scope

Identify all affected:

AWS accounts
AWS Regions
IAM users
IAM roles
Access keys
EC2 instances
Security groups
S3 buckets
KMS keys
Secrets
Lambda functions
VPCs
Databases
CloudTrail trails

Scope Matrix

Resource Type	Resource ID	Account	Region	Impact

Classify each resource as:

Confirmed Affected
Potentially Affected
Reviewed — No Evidence
Investigation Pending

Step 22 — Build the Incident Timeline

Create a chronological timeline.

Time	Event	Evidence Source
02:15	Initial GuardDuty alert	GuardDuty

Include:

Initial access
Authentication
Access-key creation
Privilege escalation
Security group modification
EC2 activity
S3 access
CloudTrail tampering
Detection
Analyst escalation
Containment approval
Recovery actions

Step 23 — Map Activity to MITRE ATT&CK

Map observed activity to relevant tactics.

Tactic	Observed Activity	Evidence
Initial Access	Compromised identity
Persistence	New access key or role
Privilege Escalation	Administrative policy attached
Discovery	AWS resource enumeration
Defence Evasion	CloudTrail logging modified
Credential Access	Access key creation
Collection	Sensitive S3 objects accessed
Exfiltration	Large outbound transfer
Impact	Production security controls weakened

Step 24 — Preserve Investigation Evidence

Preserve:

GuardDuty finding JSON
Security Hub findings
CloudTrail events
Detective investigation screenshots
VPC Flow Logs
AWS Config history
Inspector findings
IAM policy documents
Access-key metadata
S3 data-access events
CloudWatch Logs Insights query results

Create an evidence register.

Evidence ID	Description	Source	Collected By	Date and Time	Hash or Validation
E-001

Store evidence in an encrypted, access-controlled evidence location.

Do not modify original evidence.

Do not perform destructive actions without authorised incident-response approval.

Recommended containment actions may include:

Disable the compromised access key
Revoke active sessions
Reset the affected user’s credentials
Require MFA registration
Detach unauthorised policies
Quarantine the affected EC2 instance
Apply an isolation security group
Restrict S3 access
Restore CloudTrail logging
Block malicious IP addresses
Preserve EC2 volumes using snapshots
Rotate exposed secrets
Restrict role trust policies
Notify legal, compliance, and privacy teams

Containment Plan

Action	Priority	Owner	Approval Required	Status

Recommended actions:

Remove unauthorised IAM users and roles
Remove malicious access keys
Remove unauthorised policies
Remove persistence mechanisms
Patch exploited vulnerabilities
Rebuild compromised EC2 instances
Remove unauthorised Lambda functions
Correct S3 bucket policies
Correct security-group rules
Rotate credentials and secrets
Review third-party integrations
Perform malware analysis where authorised

Recommended actions:

Restore workloads from known-good images
Restore data from validated backups
Re-enable production access gradually
Apply enhanced monitoring
Validate all security controls
Confirm CloudTrail and GuardDuty operation
Validate IAM access
Review Security Hub findings
Perform post-recovery vulnerability scans
Increase monitoring for related indicators
Obtain business-owner approval before closure

Step 28 — Validate Post-Incident Security

Confirm:

Compromised access keys disabled
Active sessions revoked
Unauthorised policies removed
Security groups corrected
S3 permissions restored
CloudTrail logging active
GuardDuty operational
Security Hub receiving findings
EC2 instance isolated or rebuilt
Secrets rotated
Additional suspicious activity absent
Monitoring period completed

Step 29 — Create the Technical Incident Report

The technical report must include:

Incident Summary
Detection Source
Incident Severity
Affected Accounts and Regions
Affected Identities
Affected Resources
Initial Access Assessment
Attack Timeline
Privilege Escalation
Persistence
Network Activity
Data Access
Defensive Evasion
Evidence Collected
Containment Recommendations
Eradication Recommendations
Recovery Recommendations
Root Cause
Security-Control Gaps
Lessons Learned

Step 30 — Create the Executive Incident Summary

The executive summary should explain:

What happened
When it happened
How it was detected
Which business services were affected
Whether customer or sensitive data was accessed
Whether the incident is contained
Current business risk
Immediate actions taken
Required leadership decisions
Long-term improvement recommendations

Avoid excessive technical detail.

Use clear business language.

🧪 Enterprise Challenge

During the investigation, additional evidence reveals that the compromised IAM identity was used across three AWS Regions.

The attacker:

Created two access keys
Attached AdministratorAccess
Modified a production role trust policy
Opened port 22 to the Internet
Launched an EC2 instance
Used the instance to scan internal systems
Downloaded sensitive S3 objects
Attempted to disable CloudTrail
Created a Lambda function for persistence
Accessed a Secrets Manager secret
Communicated with a known malicious IP address

As the Tier-2 SOC Analyst, you must:

Validate all alerts
Identify the initial access method
Identify privilege escalation
Identify persistence
Determine the full blast radius
Correlate evidence across all affected Regions
Preserve relevant evidence
Produce containment recommendations
Produce an eradication plan
Produce a recovery plan
Brief the SOC Manager and CISO
Produce a complete executive incident report

📄 Deliverables

Capture evidence of:

GuardDuty finding
Security Hub findings
Amazon Detective investigation
CloudTrail authentication events
IAM policy changes
Access-key activity
Security-group modification
EC2 instance activity
VPC Flow Log analysis
Amazon Inspector findings
S3 data-access events
CloudTrail tampering
AWS Config history
IAM Access Analyzer findings
Security Lake or Athena queries

Submit:

SOC Alert Triage Worksheet
Complete Incident Investigation Report
Incident Timeline
MITRE ATT&CK Mapping
Affected Resource Register
Evidence Register
Containment Plan
Eradication Plan
Recovery Plan
Root-Cause Analysis
Executive Incident Summary
Post-Incident Improvement Plan

🧹 Cleanup

This is primarily an investigation runbook.

Do not delete or modify evidence before approval.

Retain:

CloudTrail logs
GuardDuty findings
Security Hub findings
VPC Flow Logs
AWS Config history
Detective investigation data
Inspector findings
Security Lake data
Incident reports
Evidence register
Screenshots and exported query results

Delete only after authorised closure:

Test IAM identities
Test access keys
Test EC2 instances
Test Lambda functions
Temporary security-group rules
Temporary investigation resources

Review all active resources and confirm that no unintended charges remain.

Runbook 02 Enterprise SOC Security Monitoring

🎯 Objective

🏢 Business Scenario

📋 Prerequisites

🏗 Investigation Architecture

Mission Information

Step 1 — Open the Incident Record

Incident Record

Step 2 — Review the Initial Alert

AWS CLI

Step 3 — Validate the Alert

Alert Validation Worksheet

Step 4 — Classify Incident Severity

Step 5 — Review Security Hub Findings

AWS CLI

Step 6 — Investigate with Amazon Detective

Step 7 — Review CloudTrail Authentication Events

AWS CLI

Step 8 — Review IAM Privilege Changes

AWS CLI

Step 9 — Review Access-Key Activity

AWS CLI

Step 10 — Review EC2 Security Changes

AWS CLI

Step 11 — Analyse VPC Flow Logs

Step 12 — Review EC2 Instance Activity

AWS CLI

Step 13 — Review Amazon Inspector Findings

AWS CLI

Step 14 — Review S3 Data Access

Step 15 — Review CloudTrail Tampering

AWS CLI

Step 16 — Review AWS Config Changes

AWS CLI

Step 17 — Review IAM Access Analyzer Findings

AWS CLI

Step 18 — Search Security Lake or Athena

Step 19 — Determine the Initial Access Method

Step 20 — Identify Privilege Escalation and Persistence

Step 21 — Determine Incident Scope

Scope Matrix

Step 22 — Build the Incident Timeline

Step 23 — Map Activity to MITRE ATT&CK

Step 24 — Preserve Investigation Evidence

Step 25 — Recommend Immediate Containment

Containment Plan

Step 26 — Recommend Eradication Actions

Step 27 — Recommend Recovery Actions

Step 28 — Validate Post-Incident Security

Step 29 — Create the Technical Incident Report

Step 30 — Create the Executive Incident Summary

🧪 Enterprise Challenge

📄 Deliverables

🧹 Cleanup

✅ Runbook Checklist

💡 Lessons Learned

Which security event provided the earliest reliable indication of compromise?

How did correlating GuardDuty, Security Hub, Detective, CloudTrail, VPC Flow Logs, and AWS Config improve the investigation?

What evidence confirmed the initial access method?

Which attacker actions represented privilege escalation, persistence, defence evasion, and data access?

How did you determine the incident blast radius?

Which containment action should be completed first, and why?

What controls could have prevented or detected this incident earlier?

How should CloudNova Technologies improve its 24×7 SOC operating model?

🚀 Next Enterprise Runbook