Overview

Spearphishing Link (T1566.002) is a targeted email attack where adversaries send carefully crafted messages containing malicious URLs to specific individuals. When the recipient clicks the link, they may be directed to a site that delivers malware, harvests credentials, triggers a browser exploit, or tricks the user into granting OAuth consent to a malicious application — giving the attacker an initial foothold inside the environment.

This technique is one of the most common initial access vectors across ransomware, espionage, and business email compromise campaigns, making it a mandatory detection priority for every security team. Because it exploits human behaviour rather than a technical vulnerability, purely preventive controls will fail — detection must catch the moment a malicious link is clicked and the downstream activity that follows.

Attacker Perspective

Attackers use spearphishing links because they bypass attachment-scanning defences while still delivering a payload, and the required user action — clicking a URL — is completely normal behaviour that blends into everyday traffic.

• Malware delivery via file-hosting redirect: The email contains a link to a legitimate-looking SharePoint or OneDrive URL that immediately redirects to an attacker-controlled host serving an ISO, ZIP, or LNK dropper — a technique heavily used by groups like TA577 and QBot operators. Example pattern: hxxps://sharepoint-login[.]co/download?token=abc123 redirecting to a raw payload URL.
• OAuth consent phishing: The link is a crafted OAuth 2.0 authorization URL (e.g., targeting Microsoft or Google) that requests Mail.ReadWrite, Files.ReadWrite.All, or similar high-privilege scopes. When the user approves, the attacker receives a long-lived access token without needing the user’s password.
• Credential harvesting via adversary-in-the-middle (AiTM) proxy: Tools like Evilginx2 or Modlishka serve a pixel-perfect reverse proxy of the victim’s login portal. The link leads the user to the fake portal, which captures both the password and the session cookie in real time, defeating MFA.
• IDN homograph / URL obfuscation: The link uses a lookalike domain (microsоft.com using Cyrillic ‘о’) or an integer-encoded host (hxxp://google.com@1157586937) to evade visual inspection and some URL reputation filters, landing the user on a browser-exploit or credential-harvest page.

The technique is attractive because it requires zero-day exploits only optionally, is cheap to execute at scale with targeted personalisation, and the initial malicious action (clicking a link) leaves minimal forensic evidence compared to a weaponised attachment.

Detection Strategy

Required Telemetry

• Email gateway / MTA logs: Enable full header logging on your email security platform (Microsoft Defender for Office 365, Proofpoint, Mimecast, or Google Workspace Gmail logs). Capture sender address, reply-to, subject, all URLs extracted from the body, click-time URL rewrite outcomes, and delivery verdict. In Microsoft 365, ensure Unified Audit Log is enabled and the UrlClickEvents table is populated in Defender for Endpoint / Microsoft Sentinel.
• DNS query logs: Enable DNS logging at the resolver level. On Windows domain controllers, enable DNS Analytical logging (Event ID 3008 for client queries) via dnscmd /config /loglevel 0x8100, or deploy a DNS sinkhole/RPZ solution (e.g., Infoblox, Pi-hole with logging). On Linux, configure systemd-resolved or bind query logging. In cloud environments, enable VPC/Azure DNS query logging.
• Web proxy / firewall HTTP logs: All outbound HTTP/HTTPS requests must be logged with full URL (not just domain), referrer, user-agent, response code, and bytes transferred. Require TLS inspection for non-corporate-managed certificate authorities so payload downloads over HTTPS are visible. Tools: Zscaler, Palo Alto Threat Prevention, Squid proxy with full URL logging enabled.
• Endpoint process creation (Windows): Enable Audit Process Creation via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation = Success. This generates Event ID 4688. Additionally enable command-line logging: GPO path Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events = Enabled. Alternatively, deploy Sysmon with a baseline config (SwiftOnSecurity or Florian Roth); Sysmon Event ID 1 provides richer parent-child-commandline data including hashes.
• Endpoint network connections (Windows): Sysmon Event ID 3 (Network Connection) logs process-to-IP/domain mappings. Enable via Sysmon config with <NetworkConnect onmatch="include"> rules targeting browsers and Office processes. Alternatively, Windows Filtering Platform events 5156 (Audit Filtering Platform Connection = Success/Failure via Advanced Audit Policy).
• Endpoint file creation (Windows): Sysmon Event ID 11 (FileCreate) and Event ID 15 (FileCreateStreamHash — captures Alternate Data Streams, critical for Mark-of-the-Web / Zone.Identifier tracking). Enable in Sysmon config targeting %USERPROFILE%\Downloads, %TEMP%, and browser cache paths.
• Browser telemetry / MOTW: Files downloaded from the internet receive a Zone.Identifier ADS with ZoneId=3. Sysmon Event ID 15 captures this. This is the single most reliable signal that a file arrived via browser click rather than internal file copy.
• Linux / macOS endpoint: On Linux, deploy auditd with rules: -a always,exit -F arch=b64 -S execve -k process_execution and -w /home -p wa -k home_writes. On macOS, enable Endpoint Security Framework (ESF) via an EDR agent (CrowdStrike, SentinelOne, or osquery with the process_events and socket_events tables). Capture browser child process spawning and file writes to ~/Downloads.
• Identity / OAuth logs: For Microsoft 365, enable Unified Audit Log and monitor Add OAuth2PermissionGrant and Consent to application operations. For Entra ID (Azure AD), enable Sign-in logs and Audit logs in Diagnostic Settings, streaming to your SIEM. For Google Workspace, enable Admin SDK Reports API and capture token activity events.
• EDR telemetry: If available (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne), prioritise EDR over raw event log collection — EDR agents provide enriched parent-child process trees, pre-built IOC matching, and network connection context that significantly accelerates investigation.

Key Indicators

• Browser spawning an unusual child process: Log source: Sysmon Event ID 1 / Windows Event ID 4688. Field: ParentImage = chrome.exe, msedge.exe, firefox.exe, iexplore.exe, opera.exe. Child Image matches: cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, certutil.exe, curl.exe, or msiexec.exe. This indicates a drive-by or file-open-from-download scenario.
• Office application spawning a script interpreter: Log source: Sysmon Event ID 1. Field: ParentImage contains WINWORD.EXE, EXCEL.EXE, OUTLOOK.EXE, or POWERPNT.EXE; child Image = powershell.exe, cmd.exe, mshta.exe, or wscript.exe. This covers malicious Office documents downloaded via the phishing link.
• Suspicious file download with MOTW: Log source: Sysmon Event ID 15 (FileCreateStreamHash). Field: Contents contains ZoneId=3. File extension in: .exe, .dll, .iso, .lnk, .hta, .js, .vbs, .zip, .msi. Path contains \Downloads\ or \Temp\. This directly links a browser download to a potentially executable payload.
• DNS resolution of newly registered or uncategorised domain: Log source: DNS query logs / web proxy logs. Field: query_name or url_domain where domain age < 30 days (enriched via WHOIS API or threat intel platform), or proxy category = Uncategorized / Unknown. Particularly suspicious when initiated by chrome.exe, msedge.exe, or outlook.exe.
• URL click event on a rewritten / safelinks URL that resolves to a low-reputation domain: Log source: Microsoft Defender for Office 365 UrlClickEvents table (or equivalent from Proofpoint/Mimecast click logs). Field: ActionType = ClickAllowed or ClickBlocked; IsClickedThrough = 1; ThreatTypes is not null. A click-through on a blocked URL is an immediate high-priority indicator.
• OAuth consent grant to an unverified application: Log source: Entra ID Audit Logs / Unified Audit Log. Operation = Consent to application or Add OAuth2PermissionGrant. Fields: TargetResources[*].displayName is an unfamiliar app name; AdditionalDetails[*].value contains high-privilege scopes such as Mail.ReadWrite, Files.ReadWrite.All, or offline_access. Publisher domain is unverified (publisherDomain lacks a blue verified badge).
• certutil or bitsadmin used to download files: Log source: Sysmon Event ID 1 / Windows Event ID 4688. Field: CommandLine contains certutil -urlcache, certutil -decode, or bitsadmin /transfer. These are living-off-the-land download techniques commonly triggered from a malicious link payload.
• PowerShell encoded command or download cradle: Log source: PowerShell Script Block Logging (enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1, generates Event ID 4104). Field: ScriptBlockText contains IEX, Invoke-Expression, DownloadString, DownloadFile, WebClient, Net.WebClient, or -EncodedCommand combined with Base64-looking strings.
• Abnormal network connection from an Office or browser process: Log source: Sysmon Event ID 3. Fields: Image = WINWORD.EXE or powershell.exe; DestinationPort = 443 or 80; DestinationIp not in known-good CDN or Microsoft IP range. Direct Office-to-internet connections that bypass the proxy are suspicious.

Detection Logic

Rule 1 (Broad — high sensitivity): Email link click followed by suspicious file download
IF email_gateway.event_type = "url_click" AND email_gateway.click_action = "allowed" AND proxy_log.url_domain NOT IN known_good_domains AND proxy_log.response_content_type IN ("application/octet-stream","application/zip","application/x-msdownload","application/x-msi") AND time_delta(email_click, proxy_request) < 300 seconds THEN alert priority=HIGH

This catches the most common kill chain: user clicks a link in email, and within five minutes a binary or archive is downloaded from an uncategorised or unknown domain. Expect moderate volume in environments without URL rewriting; tune by adding a proxy category exclusion for known software distribution CDNs like dl.google.com or download.microsoft.com.

Rule 2 (Medium — balanced): Browser or Office process spawning a script interpreter
IF process.parent_image IN ("chrome.exe","msedge.exe","firefox.exe","WINWORD.EXE","EXCEL.EXE","OUTLOOK.EXE") AND process.image IN ("powershell.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe","certutil.exe") AND NOT process.command_line MATCHES known_good_patterns THEN alert priority=HIGH

This rule directly targets execution that follows a link click or document open, catching drive-by browser exploits and malicious macro/embedded content. Volume should be low in a typical enterprise; tune by building an allowlist of command_line patterns for known software updaters that legitimately spawn cmd.exe from Chrome (e.g., Google Update).

Rule 3 (Medium — OAuth consent phishing): High-privilege OAuth grant from unverified app
IF identity_log.operation IN ("Consent to application","Add OAuth2PermissionGrant") AND identity_log.app_publisher_verified = false AND identity_log.granted_scopes CONTAINS_ANY ("Mail.ReadWrite","Files.ReadWrite.All","offline_access","Calendars.ReadWrite","MailboxSettings.ReadWrite") THEN alert priority=HIGH

This directly catches consent phishing campaigns. False positive volume is very low — legitimate enterprise apps granted high-privilege scopes should be pre-approved and registered in your application inventory; any unknown app triggering this rule warrants immediate investigation.

Rule 4 (Narrow — high precision): PowerShell download cradle with internet parent
IF powershell_scriptblock.event_id = 4104 AND powershell_scriptblock.script_text MATCHES_REGEX "(IEX|Invoke-Expression).*(Net\.WebClient|DownloadString|DownloadFile|WebRequest)" AND process.parent_image IN ("chrome.exe","msedge.exe","WINWORD.EXE","EXCEL.EXE","wscript.exe","mshta.exe") THEN alert priority=CRITICAL

This is a near-zero false-positive rule. A PowerShell download cradle invoked directly from a browser or Office application is a confirmed malicious execution chain. Alert volume will be very low — treat every hit as a confirmed incident until proven otherwise.

Tuning Guidance

• Software deployment tools spawning cmd.exe or powershell.exe: SCCM, Intune, and similar management platforms legitimately cause svchost.exe or management agent processes to spawn script interpreters. Exclude by adding parent_image IN ("CCMExec.exe","IntuneManagementExtension.exe","MicrosoftEdgeUpdate.exe") to process-spawn rules, and verify by correlating with deployment schedules.
• Legitimate software updates downloading executables via browser: Chrome, Firefox, and Electron apps regularly download update binaries that trigger file-download rules. Exclude known update CDN domains such as dl.google.com, update.googleapis.com, download.mozilla.org, and aka.ms from proxy-based download detections.
• IT and developer users running PowerShell web requests: Administrators and developers legitimately use Invoke-WebRequest and DownloadFile. Scope Rule 4 tightly to browser and Office parent processes rather than excluding users — the parent process constraint is the critical differentiator. If needed, add user NOT IN privileged_admin_group as a secondary filter but do not rely on it alone.
• Approved OAuth applications triggering the consent rule: Internal or vendor SaaS integrations that are legitimately granted high scopes will fire Rule 3 on first consent. Build and maintain an approved_app_id allowlist in your SIEM lookup table and add AND app_id NOT IN approved_app_ids to the rule. Review the list quarterly.
• Security awareness phishing simulation platforms: Tools like KnowBe4 or Proofpoint Security Awareness Training send simulated phishing links that will trigger email click and URL reputation rules. Add your vendor's sending IP ranges and URL domains (available in their admin portal) to a phishing_simulation_exclusion lookup and suppress alerts for those sources.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Pull the raw event from its source log — for an email click alert, query the UrlClickEvents table in Defender for Office 365 (or your gateway's click log) and confirm the NetworkMessageId, timestamp, recipient UPN, and destination URL are present and match the alert. Do not proceed on a correlated alert alone until the raw event is confirmed.
2. Identify the affected host and user: Map the recipient email address to a hostname and user account in your directory (Active Directory, Entra ID, or LDAP). Use your SIEM to check if the account has elevated roles — Domain Admin, Global Admin, Exchange Admin, or service account membership — and escalate immediately if so, as the blast radius is significantly larger.
3. Pull the full command-line and parent process chain: In your EDR console or Sysmon logs (Event ID 1), search for process creation events on the affected host within ±30 minutes of the click time. Build the full parent-child tree: confirm whether the browser or email client spawned any child process, and extract the full CommandLine, Image, ParentImage, User, and file hash (SHA256) for every suspicious child process.
4. Check for network connections and files written to disk: Query Sysmon Event ID 3 (network connections) and Event ID 11/15 (file creation and stream hash) for the affected host in the same time window. Note every external IP or domain contacted by the browser or any spawned process, and identify every file written to %USERPROFILE%\Downloads, %TEMP%, or %APPDATA%. Submit file hashes to VirusTotal or your threat intel platform, and look up IPs/domains in your TIP for known C2 infrastructure.
5. Look for lateral movement from this host: Search Windows Security Event ID 4624 (logon) and 4648 (explicit credentials) on neighbouring hosts, filtering for SubjectUserName matching the affected user and LogonType 3 (network) or 10 (RemoteInteractive). In your SIEM, run a query for SMB, RDP, WMI, or PsExec activity originating from the affected host's IP within the 2 hours following the initial click event.
6. Search for persistence mechanisms added: On the affected host, query Sysmon Event ID 12/13 (registry key creation/modification) for paths under HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\Software\Microsoft\Windows\CurrentVersion\Run, and HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Also query Windows Event ID 4698 (scheduled task created) and check Sysmon Event ID 11 for new files in %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup.
7. Escalation decision: Escalate to a confirmed incident and invoke your IR process if any of the following are true: a child process was spawned from a browser or Office app, a file with a MOTW Zone.Identifier of ZoneId=3 was executed, a PowerShell download cradle was observed, an OAuth consent grant was made to an unverified app, or lateral movement events exist. If the investigation shows only a URL click with no downstream execution and no payload delivery, document the event as a phishing attempt with no compromise and close with tuning notes.

