T1566 – Phishing

Phishing (T1566) is delivery through a deceptive message or interaction. ATT&CK currently separates spearphishing attachment, spearphishing link, spearphishing via service, and spearphishing voice.

For a hunter, the useful question is not merely Was this message phishing? It is What did the recipient, browser, identity, device, and cloud session do next?

• Tactic: Initial Access
• Sub-techniques:
  • T1566.001 – Spearphishing Attachment
  • T1566.002 – Spearphishing Link
  • T1566.003 – Spearphishing via Service
  • T1566.004 – Spearphishing Voice

References: RFC 7208, SPF , RFC 6376, DKIM , and RFC 7489, DMARC .

Separate the outcomes

A message can lead to very different investigations:

Avoid compressing these into a single severity label. The containment and evidence requirements differ.

Message evidence to preserve

• Original message and headers, not only a screenshot
• Sender, return path, reply-to, sending IP, RFC 5322 Message-ID / Microsoft InternetMessageId, provider-specific identifiers such as NetworkMessageId, and TeamsMessageId where applicable
• Recipient list, delivery action, delivery location, and post-delivery changes
• URLs as displayed and resolved, including redirects and Safe Links rewriting
• Attachment name, type, size, hashes, archive structure, and detonation result
• User report time and the user’s description of interaction
• Mail trace and copies sent to other recipients
• Threat-intelligence results with lookup timestamps

Do not submit private messages, URLs, attachments, or tokens to public services without checking disclosure and retention implications.

Investigation workflow

1. Reconstruct delivery

Determine whether the message was delivered, quarantined, removed later, forwarded, or never accepted. Search by stable identifiers such as network message ID, sender infrastructure, normalised URL, and attachment hash. Display names and subjects are useful but weak campaign keys.

2. Scope the campaign

Look for related recipients, sender domains, reply-to addresses, URL paths, redirects, attachment hashes, file names, sending IPs, and wording. Shared infrastructure can produce loose associations, so record why messages are considered related.

3. Establish interaction

A click record proves a redirect or URL interaction at a particular telemetry point; it does not always prove that the final page loaded or that the user entered data. Correlate browser, proxy, DNS, endpoint, and identity telemetry.

4. Follow identity activity

For suspected credential phishing, examine:

• Sign-ins before and after the interaction
• Source IP, ASN, geography, device, client, and authentication method
• MFA prompts and authentication-method changes
• New sessions, refresh-token use, device registration, and unfamiliar applications
• OAuth consent and delegated permissions
• Mailbox rules, forwarding, inbox access, and message deletion
• Access to cloud files, chats, and other high-value services

Travel, mobile networks, VPNs, proxies, and cloud egress can make location-based conclusions unreliable.

5. Follow endpoint activity

For attachments or downloads, correlate:

message or click
    -> browser, mail client, or archive utility
    -> file creation and extraction
    -> script interpreter or child process
    -> network connection
    -> persistence or follow-on behaviour

Office applications, browsers, PDF readers, archive tools, and collaboration clients have legitimate child processes. Focus on rare relationships, command lines, destinations, file prevalence, and what followed.

6. Preserve session evidence

If account compromise is plausible, password reset alone may not invalidate existing sessions, application passwords, OAuth grants, mailbox rules, or attacker-added authentication methods. Record the identity controls checked and the time they were changed.

Microsoft Defender XDR pivots

Common advanced-hunting tables include:

Reference: Microsoft Defender XDR advanced-hunting schema .

Schema availability varies by licensing, onboarding, workload, preview status, and retention. Inspect current records before writing a cross-table join. UrlClickEvents includes NetworkMessageId for supported email clicks, but Teams or Office clicks and incomplete records may require URL, account, workload, and time as alternative pivots.

A message-retrieval query can begin with a known message identifier:

let TargetMessageId = "KNOWN-NETWORK-MESSAGE-ID";
EmailEvents
| where Timestamp > ago(30d)
| where NetworkMessageId == TargetMessageId
| project Timestamp, NetworkMessageId, SenderFromAddress,
          SenderIPv4, RecipientEmailAddress,
          Subject, DeliveryAction, DeliveryLocation,
          ThreatTypes, DetectionMethods,
          AuthenticationDetails

Pivot from the retrieved message to sender infrastructure, URLs, attachment hashes, subjects, and recipient patterns to determine campaign scope. Then follow click, post-delivery, endpoint, and identity evidence. Do not use a placeholder query as a detection without validating local fields.

Useful hunt patterns

• One URL or attachment reaching several unrelated departments
• A trusted but rarely seen sender followed by a new sign-in pattern
• Click followed by MFA changes, OAuth consent, or mailbox forwarding
• Archive attachment followed by script or interpreter execution
• Reply-to domain differing from the visible sender in a new relationship
• Messages removed post-delivery after one or more recipients interacted
• A conversation thread changing beneficiary, bank details, or reply path
• Voice contact followed by remote-support software or account recovery

Each pattern has ordinary explanations. The point is to locate the evidence chain that distinguishes them.

Reporting the conclusion

A defensible case note might say:

• Observed: the message was delivered to three recipients; one clicked the rewritten URL.
• Observed: the same identity signed in from a new ASN 11 minutes later and created a forwarding rule.
• Assessment: the sequence strongly supports credential phishing followed by mailbox access.
• Caveat: endpoint telemetry did not confirm whether the final page rendered.
• Scope: no equivalent sign-in or rule activity was found for the other recipients during the reviewed period.

Revision