T1566.002 is a sub-technique of T1566 (Phishing) within the Initial Access tactic. Its defining characteristic — the use of a URL rather than an attached file — gives it distinct operational advantages over T1566.001. Attachment-based delivery is constrained at send time: once the email leaves the adversary's infrastructure, the payload is fixed. A link changes that equation. The destination server can serve different content to different visitors, swap the payload after the initial send, or simply return a benign page when accessed by automated scanners operating from known IP ranges — then redirect human victims from targeted organisations to the actual malicious content.
The technique has also expanded well beyond traditional credential harvesting pages and malware downloads. Modern variants abuse legitimate authentication infrastructure — OAuth consent flows, device authorization grant flows, and application-specific passwords — in ways that produce valid, platform-issued access tokens rather than stolen passwords. These tokens survive password resets, are difficult to attribute to phishing without deep audit log analysis, and grant API-level access to email, files, and cloud resources that perimeter controls are not designed to detect.
How Spearphishing Link Works
The adversary's first step is the same as in T1566.001: reconnaissance to build a convincing lure. Job title, organisational role, current projects, trusted vendors, and recent communications all feed into crafting an email that the target has a plausible reason to engage with. The difference is in the payload delivery mechanism.
Classic credential harvesting. The email contains a URL that leads to a login page mimicking a trusted service — Microsoft 365, Outlook Web Access, VPN portals, or cloud storage. The page captures credentials on submission and often redirects the victim to the legitimate service afterward to reduce suspicion. URL obfuscation is commonly applied to make the link appear trustworthy: IDN homograph attacks use Unicode characters that are visually identical to ASCII letters to create domains that look like legitimate brands at a glance. Other obfuscation methods exploit URL schema quirks — the automatic discarding of content before an @ symbol means a URL like https://google.com@malicious-host.net/page actually resolves to malicious-host.net, not Google.
Drive-by download and malware staging. The link leads directly to a file download — a ZIP, ISO, MSI, or script file — or to a page that exploits browser vulnerabilities to execute code without user interaction. This variant is particularly useful when the adversary wants to deliver a specific implant without any attachment scanning at the email gateway. Because the payload lives on a web server rather than the email, it can also be updated between the send time and the click time, and different visitor fingerprints can be served different files.
OAuth consent phishing. The link initiates an OAuth 2.0 authorisation request for a malicious application registered by the adversary. The target is presented with a legitimate-looking permission consent page — hosted on login.microsoftonline.com or accounts.google.com — and asked to grant the application access to email, calendar, files, or other cloud resources. When the target approves, the adversary receives an OAuth access token. This token provides persistent API-level access that survives password resets, does not require the victim's credentials to be captured, and generates audit log entries that look like routine application authorisation rather than a breach.
Device code phishing. This is a more recent and particularly effective variant. OAuth 2.0 includes a device authorization grant flow designed for devices without browsers — smart TVs, printers — that cannot perform standard interactive logins. The flow asks the user to visit a URL and enter a short code on a separate device to authenticate. Adversaries abuse this flow by sending targets a spearphishing link directing them to the legitimate microsoft.com/devicelogin page along with a code that the adversary has pre-generated. If the target enters the code, the adversary's session — not the target's — receives the authenticated token, granting full account access without the target ever entering a password on a fake page.
OAuth consent phishing and device code phishing both leverage legitimate authentication infrastructure. The victim visits a real Microsoft or Google domain, enters credentials or a code on a page with a valid TLS certificate, and receives no warning from their browser. Standard anti-phishing training that teaches users to check URLs and TLS indicators provides no protection against these variants.
Real-World Case Studies
APT29 GRAPELOADER — Diplomatic Lure Links (January 2025)
Check Point Research tracked a sustained APT29 (Midnight Blizzard) campaign beginning in January 2025 that targeted European ministries of foreign affairs and diplomatic missions. Spearphishing emails impersonated a major European foreign affairs ministry and delivered fake wine-tasting event invitations to diplomatic targets. Each email contained a malicious link that, depending on the visitor's profile, either redirected to the impersonated ministry's legitimate website (for automated scanners) or silently downloaded an archive deploying GRAPELOADER — a newly identified first-stage loader used for host fingerprinting, persistence, and delivery of the WINELOADER backdoor in later campaign stages. The server-side targeting logic — serving benign content to known security infrastructure while serving malicious payloads to profiled victims — exemplifies the operational advantage of link-based delivery over static attachments.
Storm-2372 and Russian Actors: Device Code Phishing at Scale (2025)
Beginning in August 2024 and continuing through early 2025, Microsoft documented a campaign by Storm-2372, a threat actor assessed to align with Russian state interests, targeting governments, NGOs, and multiple industry sectors using device code phishing. The campaign sent spearphishing emails with links to Microsoft productivity application authentication flows, capturing OAuth tokens when targets entered the device codes. Volexity independently tracked at least three Russian threat actor clusters — including activity attributed with medium confidence to APT29 — conducting similar device code phishing campaigns against Microsoft 365 accounts from mid-January 2025, with lure themes impersonating the US Department of State, the Ukrainian Ministry of Defence, and the European Parliament. One cluster coordinated the attack through Signal to establish rapport before sending the phishing link, ensuring targets were primed to enter the code within the 15-minute validity window of the device code. These campaigns were assessed to be more effective at compromising accounts than traditional credential harvesting phishing.
APT29 Watering Hole and Device Auth Abuse (August 2025)
In August 2025, AWS researchers documented an APT29 campaign that combined watering hole attacks with device code authentication abuse at a scale and sophistication level representing a notable evolution in the group's capabilities. The adversaries infected legitimate, high-traffic websites with obfuscated JavaScript that redirected approximately 10% of visitors — selected by browser fingerprinting to identify high-value targets — to Cloudflare verification page lookalikes or Microsoft login spoofs, ultimately directing them through the device authorization flow. The use of legitimate websites as initial redirect infrastructure, combined with Base64-encoded obfuscation and server-side visitor filtering, made the campaign significantly harder to detect than direct phishing infrastructure and was only uncovered through coordinated analysis between Amazon, Cloudflare, and Microsoft.
Detection Strategies
Detection for T1566.002 requires visibility at multiple layers: email delivery, click time, authentication events, and OAuth activity. The link-based nature of the technique means that scanning only the email body is insufficient — the malicious content does not exist in the email itself.
Splunk — Suspicious Post-Email Authentication and OAuth Events
# Correlate email delivery with authentication anomalies and OAuth grants
# Requires email gateway logs, Azure AD / Entra sign-in logs, and OAuth audit logs
index=azure_ad OR index=email_logs
| eval event_type=case(
sourcetype="email_gateway", "email_delivered",
sourcetype="azure_signin", "authentication",
sourcetype="azure_audit" AND Operation="Consent to application", "oauth_grant",
sourcetype="azure_audit" AND Operation="Add OAuth2PermissionGrant", "token_grant",
true(), "other"
)
| where event_type IN ("email_delivered","authentication","oauth_grant","token_grant")
| transaction user maxspan=30m maxpause=10m
| where eventcount > 1
AND mvcount(event_type) > 1
AND (match(mvjoin(event_type," "),"oauth_grant") OR match(mvjoin(event_type," "),"token_grant"))
| table user, event_type, src_ip, dest, _timeBehavioral Indicators
| Indicator | What It Means |
|---|---|
| Authentication event from new geography or IP within minutes of email delivery to that user | Click-time credential harvesting; the timing correlation between email receipt and subsequent login attempt from an unusual location is a high-signal indicator |
| OAuth application consent granted by a user for an unrecognised application | Consent phishing success; the granted application now has persistent API access to that user's cloud resources regardless of subsequent password changes |
| Device code authentication flow completed outside of expected device types or contexts | Device code phishing; microsoft.com/devicelogin visits from standard workstations with no corresponding device registration are anomalous |
| Proxy log showing a click to a domain registered within the past 30 days via a mail client process | Freshly registered infrastructure is the norm for targeted phishing campaigns; mail-client-initiated clicks to new domains warrant immediate investigation |
URL in email body containing @ before the domain, integer-format hostname, or Unicode lookalike characters |
IDN homograph or URL schema obfuscation; the visible portion of the URL does not represent the actual destination |
| Outbound connection to a legitimate cloud storage or file-sharing URL immediately generating a file download | Adversaries frequently stage payloads on Dropbox, Google Drive, or OneDrive to bypass reputation-based URL filtering; delivery via trusted cloud host is a documented evasion pattern |
Time-of-click URL rewriting — where the email gateway rewrites all links to route through a scanning proxy at click time rather than at delivery time — provides the single most impactful control for detecting and blocking link-based phishing after delivery. Microsoft Defender for Office 365 Safe Links and equivalent products in other email security platforms implement this. Without it, URL scanning at delivery time can be trivially bypassed by serving benign content to scanner IP ranges.
Known Threat Actors Using T1566.002
Link-based spearphishing is documented across a broad spectrum of tracked groups. The following represent consistently documented users with notable operational patterns.
- APT29 / Midnight Blizzard / Cozy Bear (Russia, SVR) — Sustained and evolving use of spearphishing links across multiple sub-techniques: GRAPELOADER diplomatic lure links (2025), device code phishing against M365 accounts (2024–2025), watering hole combined with device auth abuse (2025); targets European and US government, diplomatic, NGO, and academic sectors
- Storm-2372 (Russia-aligned) — Device code phishing campaigns against governments and NGOs worldwide from mid-2024 through 2025; assessed by Microsoft to align with Russian state interests
- APT40 / BRONZE MOHAWK (China, MSS) — Documented by CISA advisory AA21-200A using spearphishing links against maritime, defence, and government targets; links delivered malware loaders and credential harvesting pages
- Kimsuky (North Korea) — Persistent use of credential harvesting links against South Korean government officials, academics, think tanks, and journalists; frequently impersonates portals of specific government agencies relevant to the target
- MuddyWater (Iran, MOIS) — Targeted spearphishing emails with malicious links to cloud-hosted payloads and credential harvesting pages against organisations in the Middle East, Turkey, and Central Asia
- FIN7 (cybercriminal) — April 2024 campaign against US automotive industry used spearphishing links to deliver staged payloads; group has used link-based delivery alongside attachment-based methods across financial and retail sector campaigns
- LuminousMoth (China-linked) — Used Dropbox download links in spearphishing emails targeting government officials in Southeast Asia, routing delivery through a trusted cloud service to evade URL reputation filtering
Defensive Recommendations
- Enable time-of-click URL rewriting at the email gateway: Safe Links (Microsoft Defender for Office 365) and equivalent controls in Proofpoint, Mimecast, and similar platforms rewrite every URL in delivered email to route through a scanning proxy when clicked. This closes the window between email delivery and click time that server-side targeting exploits, and blocks access to domains that become malicious after delivery. This is the highest-priority control for T1566.002.
- Disable the OAuth device authorization grant flow where not operationally required: If your organisation does not deploy devices that require browserless authentication (printers, smart TVs, IoT), disable or restrict the device code flow for all users via Conditional Access policy in Microsoft Entra ID. This eliminates device code phishing as an attack vector with no impact on standard workstation and mobile users.
- Restrict OAuth application consent to verified publisher applications: Configure Entra ID or Google Workspace admin policies to block user-level consent to OAuth applications that are not verified publishers or that are not on an approved allowlist. Requiring admin approval for all consent grants prevents adversary-registered applications from obtaining tokens through phishing, even when a user clicks through a consent page.
- Monitor OAuth audit logs for anomalous application grants: Build SIEM alerting on consent grants to unrecognised or newly registered applications, especially those requesting broad scopes such as
Mail.Read,Files.ReadWrite, orfull_access_as_app. Correlate with email delivery timestamps — a consent grant within 30 minutes of a spearphishing email delivery is a high-confidence indicator of compromise. - Apply DMARC, DKIM, and SPF enforcement: Many link-based phishing campaigns rely on display-name spoofing or exact-domain spoofing that strict email authentication policies block. Enforce DMARC with a
p=rejectpolicy on your own domains to prevent impersonation, and configure your email gateway to reject or quarantine inbound mail that fails SPF and DKIM alignment checks. - Deploy phishing-resistant MFA: FIDO2 hardware security keys and passkeys are bound to the specific domain of the legitimate service and cannot be used on lookalike or proxied pages. This eliminates credential harvesting as a viable outcome even when the target clicks through to a spoofed login page. SMS and TOTP-based MFA remain vulnerable to real-time phishing proxies.
- Train users specifically on OAuth consent and device code flows: Standard phishing awareness training that focuses on checking URLs and TLS indicators provides limited protection against consent phishing and device code abuse — both of which occur on legitimate domains with valid certificates. Role-specific training should explain what OAuth consent prompts look like, why unsolicited device code requests are always suspicious, and how to report unexpected authentication prompts regardless of whether the URL appears legitimate.
MITRE ATT&CK Mapping
| Field | Value |
|---|---|
| Technique ID | T1566.002 |
| Technique Name | Phishing: Spearphishing Link |
| Parent Technique | T1566 Phishing |
| Tactic | Initial Access (TA0001) |
| Platforms | Identity Provider, Linux, macOS, Office Suite, SaaS, Windows |
| Data Sources | Application Log: Application Log Content; Network Traffic: Network Traffic Content; Network Traffic: Network Traffic Flow |
| Mitigations | M1049 Antivirus/Antimalware, M1031 Network Intrusion Prevention, M1021 Restrict Web-Based Content, M1054 Software Configuration, M1017 User Training |
| Version | 2.5 (Last Modified: October 24, 2025) |
| MITRE Reference | attack.mitre.org/techniques/T1566/002 |
Frequently Asked Questions
What is T1566.002 Spearphishing Link?
T1566.002 is a MITRE ATT&CK sub-technique under Initial Access in which adversaries send targeted emails containing malicious URLs that lead to credential harvesting pages, drive-by download sites, OAuth consent phishing flows, or device code authentication abuse — relying on the recipient clicking the link rather than opening an attached file.
How does spearphishing link differ from spearphishing attachment?
Spearphishing Link uses URLs embedded in email bodies to direct victims to malicious destinations, while Spearphishing Attachment delivers malicious files directly attached to the email. Link-based delivery bypasses email attachment scanning and allows adversaries to update or swap the destination payload after the email has been sent — an advantage that static attachments do not offer.
How can organizations detect spearphishing link attacks?
Detection relies on email gateway URL scanning with time-of-click rewriting, proxy logs flagging clicks to newly registered or uncategorised domains, monitoring for anomalous authentication events following email delivery, alerting on OAuth application consent grants from non-standard applications, and detecting device code authentication flows initiated from unusual source contexts.
Sources and References
- MITRE ATT&CK — T1566.002 Phishing: Spearphishing Link: attack.mitre.org
- Check Point Research — Renewed APT29 Phishing Campaign Against European Diplomats: research.checkpoint.com
- Volexity — Multiple Russian Threat Actors Targeting Microsoft Device Code Authentication: volexity.com
- Microsoft Security Blog — Storm-2372 conducts device code phishing campaign: microsoft.com
- Hack The Box — Dissecting APT29's obfuscated JavaScript watering hole campaign: hackthebox.com
- Microsoft Security Blog — Midnight Blizzard large-scale spear-phishing campaign using RDP files: microsoft.com