MITRE ATT&CK T1566 Phishing: Detection Logic, Log Sources and Identity Controls

Phishing is still the most common way into an organisation, and today the payload is as likely to be a session, an OAuth grant or an approved MFA prompt as a malware file. MITRE ATT&CK tracks the technique as T1566 Phishing in the Initial Access tactic (TA0001), with four sub-techniques covering attachments, links, third-party services and voice calls. This guide works through T1566 as it stands in ATT&CK v20 (technique version 2.8), turns each detection strategy into concrete log sources and correlation logic, and shows where identity controls decide whether a clicked link becomes a breach. It is written for detection engineers, email and identity administrators and SOC leads. For awareness material and the wider defence programme, start with the Phishing Guide; this page goes deeper on detection.

Key takeaways

• Four routes, one tactic. T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service and T1566.004 Spearphishing Voice all deliver the lure; what follows is usually User Execution (T1204) or Valid Accounts (T1078).
• The identity provider is now a primary target. ATT&CK v20 lists Identity Provider, Office Suite and SaaS as T1566 platforms, and its analytics include OAuth consent grants and MFA anomalies after delivery, not just process trees.
• Detect the chain, not the email. Every ATT&CK analytic for T1566 is a correlation: message delivered, then a click, file write or call, then an unusual process, sign-in or grant. Single-signal email alerts drown the SOC.
• Phishing-resistant authentication changes the outcome. Passkeys and FIDO2 bound to the real origin stop credential relay; consent restrictions stop illicit grants. Filtering and training reduce volume but never reach zero.
• Measure time to contain. Track how quickly a reported or detected message is purged from all mailboxes and how quickly affected sessions and tokens are revoked.

How T1566 works in ATT&CK v20

ATT&CK describes phishing as electronically delivered social engineering, targeted (spearphishing) or untargeted (mass malspam). It names thread hijacking, calendar invites, social media and callback lures that tell the victim to phone a number and install a remote management tool. It also notes evasive tradecraft such as T1684.002 Email Spoofing and T1564.008 Email Hiding Rules on compromised senders, both now in the v20 Stealth tactic.

ATT&CK v20 lists a long roster of groups using T1566, including APT28 (G0007), APT29 (G0016), Lazarus Group (G0032), Sandworm Team (G0034) and FIN7 (G0046). Mobile phishing such as SMS sits in a separate mobile matrix entry, T1660 Phishing. The reconnaissance variant, where the goal is information rather than access, is T1598 Phishing for Information, and phishing sent from an already compromised internal account is T1534 Internal Spearphishing.

Detection logic and log sources

ATT&CK v20 maps a detection strategy to T1566 itself and one to each sub-technique, with analytics per platform. The table condenses them into what to collect and what to correlate. Window lengths are starting points to tune, not ATT&CK values.

High-value signals specific to email platforms

• Click telemetry: in Microsoft Defender for Office 365, Safe Links click tracking writes to the advanced hunting table UrlClickEvents; join it to sign-in logs by user and time to find clicks that led to a sign-in from a new location.
• Post-delivery verdict changes: messages reclassified as phishing after delivery tell you who received a lure that the gateway let through. Use those recipients to scope the hunt.
• Mailbox rules created after a click: new inbox rules that move or delete messages, or forward externally, are the T1564.008 follow-up and a reliable compromise indicator.
• Internal sends: a sudden burst of messages with the same link from one internal account points to T1534 and a compromised mailbox.

Prevention controls mapped to ATT&CK mitigations

In Microsoft 365, anti-phishing policies offer user impersonation protection (up to 350 users per policy), domain impersonation protection, mailbox intelligence and phishing email thresholds from 1 Standard to 4 Most aggressive. Impersonation actions default to doing nothing, so set them to quarantine for protected executives and finance staff. Safe Links rewrites inbound email URLs and rechecks them at click time; Teams links are checked at click without rewriting. Keep the option to let users click through to the original URL switched off, and audit the do-not-rewrite list, because entries there skip mail-flow scanning. See the DMARC, SPF and DKIM Guide for sender authentication.

Where identity fits

The modern phishing objective is an identity artefact: a password plus a relayed one-time code, a session cookie, an OAuth refresh token or a help desk reset. That is why the strongest T1566 control sits in the identity layer, not the mail filter.

• Phishing-resistant MFA: FIDO2 security keys and passkeys are bound to the origin, so a proxy page on a lookalike domain cannot obtain a usable assertion. In the Twilio breach, an SMS lure sent staff to fake Okta pages that relayed one-time codes in real time; Twilio moved to FIDO2 keys afterwards. See the Phishing-Resistant MFA Guide.
• Session and token theft: AiTM kits capture the session after MFA succeeds. Bind sessions to devices where supported and keep revocation fast. See the AiTM Phishing Guide.
• OAuth consent: a consent lure needs no password at all. Restrict user consent and alert on grants of mail, file and offline access scopes. See the Consent Phishing and Illicit OAuth Grants Guide.
• Voice and the help desk: in the Cisco 2022 breach the attacker combined vishing calls with repeated push requests until an employee approved one, then enrolled new MFA devices. Verify callers out of band and alert on MFA registration after any reset.
• Non-human identities: phished developers and administrators often hold API keys, cloud access keys and CI tokens. Treat any confirmed phish of a privileged or engineering user as a possible secrets exposure and rotate what their sessions could reach.