Response Playbook

Containment

• Isolate the affected host from the network immediately, but leave it powered on. In your EDR console (CrowdStrike: Network Containment; Defender for Endpoint: Isolate Device; SentinelOne: Network Quarantine), apply network isolation. Keeping the host powered on preserves volatile memory, running processes, and open network connections for forensic collection.
• Disable the affected user account in Active Directory or Entra ID. In Active Directory: Disable-ADAccount -Identity username. In Entra ID: navigate to Users → select user → Edit → Account status = Disabled. This prevents the attacker from reusing the account for lateral movement while investigation continues.
• Revoke all active sessions and tokens for the affected account. In Entra ID: Users → select user → Revoke Sessions. For Microsoft 365: Revoke-AzureADUserAllRefreshToken -ObjectId <user_object_id>. If an OAuth grant was made to a malicious application, remove it immediately: Entra ID → Enterprise Applications → find the app → Delete, and run Remove-MgOAuth2PermissionGrant via Microsoft Graph PowerShell.
• Block identified malicious domains and IPs at the perimeter. Add C2 domains and IPs identified in step 4 of investigation to your firewall deny list, DNS RPZ sinkhole, and web proxy block list. In Microsoft 365 Defender, add the malicious URL to the Tenant Block List (Policies → Threat Policies → Tenant Allow/Block Lists → URLs).
• Kill any active malicious processes on the host. If EDR isolation has not already terminated them, use your EDR's remote kill process capability, or if you have a live-response shell: taskkill /F /PID <pid> for identified malicious processes. Document the PID, image name, and command line before terminating.

