Writing the Containment Ticket — From Report to Remediation

The investigation is finished when you’ve extracted every indicator and determined what happened. But the case isn’t closed until you’ve documented it, contained the threat, and handed off actionable items to engineering. The containment ticket is the artifact that makes investigation results permanent and actionable.

The Containment Ticket Format

Section 1: Classification

CLASSIFICATION
  Type:      Spear-phishing (T1566.002 — Spearphishing Link)
  Sub-type:  AiTM session capture (T1557) → BEC follow-on (T1534)
  Severity:  P1 — Active session compromise, financial fraud attempted
  Campaign:  Isolated / Part of campaign [specify if multiple targets]

Always include:

The most specific phishing taxonomy tier (not just “phishing”)
ATT&CK technique IDs for the full chain (not just the delivery technique)
Whether this appears isolated or part of a coordinated campaign

Section 2: Email Evidence

EMAIL EVIDENCE
  Sender:        "CFO Michael Torres" <mikes@corp-finance.net>
  Reply-To:      mikes@corp-finance.net (attacker-controlled)
  Subject:       Q3 Acquisition — Urgent Wire Authorization
  Delivered:     2024-08-14T09:14:22Z
  Recipients:    finance@corp.com, ap-team@corp.com (2 recipients)
  
  Authentication Results:
    SPF:   pass (corp-finance.net)
    DKIM:  pass (corp-finance.net)
    DMARC: fail (p=reject for corp.com — alignment failed, wrong domain)
  
  Lookalike domain: corp-finance.net (registered 2024-08-08, 6 days before delivery)
  Phishing URL:    https://secure-docs.corp-finance.net/view (AiTM proxy)
  URL sandbox:     URLScan.io scan confirmed: credential-harvest page, Microsoft 365 clone

Section 3: Victim Status

