▣ Tailgate / GuestList

Scenario 1 of 2 · Reactive DFIR

Tailgate — investigate the breach

A phishing email got someone in. Find how far the attacker got before anyone noticed, and write the incident report.

Setup (do this once)

1. Open a terminal. 2. cd ~/tailgate. 3. Start the agent: claude. 4. Paste each prompt below, in order, in the same chat, so it remembers. Type only the prompt text — no quotes.

~25 min per visit. Do the CORE phases (1, 2, 5) for the full story. DEEP phases (3, 4) are for a quiet moment or to run later — this page is yours to keep. No agent? Terminal fallback commands are at the bottom.

Phase 1 Core

Act 1 — initial access

Paste this, then Enter:

Using your cybersecurity skills, investigate phishing-email.eml, mail-gateway.log, and endpoint-alert.log: find how the initial foothold was gained, extract the malicious attachment's SHA-256 hash, and tell me which external IP the attacker used to access Bellwood's systems afterward. List the skills you used.

You will see: a lookalike sending domain, a macro-enabled attachment, a PowerShell download cradle, and a sign-in from an unfamiliar external IP with no MFA.

Checkpoint — on track when you see

Attachment hash a1e4c9d2f6b8034e7c1a29d5f3b6e8901c4d7f2a5b8e1c4f7a0d3b6e9c2f5a81, attacker IP 203.0.113.77, and a VPN session landing at internal address 10.20.14.230.

Reveal the answer

Phishing from bellwood-support.com (lookalike domain) got through because DMARC is p=none and SPF is ~all (soft-fail, not hard-fail). Sandra Kim opened Invoice_BW88291.xlsm; EXCEL.EXE spawned POWERSHELL.EXE with an encoded download cradle. ~40 minutes later her account signed in from 203.0.113.77 (Amsterdam-area hosting ASN, her first-ever non-Chicago sign-in) with no MFA challenge, then used that session against the external VPN gateway, landing internal address 10.20.14.230. Techniques: T1566.001, T1204.002, T1078, T1133.

Phase 2 Core

Act 2 — lateral movement

Same chat:

Now use your network-security skills on network/netflow.txt and network/smb-rdp-events.txt: trace where the VPN-assigned address 10.20.14.230 went next inside the network, and tell me which two internal hosts it reached and how.

You will see: two internal hosts it had never talked to before, reached by RDP and SMB, both off-hours.

Checkpoint — on track when you see

RDP to JMP-ADMIN01 (event 4624 type 10) and SMB/ADMIN$ to FILESVR01 (event 4624 type 3) — both first-time-seen host pairs in the 30-day netflow baseline, both at ~02:1x UTC (outside 13:00–01:00 UTC business hours).

Reveal the answer

10.20.14.230 pivoted to JMP-ADMIN01 (10.20.1.50) via RDP and to FILESVR01 (10.20.1.15) via SMB/ADMIN$ — neither host pair appears anywhere in the prior 30 days of netflow. A high-volume SMB flow to JMP-ADMIN01 immediately preceded the RDP logon, consistent with staging a tool ahead of the Kerberos activity in Act 3. Techniques: T1570, T1021.002, T1021.001.

Phase 3 Deep

Baseline vs. anomaly

Same chat:

What does normal Kerberos ticket-request activity look like on this domain, and what makes the activity from JMP-ADMIN01 stand out? Could this have been caught WITHOUT already knowing which account was compromised?

You will see: a baseline of 1-2 requests/hour vs. a 14-request burst in 86 seconds, every one downgraded to a weaker ticket-encryption type.

Checkpoint — on track when you see

Baseline = AES256 (etype 0x12) by domain policy, 1-2 requests/hour. The burst = RC4 (etype 0x17), 14 requests in 86 seconds. Rate + encryption downgrade is the tell, not the specific account.

Reveal the answer

Detectable by volume and encryption type alone, independent of which account is requesting: a burst of RC4-downgraded TGS requests against multiple SPN accounts in under two minutes is the classic Kerberoasting signature, regardless of whose credentials are doing the requesting.

Phase 4 Deep

Map it — and check the agent

Same chat:

Map the full attack to MITRE ATT&CK technique IDs. Then tell me: was AS-REP Roasting (T1558.004) actually carried out against svc-legacyapp, or only exposed as a possibility? Show the evidence either way.

You will see: a clean chain from phishing through to Kerberoasting — and watch whether the agent correctly separates "exposed" from "exploited" for the AS-REP finding, or over-claims it.

Checkpoint — on track when you see

The chain: T1566.001 → T1204.002 → T1078 → T1133 → T1570 → T1021.002/T1021.001 → T1558.003. For T1558.004: the agent should say not confirmed — this is the deliberate catch built into this scenario.

Reveal the answer

svc-legacyapp's AS-REP exposure was not used. A targeted search of the incident window for a 4768 event without pre-authentication against svc-legacyapp returns no matching events — the account is equally vulnerable but this attacker never touched it. Exposed ≠ exploited. If the agent claimed AS-REP Roasting "was carried out," that's the over-claim to correct.

Phase 5 Core

Incident report

Same chat:

Write a short incident report: the full attack chain, the VERIFIED ATT&CK IDs, and the single change that would have stopped it at the earliest point.

You will see: phishing → foothold → lateral movement → Kerberoasting, and "enforce DMARC p=reject" as the one fix that breaks the whole chain at step one.

Checkpoint — on track when you see

One chain, an ID per step, and a single earliest-point fix — DMARC enforcement, not a downstream control.

Reveal the answer

Enforce DMARC to p=reject with SPF -all — blocks bellwood-support.com's spoofed mail before delivery, breaking the entire chain at step one, the earliest possible point.

Explore without spoiling it

Want to poke at the raw data yourself, agent aside?

grep -c "ALLOWED" mail-gateway.log
grep "0x17" ad/kerberos-events.txt | wc -l   # the RC4-downgrade burst

Terminal fallbacks (no agent)

grep -A2 "SIGNIN_SUCCESS" endpoint-alert.log
grep "NEW PEER" network/netflow.txt
grep -B1 "NOT FOUND" ad/kerberos-events.txt   # the AS-REP catch

Authorized & lawful use only. All data is synthetic and self-contained; no live systems are touched. Promotes the open-source Anthropic Cybersecurity Skills library (Apache-2.0); not affiliated with Anthropic PBC.

Next → Scenario 2: GuestList