---
title: "An 8-Minute ATT&CK Exercise Your Blue Team Can Steal"
date: 2026-11-12
canonical: "https://codeandcypher.com/posts/an-8-minute-attack-exercise-your-blue-team-can-steal/"
description: "A reusable 8-minute MITRE ATT&CK v19 tabletop exercise: map a 5-line cloud incident to telemetry, write a 4-line KQL detection, and reward honest gaps."
author: "Joshua Wortz"
---

# An 8-Minute ATT&CK Exercise Your Blue Team Can Steal


> A reusable 8-minute MITRE ATT&CK v19 tabletop exercise: map a 5-line cloud incident to telemetry, write a 4-line KQL detection, and reward honest gaps.

---



## Why 90-Minute Tabletop Exercises Lose the Room

Most security tabletop exercises suffer from one of two fatal flaws: either they sprawl into a 90-minute compliance ritual where participants debate hypothetical policy binders, or they treat the **MITRE ATT&CK®** matrix like a multiple-choice trivia game.

I call that second failure mode the **Green Box Fallacy**—the illusion that defensive maturity means shading 222 enterprise technique tiles green on a spreadsheet and declaring victory. In a working Security Operations Center (SOC), ATT&CK is not a scorecard. It is a **shared behavioral grammar** that connects what an adversary *did* to the exact telemetry table your systems record.

When I was invited to deliver a guest lecture for Professor Teresa Macklin's cybersecurity course at California State University San Marcos (CSUSM), I had a strict constraint: **30 minutes of formal talk time** before a 15-minute Q&A window. I couldn't spend an hour running a sprawling incident simulation. I needed an interactive exercise that could take analysts or students from a raw incident summary to ATT&CK v19 technique mapping, log-source identification, and working **Kusto Query Language (KQL)** detection code in **eight minutes flat**.

This post packages that exact 8-minute tabletop exercise—complete with the 5-line synthetic incident, facilitator run-of-show, master solution key, synthetic Entra ID `SigninLogs` artifact, and 4-line Sentinel query—so you can steal it for your next SOC shift handoff, brown-bag lunch, or university classroom.

---

## Setting the Baseline: The ATT&CK v19 Architecture Shift

Before dropping participants into the scenario, establish one ground rule: **always cite your framework version**.

For over a decade, textbooks and training decks taught that the ATT&CK Enterprise Matrix contained 14 tactics, with all evasion tradecraft lumped into a single omnibus column: *Defense Evasion* (`TA0005`). In **ATT&CK v19 (April 2026)**, MITRE retired that single bucket and split it into two distinct operational tactics across the **15-tactic Enterprise Matrix**:

1. **Stealth (`TA0045`):** Passive adversary behaviors designed to blend into normal operational noise, masquerade as legitimate administrative activity, or hide artifacts without disrupting security controls—such as living off the land, renaming binaries, or creating hidden mailbox rules (`T1564.008`).
2. **Defense Impairment (`TA0046`):** Active adversary behaviors that intentionally degrade, blind, tamper with, or disable defensive sensors—such as stopping an EDR service (`T1562.001`), clearing Windows Security Event Log `1102` (`T1070.001`), or deleting firewall rules.

```mermaid
flowchart TD
    Legacy["Legacy ATT&CK (Pre-v19)<br/>TA0005: Defense Evasion"] --> Split{"ATT&CK v19 Architectural Split<br/>(April 2026 — 15 Enterprise Tactics)"}
    Split -->|"Passive Blending & Masking"| Stealth["TA0045: Stealth<br/>• Hide Artifacts: Email Hiding Rules (T1564.008)<br/>• Masquerading (T1036)<br/>• Living off the Land"]
    Split -->|"Active Sensor Disruption"| Impairment["TA0046: Defense Impairment<br/>• Disable or Modify Tools (T1562.001)<br/>• Clear Windows Event Logs (T1070.001)<br/>• Tamper with Firewall Rules"]
```

Why does this distinction matter in a tabletop exercise? Because passive stealth and active sensor impairment leave completely different telemetry footprints and demand different escalation priorities.

---

## The 8-Minute Run of Show