Eradication

• Remove all identified persistence mechanisms. Delete registry Run key entries added by the malware (reg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v <malware_entry> /f). Remove any malicious scheduled tasks identified in Event ID 4698 (schtasks /delete /tn "<task_name>" /f). Delete any startup folder entries. Document each one removed.
• Delete all dropped payloads and tools identified during investigation. Use your EDR's file remediation capability or manually delete files identified via Sysmon Event ID 11/15 from download and temp directories. Run a hash-based scan across the environment using your EDR (deploy a custom IOC hunt using the SHA256 hashes collected) to find the same payload on other hosts.
• Reset credentials for the affected user and any accounts whose credentials may have been captured. Force a password reset for the affected user. If AiTM or credential harvesting is suspected, also rotate credentials for any shared accounts or service accounts the user had access to. Notify the user directly (out-of-band, not via email) before re-enabling their account.
• Audit and remediate lateral movement targets. For every host where the affected user authenticated after the initial compromise time, repeat the persistence check (registry, scheduled tasks, startup items) and run an EDR hunt for the same payload hashes. Treat any host with a positive match as a separate compromised endpoint.
• Rotate any secrets, API keys, or tokens that may have been exposed. If the user had access to secrets managers, cloud consoles, or CI/CD pipelines, audit and rotate all associated API keys and service principal credentials. Check your cloud provider's IAM audit logs for any API calls made using the user's cloud credentials since the compromise time.

Recovery

• Verify the host is clean before reconnecting it to the network. Run a full EDR scan and confirm zero active threats. If confidence in the cleanliness of the host is low — particularly if the malware ran with elevated privileges, if any persistence mechanism was confirmed, or if the dwell time exceeded a few hours — re-image the endpoint from a known-good baseline rather than attempting to clean it in place.
• Re-enable the user account only after all persistence has been confirmed removed and credentials have been reset. Coordinate the account re-enable with the user's manager and confirm the user has received security awareness guidance specific to the phishing technique used against them.
• Monitor the previously affected host and user account for 72 hours post-remediation. Create a temporary high-sensitivity detection rule in your SIEM scoped to the affected host and user — alert on any process execution, network connection, or authentication event that would normally be below your alerting threshold. Assign a dedicated analyst to review these alerts daily for the monitoring period.
• Document the full incident timeline and close with lessons learned. Record the initial email receipt time, click time, first malicious execution, containment time, and erad