VICTIM STATUS
  Primary victim: jdoe@corp.com (Finance Analyst, no admin privileges)
  
  User interaction:
    [X] Email opened           (09:21 — read event in UAL)
    [X] Link clicked           (09:21 — browser proxy log)
    [X] Credentials entered    (09:21 — Entra ID sign-in from AiTM proxy IP)
    [X] MFA completed          (09:21 — MFA satisfied in sign-in log)
    [X] Session token stolen   (09:21 — second sign-in from 185.220.101.44, MFA pre-satisfied)
    [X] Attacker accessed mail (09:22–09:47 — MailItemsAccessed from 185.220.101.44)
    [X] Inbox rule created     (09:50 — deletes finance alert emails)
    [X] BEC sent by attacker   (09:51 — vendor account change email from victim's account)
    [ ] Wire transfer initiated (finance team not yet processed — confirm immediately)
    [ ] Secondary victims      (check if attacker sent further BEC from jdoe's account)

Being explicit about what happened vs. what has been confirmed vs. what is unverified avoids both under-escalation (“probably fine”) and over-escalation (“everything is compromised”).

Section 4: Technical Indicators

INDICATORS OF COMPROMISE
  Domains:
    corp-finance.net        (lookalike — attacker-registered 2024-08-08)
    secure-docs.corp-finance.net  (AiTM proxy subdomain)
  
  IP Addresses:
    185.220.101.44          (Tor exit node — attacker session access)
  
  Email:
    mikes@corp-finance.net  (attacker sender)
  
  URL:
    https://secure-docs.corp-finance.net/view
  
  User Agent (from sign-in log):
    Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... (generic — likely attacker's tool)
  
  No malware attachment — link-only delivery.

Section 5: Containment Actions

List every action in the order it was or should be performed. Mark completed vs. pending.

CONTAINMENT ACTIONS

[X] 1. Remove inbox rule (delete-finance-alerts rule removed 10:15Z — BEFORE victim notification)
[X] 2. Revoke all sessions for jdoe@corp.com (Entra ID → Revoke sessions — 10:17Z)
[X] 3. Email gateway: block sender corp-finance.net domain (quarantined all matching)
[X] 4. Search all mailboxes for emails from corp-finance.net → 1 additional recipient found
        → jsmith@corp.com received same email at 09:16, did not click (confirmed by phone)
[X] 5. Quarantine jsmith's copy of the email
[ ] 6. Force password reset for jdoe (pending MFA re-enrollment)
[ ] 7. Force MFA re-enrollment for jdoe (requires helpdesk ticket — pending)
[ ] 8. Check if BEC email (vendor account change) has been actioned by finance — URGENT
[ ] 9. URL block at proxy: secure-docs.corp-finance.net
[ ] 10. Threat intel share: IP 185.220.101.44, domain corp-finance.net → ISAC submission

Section 6: Escalation Assessment

ESCALATION ASSESSMENT

IR escalation threshold: MET

Reasons:
  - Active AiTM session compromise (attacker had active access for 25 minutes)
  - BEC attempt sent from compromised account (financial fraud attempt)
  - Wire transfer status unconfirmed (finance team must be contacted immediately)
  - Second recipient identified — scope assessment needed

Escalation actions:
  [X] Escalated to L2 (10:20Z)
  [X] Finance team contacted re: wire request (10:22Z)
  [ ] IR ticket opened for full scope assessment
  [ ] CISO notification (required for financial fraud incidents per IR policy)

Section 7: Open Items for Security Engineering

OPEN ITEMS — SECURITY ENGINEERING

1. DMARC enforcement: corp.com policy is p=quarantine — should be p=reject.
   Current policy allows lookalike-domain BEC to appear in inbox (not filtered).
   Request: upgrade to p=reject after testing. Owner: email-security team.

2. Detection rule gap: No alert fired on MailItemsAccessed from new IP within 30 min of phishing delivery.
   Request: create alert rule: MailItemsAccessed from IP not seen in last 30 days within 60 min of
   phishing email delivery to same user. Owner: detection team.

3. AiTM proxy indicator: IP 185.220.101.44 — add to threat intel blocklist.
   Domain corp-finance.net — add to email gateway blocklist.

4. Awareness: jdoe is enrolled in next phishing simulation. jsmith reported correctly (good outcome).
   Owner: security awareness team.

User Communication (Safe Harbor Notice)

TO: jdoe@corp.com
CHANNEL: Phone call (not email — mailbox was compromised)
TIMING: After session revocation and inbox rule removal

Content:
"We detected that a sophisticated phishing email was delivered to your mailbox today.
The email appeared to come from the CFO's address but was sent by an attacker.
We've already secured your account (revoked active sessions and removed a malicious rule).
You need to:
  1. Reset your password using the reset link we'll send to your personal email
  2. Re-enroll your MFA device with IT (we'll set up a call)
  3. Do not approve any wire transfers or payment changes until confirmed with the SOC

This was a highly targeted attack — you did nothing wrong. Many people would have clicked.
Please call us directly if you receive any follow-up emails about the vendor account change."

Worked Example

Complete ticket: generic phishing, no user interaction

Scenario: A user forwards a suspicious email to the phishing report mailbox. Email claims to be from Amazon about a failed delivery. Link goes to a credential-harvest page.

CLASSIFICATION
  Type: Generic phishing (T1566.002)
  Sub-type: Credential harvest — no indication of AiTM
  Severity: P3 — Email contained, no user interaction confirmed

EMAIL EVIDENCE
  Sender: noreply@amazon-delivery-notice.com (registered 2024-08-12, 2 days prior)
  Subject: Your Amazon package could not be delivered
  Recipients: 847 employees (mass distribution — HR listserv hit)
  Auth: SPF=pass (for amazon-delivery-notice.com), DKIM=pass, DMARC=fail (amazon.com)
  Phishing URL: https://amazon-delivery-notice.com/verify

VICTIM STATUS
  Reporter: jdoe@corp.com — forwarded without clicking (confirmed by proxy — no GET to URL)
  Other recipients: 846 checked via gateway search — 3 users clicked link
    mjones@corp.com: proxy log confirms GET to URL (09:44Z), no cred submission detected
    tsmith@corp.com: proxy log confirms GET to URL (09:51Z), no cred submission detected
    awong@corp.com: proxy log confirms GET AND POST to URL (10:02Z) — POSSIBLE CRED ENTRY

CONTAINMENT
[X] Email quarantined from all 847 mailboxes
[X] URL blocked at proxy
[X] Sender domain blocked at email gateway
[X] awong@corp.com: contacted by phone — confirmed entered credentials
    → Sessions revoked, password reset initiated (priority)
[ ] mjones, tsmith: monitor for suspicious activity (no cred submission detected)

ESCALATION: Not escalated — awong credential reset in progress, no further indicators

OPEN ITEMS
  Detection: No alert fired on mass delivery to HR listserv + new domain + DMARC fail.
  Request: alert rule for >50 recipients + domain age <30 days + DMARC fail.

Retrieval Practice

You've confirmed an AiTM compromise. List the containment actions in the correct sequence and explain why the order matters.

Reveal answer

Correct order: (1) Remove inbox rules — before anything else. If the attacker is watching via active session, removing rules prevents them from hiding the containment notifications; and if sessions are revoked first but the rule remains, containment emails to the victim get deleted. (2) Revoke all active sessions — kills the attacker's access. (3) Remove/quarantine the phishing email from all mailboxes — prevents other recipients from clicking. (4) Block sender domain and phishing URL at gateway and proxy. (5) Revoke any OAuth grants created during the compromise. (6) Force password reset AND MFA re-enrollment — both needed; password reset alone doesn't invalidate a stolen session, and MFA re-enrollment ensures the attacker can't use MFA push fatigue on the existing enrollment. (7) Notify victim via secondary channel (not email).

Retrieval Practice

After containment is complete, your containment ticket shows two open items: (1) DMARC policy is p=quarantine, not p=reject, and (2) no detection rule fired for MailItemsAccessed from a new IP. Who owns each open item and why does the distinction matter?

Reveal answer

(1) DMARC policy upgrade (p=quarantine → p=reject) is an email security / security engineering item. The SOC does not own email infrastructure configuration — this must be handed to the team that owns the email gateway and DNS. The SOC's job is to identify the gap and document the recommendation. (2) The detection rule gap (MailItemsAccessed from new IP) is a detection engineering item. Again, the SOC analyst identifies the gap but does not write the detection rule during incident response — that belongs to the detection engineer. The distinction matters because: if the SOC tries to own these items, they stay in the ticket as open forever. If they're explicitly handed off with an owner and a request, there's accountability. The ticket must name the receiving team and describe the specific gap.