To keep the exercise tight and prevent the loudest voice in the room from anchoring everyone else's answers, run the clock in four strict blocks using a **Simultaneous Chat Waterfall**:

| Clock Window | Duration | Phase | Facilitator Action |
| :---: | :---: | :--- | :--- |
| **`00:00 – 01:00`** | **1 min** | **The Incident Drop** | Display the 5-line scenario on screen and paste it into the team chat. Frame the rules: map each numbered step to a **Tactic**, **Technique**, and **Primary Log Source**. |
| **`01:00 – 04:00`** | **3 min** | **Silent Mapping & Chat Waterfall** | Give participants 2 minutes of silent analysis to type their mappings into the chat input box **without pressing Enter**. At `03:45`, count down *"3, 2, 1 — Hit Enter!"* so every hypothesis lands simultaneously. |
| **`04:00 – 06:00`** | **2 min** | **Solution Key & Debrief** | Walk through Steps 1–5. Highlight why Step 4 has multiple valid mappings and why Step 5 rewards `"Insufficient Evidence"`. |
| **`06:00 – 08:00`** | **2 min** | **The Telemetry & KQL Bridge** | Show the raw JSON sign-in event from Step 3 and walk line-by-line through the 4-line KQL detection rule that catches it. |

---

## Phase 1: The 5-Line Incident Story (`00:00 – 01:00`)

Paste the following synthetic scenario directly into your Zoom, Teams, or Slack channel:

> **SCENARIO: THE 02:14 UTC IDENTITY ALERT (SYNTHETIC DATA)**
>
> **[1]** At `01:58 UTC`, a Payroll Specialist (`a.rivera@meridian-health.example`) receives an urgent email claiming their multi-factor authentication (MFA) token is expiring, containing a hyperlink to `https://login-meridian-portal[.]com`.  
> **[2]** The employee clicks the link and submits their corporate username, password, and one-time passcode into the fraudulent web form.  
> **[3]** Sixteen minutes later (`02:14 UTC`), an attacker authenticates into the corporate Microsoft 365 / Entra ID tenant as `a.rivera` from an unfamiliar residential proxy IP in Frankfurt, Germany (`185.220.101.42`).  
> **[4]** At `02:17 UTC`, a new mailbox rule named `.forward_ext` is created on `a.rivera`'s account that silently forwards all incoming emails containing the words *"Wire"*, *"ACH"*, or *"Invoice"* to an external proton.me address and marks them as read.  
> **[5]** At `02:22 UTC`, the compromised session reaches internal network file shares to look for payroll spreadsheets.

Provide participants with a clean 5-row worksheet template:

| Step | Story Event Summary | ATT&CK Tactic (The *Why*) | ATT&CK Technique / ID (The *How*) | Primary Log Source (Where to Look) |
| :---: | :--- | :--- | :--- | :--- |
| **1** | Urgent email with deceptive link (`login-meridian-portal[.]com`) | | | |
| **2** | User enters credentials into spoofed login portal | | | |
| **3** | Attacker logs into M365 from Frankfurt IP (`185.220.101.42`) | | | |
| **4** | Mailbox rule `.forward_ext` forwards & hides *"Invoice"* emails | | | |
| **5** | Compromised session reaches internal network file shares | | | |

---

## Phase 2: The Master Solution Key & Debrief (`04:00 – 06:00`)

Once the chat waterfall lands, walk through the solution matrix below. If participants don't know exact sub-technique numbers off the top of their heads, plain-English behavioral names (*Phishing Link*, *Valid Accounts*, *Email Forwarding*) earn full credit—the goal is behavioral reasoning, not memorizing numeric IDs.