How to implement

1. Baseline telemetry (weeks 1 to 2): confirm message trace, URL click events, endpoint process and DNS telemetry, and IdP sign-in and audit logs all reach the SIEM with a common user identifier.
2. Harden authentication of senders (weeks 1 to 4): move DMARC from p=none to quarantine then reject, monitoring aggregate reports at each step; roll back a step if legitimate senders fail.
3. Tighten filtering in rings: apply stricter anti-phishing thresholds and impersonation protection to a pilot group, measure false positives in quarantine for two weeks, then extend. Keep the previous policy for rapid rollback.
4. Close identity gaps: restrict user consent, enable admin consent workflow, and enforce phishing-resistant MFA first for administrators, finance and help desk staff.
5. Deploy correlation rules: start with three: attachment to child process, click to new-location sign-in, and click to consent grant. Run them in alert-only mode and tune before paging on them.
6. Wire up response: automate search and purge across mailboxes, session and refresh token revocation, and password reset for confirmed clickers. Follow the Phishing Incident Response Playbook.
7. Close the loop with users: a report button feeding a triage queue, with feedback to the reporter. See the Phishing Report Button and User Reported Message Triage Guide.

Decision guidance

• Gateway versus API-based email security: a secure email gateway in the MX path can block before delivery; API-based tools see internal mail and can purge after delivery. Large organisations often run both; small ones usually get most value from tuning the platform's built-in protection.
• Block or warn on risky attachments: block container and script formats outright unless a business process needs them; warn on macros only where macros from the internet are already blocked by policy.
• Training versus engineering spend: training reduces click rates but cannot stop a well-made lure. If budget forces a choice, phishing-resistant MFA for privileged users removes more risk than another simulation cycle.
• Small organisations: enable the preset strict or standard policies, enforce DMARC, use passkeys where the IdP supports them and turn on click logging. Correlation rules can wait.

Detection and measurement

• Mean time to purge: from first report or detection to removal from all mailboxes; target under 30 minutes.
• Click-to-revocation time: from a confirmed credential or token compromise to sessions revoked.
• Report rate versus click rate: in simulations and real campaigns, the share of recipients who report against those who click.
• Phishing-resistant MFA coverage: percentage of privileged and high-risk users who can only sign in with FIDO2 or passkeys.
• Post-delivery catches: number of malicious messages found after delivery, a measure of filter gaps and hunting value.
• Unapproved consent grants: count per month, trending to zero after consent restriction.

Common failure patterns

• Treating MFA as phishing-proof: SMS, voice and push codes can be relayed or approved under pressure, as the Twilio and Cisco incidents show.
• Allow-list sprawl: broad sender allow lists and do-not-rewrite URL entries added to fix one complaint, which then carry lures straight to inboxes.
• Email-only scope: no detection for Teams, Slack or LinkedIn lures, so T1566.003 goes unseen.
• Password reset without token revocation: the attacker keeps the stolen session or refresh token after the password changes.
• Help desk resets on caller say-so: no callback or manager verification for MFA resets, which turns T1566.004 into account takeover.
• No link from email alert to identity logs: the SOC closes the phishing alert without checking whether the recipient signed in from somewhere new.

Framework mapping

Practitioner checklist

• DMARC at p=reject on all sending domains, with parked domains also protected.
• Impersonation protection set to quarantine for executives, finance and help desk.
• Click logging on, click-through off, and the URL do-not-rewrite list reviewed quarterly.
• Container and script attachment types blocked at the gateway.
• User consent restricted and an admin consent workflow in place.
• Phishing-resistant MFA enforced for privileged and high-risk users.
• Correlation rules live for attachment to process, click to sign-in and click to consent.
• Automated purge plus session and token revocation tested in the last quarter.
• Help desk callback verification for any MFA or password reset.

Standards and references

• MITRE ATT&CK: Phishing (T1566)
• MITRE ATT&CK: Spearphishing Link (T1566.002)
• MITRE ATT&CK: Spearphishing Voice (T1566.004)
• CISA, NSA, FBI and MS-ISAC: Phishing Guidance, Stopping the Attack Cycle at Phase One
• Microsoft Learn: Anti-phishing policies in Microsoft 365
• Microsoft Learn: Safe Links in Microsoft Defender for Office 365
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Phishing Guide, Top 10 Phishing Techniques, Callback Phishing (TOAD) Guide, MITRE ATT&CK T1528 Steal Application Access Token Guide, Top 10 Identity Attacks.