AD5.4 Reading the Attack Story

Worked example: reading a phishing incident

Here's a real-world-style incident you might see in your Monday review:

Incident name: "Email messages containing phishing URLs removed after delivery" Severity: Medium Alerts: 2 — "Phishing email detected post-delivery" + "URL click blocked by Safe Links" Entities: User: r.williams@northgateeng.com, Email: from "Microsoft Support" <support-verify@ms-account-check.com>

Reading the story — the 4 questions:

1. What happened? A phishing email was delivered to r.williams. The email contained a URL that was clean at delivery time but was later identified as a phishing page. Defender retroactively flagged the email (ZAP) and Safe Links blocked a click.

1. Who is affected? r.williams — check the Assets tab. Is r.williams a real active user? Yes. Are there other users who received the same email? Check by clicking the email entity → "Other recipients." If 5 other users received it, the scope is broader.

1. Was it blocked? Partially. The email was delivered initially (not blocked at delivery). ZAP removed it retroactively. Safe Links blocked r.williams' click — the warning page was shown. But there's a window between delivery and ZAP removal where the email was in the inbox. Did r.williams interact with it before removal?

1. What do I do? Check whether r.williams clicked the URL BEFORE Safe Links classified it (check the URL trace timeline). If the click happened before classification and the user reached the phishing page, treat as a potential credential compromise — check the sign-in log for r.williams, look for unusual sign-ins. If Safe Links blocked the click (which the alert says it did), r.williams is safe. Check for other recipients who may have clicked before the block. Classify the incident based on the outcome: if all clicks were blocked, classify as TP (the attack was real but blocked). If any user reached the phishing page, investigate further.

The timeline is everything

The most important element of the attack story is the timeline — the sequence of events with timestamps. In the Defender incident, the timeline shows:

• 09:14 — Phishing email delivered to r.williams
• 09:47 — Microsoft reclassifies URL as phishing (33-minute gap)
• 09:52 — ZAP removes email from inbox
• 10:03 — r.williams clicks URL from Outlook mobile notification (email was already removed from inbox, but the notification still contained the link)
• 10:03 — Safe Links blocks the click, shows warning page

The timeline reveals a nuance: the email was removed from the inbox by ZAP at 09:52, but the Outlook mobile notification (which was already pushed at 09:14) still contained the link. r.williams clicked the link from the notification, not from the inbox. Safe Links caught it regardless — but this shows why click-time scanning (Safe Links) is essential even when ZAP removes the email.

This level of timeline reading is what distinguishes "I checked the incident queue" from "I understand what happened." For most Monday reviews, the 4-question framework is sufficient. For medium and high-severity incidents, reading the timeline tells you the full story and informs the correct response.

Entity investigation shortcuts

When you need to investigate an entity (user, device, IP) further, the Defender portal provides quick investigation links:

For a user: Click the user entity → "Go to user page." This shows: recent sign-in activity, risk level, devices used, incidents involving this user, and timeline of alerts. This is faster than navigating to Entra ID separately.

For an email: Click the email entity → "Open email page." This shows: sender analysis, recipient list, attachment details, URL analysis, and delivery action. You can take action from here: quarantine, delete, or investigate further.

For an IP address: Click the IP entity → the portal shows geolocation, reputation, and other incidents associated with this IP. A known-malicious IP appears with a red warning. An unknown IP needs manual investigation (whois lookup, geolocation check).

These entity investigation shortcuts keep you in the Defender portal instead of switching between 3-4 different portals. The unified portal is designed for exactly this workflow: incident → entity → investigation → response, all in one window.

Worked example: credential compromise attack story

Here's a more complex attack story you might encounter:

Incident name: "Suspicious sign-in activity followed by inbox manipulation" Severity: High Alerts: 3 — "Atypical travel" + "Suspicious inbox forwarding rule" + "Email delivered containing credential harvesting link" Timeline:

• Monday 23:47 — Phishing email delivered to m.thompson (the original compromise vector)
• Tuesday 01:15 — Suspicious sign-in from IP 198.51.100.22 (Eastern Europe), MFA satisfied by claim
• Tuesday 01:17 — New inbox rule created: forward emails matching "invoice|payment|wire" to ext.account@proton.me
• Tuesday 01:22 — Mail read activity: 47 emails opened in the user's inbox
• Tuesday 01:25 — Atypical travel alert fires (London → Eastern Europe in 8 hours)

Reading the story: The phishing email (alert 3) was the initial access vector — m.thompson likely clicked the credential harvesting link and entered their password on the phishing page, which also captured the session token (AiTM). 3.5 hours later, the attacker replayed the captured token (alert 1 — the sign-in shows "MFA satisfied by claim"). Within 2 minutes of sign-in, the attacker created a BEC forwarding rule (alert 2) targeting financial communications. The attacker then read 47 emails — likely scanning for active invoices or payment requests they could intercept.

The critical evidence: Open the Evidence and response tab. Check whether the forwarding rule is still active (if so, disable it immediately via Exchange admin). Check message trace: were any emails forwarded to ext.account@proton.me BEFORE you deleted the rule? If yes, those emails are in the attacker's hands — identify which emails were forwarded and what data they contained.

Response: This is a confirmed TP requiring full AD1.9 execution plus vendor notification. The attacker has read 47 emails and may have received forwarded financial communications. Contact any vendors or clients whose invoices were forwarded — they may receive fraudulent payment redirect requests using information from the stolen emails.

This example demonstrates why the timeline matters: each alert in isolation looks different (atypical travel, inbox rule, phishing email), but the timeline connects them into a single attack chain. The Defender portal's correlation engine put all three alerts into one incident because the same user is involved — saving you from investigating three separate events.

When reviewing multi-alert incidents, always check whether the alerts are genuinely related or coincidentally correlated. The correlation engine groups alerts by shared entities (users, devices, IPs). Sometimes two unrelated events affecting the same user are grouped: a legitimate travel trigger and an unrelated DLP match. Read each alert's timeline independently before assuming they're part of the same attack chain. If the timestamps and activities don't connect logically, they may be coincidental — investigate each alert on its own merits before treating them as a unified attack.