| Step | Primary Tactic | Technique & ID | Also-Acceptable Mappings | Primary Telemetry & Log Source |
| :---: | :--- | :--- | :--- | :--- |
| **1** | **Initial Access** (`TA0001`) | **Phishing: Spearphishing Link** (`T1566.002`) | `T1566` (Phishing parent) | **Secure Email Gateway (SEG) / Microsoft Defender for Office 365** (`EmailEvents`, `UrlClickEvents`) |
| **2** | **Credential Access** (`TA0006`) | **Input Capture: Web Portal Capture** (`T1056.003`) | `T1557` (Adversary-in-the-Middle / Evilginx proxy) | **DNS Query Logs / Secure Web Gateway (SWG)** (`DnsEvents`, `CommonSecurityLog`) |
| **3** | **Initial Access** (`TA0001`) or **Persistence** (`TA0003`) | **Valid Accounts: Cloud Accounts** (`T1078.004`) | `T1078` (Valid Accounts parent), `T1550.004` (Web Session Cookie) | **Entra ID Sign-In Logs** (`SigninLogs`, `AADNonInteractiveUserSignInLogs`) |
| **4** | **Collection** (`TA0009`) or **Stealth** (`TA0045`) | **Email Collection: Email Forwarding Rule** (`T1114.003`) | `T1564.008` (Hide Artifacts: Email Hiding Rules), `T1098` (Account Manipulation) | **Exchange Online Unified Audit Log** (`CloudAppEvents` / `OfficeActivity` -> `New-InboxRule`) |
| **5** | **Discovery** (`TA0007`) *(or **Insufficient Evidence**)* | **File and Directory Discovery** (`T1083`) *(or **Unverified**)* | `T1135` (Network Share Discovery), `T1021.002` (SMB/Admin Shares) | **Windows Security Event `5140` / `5145`** or **Defender for Endpoint** (`DeviceFileEvents`, `DeviceProcessEvents`) |

### Lesson 1: Step 4 Proves That Mapping Is Interpretive, Not Multiple-Choice

Step 4 intentionally blends two actions inside a single Exchange operation: forwarding sensitive financial messages externally (`T1114.003` under **Collection**) and marking them as read under a dot-prefixed rule name `.forward_ext` so the victim never notices (`T1564.008` under **Stealth** `TA0045`, or `T1098` under **Persistence**).

In every group I run this with, analysts split across those three mappings. **All three are defensible.** The operational lesson is that two engineers can assign different ATT&CK IDs to Step 4 and still agree 100% on the detection surface: the Exchange Online `New-InboxRule` and `Set-InboxRule` audit events containing `ForwardTo` or `RedirectTo` parameters. Never waste incident response cycles arguing over taxonomy labels when you agree on the log source.

### Lesson 2: Step 5 Rewards "Insufficient Evidence" Over Guessing

Look closely at the wording of Step 5: *"the compromised session reaches internal network file shares to look for payroll spreadsheets."*

Notice how vague that sentence is compared to Steps 1–4. How did a cloud M365 session reach internal file shares?
- Did the attacker enumerate SharePoint Online document libraries (`T1213.002` — Data from Information Repositories)?
- Did they authenticate to an on-premises SMB share (`T1021.002`), triggering Windows Security Event ID `5140` (*A network share object was accessed*) or `5145`?
- Did they run `net view` (`T1135`) or `dir /s *payroll*.xlsx` (`T1083`) via a command shell?

From the five-line summary alone, **you cannot prove which sub-technique occurred**. If an analyst writes **`Insufficient Evidence — need SMB Event ID 5140/5145, SharePoint FileAccessed audit logs, or endpoint process telemetry to confirm`**, praise that answer publicly. In real-world incident response and [digital forensics hotwashes](/series/acuity-health-security-architecture/part-6-digital-forensics-ehr-vip-breach/), refusing to hallucinate certainty when telemetry is incomplete is the mark of a senior engineer.

---

## Phase 3: The Telemetry & KQL Bridge (`06:00 – 08:00`)

Conceptual mapping only matters if it translates into engineering action. In the final two minutes, bridge **Step 3 (`T1078.004 — Valid Accounts: Cloud Accounts`)** directly into raw telemetry and a KQL rule.

```mermaid
flowchart LR
    A["Adversary Behavior<br/>Step 3: Cloud Account Sign-In<br/>(T1078.004)"] --> B["Raw Telemetry Artifact<br/>Entra ID SigninLogs<br/>(ResultType: 0, LocationDetails)"]
    B --> C["Detection Engineering<br/>4-Line Sentinel KQL Rule<br/>(Failed Spray -> Success)"]
```

### 1. The Raw Telemetry Artifact (`SigninLogs`)

