TA0001 · Initial Access
T1190 Exploit Public-Facing Application
Crafted query-string payloads were sent to a public HTTPS application attempting SQL injection exploitation.
Cloud security · Incident response
Investigate cloud incidents the way a SOC would.
Walk a case from ticket briefing to evidence locker, log console, and findings report. Practice the same pivots a SOC analyst uses across cloud telemetry.
How a case works
One investigation path for every lab
15 open cases across EC2 4, IAM 3, Lambda 1, RDS 2, S3 2, WAF 3. The workspace stays the same as the catalog grows — only the evidence changes.
01
Case briefing
Read the ticket, environment, and log window before you open evidence.
02
Evidence locker
Review the exports attached to the case — CloudTrail, WAF, VPC Flow, and more.
03
Investigate
Search and pivot across logs the way a SOC would: source IP, request ID, session, object key.
04
File findings
Answer from evidence, then close the case with score, ATT&CK mapping, and remediation.
What you get at the end
A scored findings report on every submission
After you file your report, the case closes with a numeric score, per-question explanations, MITRE ATT&CK mapping, and remediation actions — all derived from the evidence you just investigated.
AWS-WAF-001·AWS WAF SQL Injection Attack InvestigationCase close-out
Investigation score
9/10
90%
Answer explanations
Q1. What is the source IP address responsible for the SQL injection campaign?
CorrectYour answer: 203.0.113.66 · Accepted: 203.0.113.66 · 10/10 pts
All SQLi rule matches and the comment-obfuscated request originated from 203.0.113.66 — visible in both the WAF logs and the correlated ALB records.
Q2. Which WAF rule produced a COUNT action for the first probe at 08:12 UTC?
CorrectYour answer: SQLi_QUERYARGUMENTS · Accepted: SQLi_QUERYARGUMENTS · 10/10 pts
The AWSManagedRulesSQLiRuleSet rule SQLi_QUERYARGUMENTS was configured in COUNT mode during the tuning window, so early probes were observed but not blocked.
Q3. What HTTP status did the origin return for the comment-obfuscated request?
IncorrectYour answer: 404 · Accepted: 500 · 0/10 pts
The origin returned HTTP 500, indicating the application attempted to process the tainted identifier and failed — a strong signal the query reached the database.
MITRE ATT&CK mapping
TA0002 · Execution
T1059.011 Command and Scripting Interpreter: SQL
Payloads included UNION SELECT, DROP TABLE, and SLEEP constructs intended to execute SQL on the backend database.
TA0009 · Collection
T1213 Data from Information Repositories
UNION queries referenced information_schema.tables indicating an attempt to enumerate and extract repository data.
Remediation actions
Move SQLi managed rules from COUNT to BLOCK
SQLi_QUERYARGUMENTS was observing early probes in COUNT mode, allowing reconnaissance to reach the origin. Set AWSManagedRulesSQLiRuleSet to BLOCK for production after confirming false-positive rate.
Add WAF text transformation coverage for obfuscation
A comment-obfuscated payload (/* */) URL-encoded in the query string was not matched and returned HTTP 500. Enable URL_DECODE, HTML_ENTITY_DECODE, and SQL_COMMENTS transformations on inspection.
This is a live preview from AWS-WAF-001. Complete any lab to generate your own scored report.
Investigation series
Related labs that build on each other
Some cases share a narrative arc. Completing a series builds continuity across related incident types without depending on any particular company branding.
Identity to database
Start with IAM privilege escalation, then investigate a separate brute-force attack against RDS in the same account narrative.
Edge to serverless to data
Move from incomplete WAF coverage to a Lambda webhook compromise, then investigate how the persisted backdoor turns an overprivileged role into S3 data destruction.
Case catalog
Filter by service, difficulty, or time
15 open cases. Filter by AWS service, difficulty, or time budget — then open a lab and start the investigation.