Investigate an incident you staged a week ago

capstone · 150 min · Objective 4.9

Task

Stage a multi-stage incident on your own lab, leave it alone long enough to forget the details, then investigate it from the evidence only — producing a timeline, a scope statement and a root cause analysis that ends in control changes rather than a name.

Steps

  1. STAGE (day one). Write a script that performs a five-stage sequence on the lab: a simulated phishing delivery — a file arriving in a mailbox directory; execution of a harmless script from it; persistence via a scheduled task; a beacon loop to your second VM; and access to a file share using a second account's credentials.
  2. Run it, with all the logging from your earlier labs in place. Then write down NOTHING about what it did, and leave it for at least a week.
  3. INVESTIGATE (day eight). Start from one indicator only — the beacon's destination — and work outwards using the evidence.
  4. Build the timeline into /tmp/case-timeline.csv, every entry citing the source log it came from, normalised to UTC.
  5. Write the scope: which accounts, which hosts, which data, over what period — and equally, what you checked and established was NOT affected, with how you established it.
  6. Perform the root cause analysis by asking why five times, and produce at least four CONTROL changes rather than one cause. 'A script was executed' is the first event, not the root cause.
  7. Now open the staging script and compare it against your timeline. Record in /tmp/case-report.md what you missed, what you inferred correctly, and what you concluded that was wrong.
  8. For each thing you missed, name the collection or detection change that would have surfaced it.

Verify

python3 - <<'PY'
import csv,re
rows=list(csv.DictReader(open('/tmp/case-timeline.csv')))
assert len(rows)>=8, 'fewer than eight events reconstructed'
srcs={r['source'] for r in rows}
assert len(srcs)>=4, 'the timeline draws on fewer than four sources: '+str(sorted(srcs))
times=[r['utc_time'] for r in rows]
assert times==sorted(times), 'timeline is not chronological'
t=open('/tmp/case-report.md').read()
changes=re.findall(r'^\s*[-*]\s*CONTROL:', t, re.M)
assert len(changes)>=4, 'root cause analysis produced %d control changes, expected at least 4' % len(changes)
for word in ('MISSED','WRONG','NOT AFFECTED'):
    assert word.lower() in t.lower(), 'the report does not record what was '+word.lower()
print('%d events, %d sources, %d control changes' % (len(rows),len(srcs),len(changes)))
PY
grep -ciE "five times|why" /tmp/case-report.md

The assertions require a genuine multi-source reconstruction and — the part that makes this a Domain 4 capstone — at least four control changes from the root cause analysis. An RCA that produces one cause has stopped at the first plausible answer, which is the failure the lesson describes.

Recording what you MISSED and what you got WRONG is mandatory, and it is the most valuable output. Nobody reconstructs a staged incident perfectly, and the gap between your timeline and the script is a measurement of your detection coverage.

Notes

The week's delay is the whole design and it is the step people skip. Investigating something you staged an hour ago tests your memory; investigating it after a week tests your logging, your retention, and your ability to reason from evidence — which is the only one of the three that will be available during a real incident.

This is an independent study companion for CompTIA Security+ SY0-701 and is not produced by or endorsed by CompTIA.