03 - Web and Cloud Incident Playbooks

This section outlines specific step-by-step procedures for common web and cloud incidents.

Playbook 1: Compromised AWS Access Key

Scenario: An AWS IAM Access Key was accidentally committed to a public GitHub repository.

AWS GuardDuty alert: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
GitHub Secret Scanning alert.
Unexpected billing spikes.

Identify the Key: Locate the exact AccessKeyId.
Deactivate the Key: Do not delete it immediately. Deactivating prevents further use while allowing you to investigate what it was used for.
```
aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name Alice
```
Determine Impact (CloudTrail): Analyze AWS CloudTrail logs to see every API call made by that key since it was compromised.
```
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE
```

Revoke Temporary Sessions: If the key was used to assume roles, revoke active sessions.

aws iam put-role-policy --role-name CompromisedRole --policy-name RevokeSessions --policy-document file://revoke-policy.json

Revert Changes: Based on the CloudTrail analysis, undo any malicious actions (e.g., terminate unauthorized EC2 instances, delete rogue IAM users, revert security group changes).
Delete Key & Rotate: Once the investigation is complete, delete the compromised key and issue a new one to the user.

Scenario: An attacker exploited an arbitrary file upload vulnerability and uploaded a PHP webshell to the web server.

EDR alert for a web server process (e.g., www-data or nginx) spawning an interactive shell (/bin/sh, cmd.exe).
File Integrity Monitoring (FIM) detects a new .php, .jsp, or .aspx file in the webroot.
WAF alerts showing malicious commands in HTTP parameters.

Isolate the Server: Isolate the affected web server at the network layer to prevent lateral movement, but keep it running for memory analysis.
Preserve Evidence:
- Capture memory.
- Copy access logs (/var/log/nginx/access.log), error logs, and system logs.
- Copy the suspected webshell file (hash it immediately).
Analyze Logs: Determine how the webshell was uploaded. Look for the first HTTP request that accessed the shell, then trace back to the upload request. Find the source IP and look for other activity from that IP.
Eradicate:
- Delete the webshell.
- Identify and fix the vulnerability (e.g., implement strict file upload validation, patch the CMS).
- Check for persistence mechanisms (cron jobs, scheduled tasks, modified startup scripts).
Rebuild: Best practice is to consider the server fundamentally compromised. Rebuild the server from a known good image, apply the fix, and redeploy.

Scenario: Multiple endpoints are reporting encrypted files and displaying ransom notes.

Immediate Isolation: Speed is critical. Immediately isolate ALL suspected infected hosts from the network using EDR or network controls. Disconnect file shares to prevent network encryption.
Identify Patient Zero: Review logs to find the first machine infected to determine the initial access vector (e.g., phishing email, RDP brute force, unpatched VPN vulnerability).
Halt Propagation: Block identified IoCs (C2 domains, malicious IPs, hashes) on firewalls and EDR.
Do Not Reboot: Rebooting can sometimes trigger data destruction or lose the encryption keys stored in memory.
Assess Backups: Verify the integrity of offline/immutable backups. Ensure they have not been compromised.
Eradicate & Recover: Wipe the infected machines completely. Reinstall the OS from golden images and restore data from verified clean backups. Do NOT pay the ransom unless human life is at risk and all other options are exhausted.