When the attacker authenticates as `a.rivera` at `02:14 UTC`, Microsoft Entra ID emits a JSON record into the `SigninLogs` table in Microsoft Sentinel:

```json
{
  "TimeGenerated": "2026-10-07T02:14:22.418Z",
  "UserPrincipalName": "a.rivera@meridian-health.example",
  "IPAddress": "185.220.101.42",
  "ResultType": "0",
  "ResultDescription": "Success",
  "AppDisplayName": "Office 365 Exchange Online",
  "ClientAppUsed": "Browser",
  "UserAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0",
  "AuthenticationRequirement": "multiFactorAuthentication",
  "RiskLevelDuringSignIn": "high",
  "LocationDetails": {
    "city": "Frankfurt am Main",
    "state": "Hesse",
    "countryOrRegion": "DE"
  }
}
```

Ask your team to spot the three high-signal fields:
- `"ResultType": "0"` — In Entra ID schema, `0` means authentication succeeded (whereas codes like `50126` indicate invalid credentials and `50074` indicates an unsatisfied MFA challenge).
- `"LocationDetails"` — Shows `"countryOrRegion": "DE"` (`185.220.101.42`) for a user whose baseline is Southern California.
- `"UserAgent"` — A Linux Firefox desktop session contrasting against a corporate Windows 11 fleet.

### 2. The 4-Line KQL Detection Rule

Now show how a blue team turns `SigninLogs` into an automated hunt for credential abuse (such as password spraying or repeated token/credential retries culminating in a successful login):

```kql
SigninLogs
| where TimeGenerated > ago(24h)
| summarize FailedCount = countif(ResultType != "0"), SuccessCount = countif(ResultType == "0") by UserPrincipalName, IPAddress, tostring(LocationDetails.countryOrRegion)
| where FailedCount > 5 and SuccessCount > 0
```

Walk through the query one line at a time:
1. **`SigninLogs`** — Selects the primary cloud identity authentication table.
2. **`| where TimeGenerated > ago(24h)`** — Constrains the time window first so the query engine scans only the last 24 hours of partitions.
3. **`| summarize FailedCount = countif(ResultType != "0"), SuccessCount = countif(ResultType == "0") by ...`** — Buckets events by user, source IP, and country code (`LocationDetails.countryOrRegion`), counting both authentication failures and successes in a single pass.
4. **`| where FailedCount > 5 and SuccessCount > 0`** — The behavioral tripwire: alerts only when a burst of failed attempts is followed by at least one successful sign-in (`ResultType == "0"`).

> **Facilitator Nuance Note:** Point out to your team that in a pure Adversary-in-the-Middle (AiTM) phishing capture where the attacker replays a stolen session token on the very first try (`FailedCount == 0, SuccessCount == 1`), a failure-threshold rule won't fire! To catch first-try AiTM logins, pair this rule with an impossible-travel or new-ASN/country anomaly query on `LocationDetails.countryOrRegion` and follow-on Exchange `New-InboxRule` detections (`CloudAppEvents`).

---

## Steal This Exercise for Your Team

Whether you are onboarding junior SOC analysts, running a 10-minute weekly detection engineering huddle, or guest-lecturing at a local university, you don't need an elaborate cyber range to teach threat-informed defense:

1. **Drop a 5-line story** grounded in real identity and mailbox telemetry.
2. **Use a simultaneous chat waterfall** so every analyst forms an independent hypothesis before seeing the room's consensus.
3. **Debrief the gray areas**—show why `T1114.003` (Collection) and `T1564.008` (Stealth `TA0045` in ATT&CK v19) can coexist on the same log event, and reward `"Insufficient Evidence"` whenever the data doesn't support a conclusion.
4. **Close with code**—never leave an ATT&CK mapping on a slide without showing the raw JSON log and the query that catches it.

If you're interested in how we enforce zero-trust verification gates across our own documentation and detection repositories, check out [Engineering a Zero-Trust Publishing Pipeline](/posts/engineering-a-zero-trust-publishing-pipeline/) or explore our [Active Defense & Canarytoken architecture](/series/acuity-health-security-architecture/part-5-active-defense-threat-hunting-canaries/).