Spearphishing Link: Detecting Malicious Links in Mail (T1566.002)

A link is harder to filter than an attachment, because the dangerous part lives on a web page the gateway may never see. MITRE T1566.002, Spearphishing Link, covers emails that contain links to malware or to pages built to steal access. It is an initial access technique for Windows, Linux, macOS, Office Suite, SaaS and identity provider environments.

How attackers use it

MITRE explains that, unlike the attachment variant, the email contains a link instead of a file. That helps avoid defenses that inspect attachments. The message is paired with social engineering text, and usually requires the user to click or copy and paste the URL into a browser, which relies on User Execution.

What happens next varies. The site may try to exploit the browser, or it may prompt the user to download an application, document, zip file or executable, depending on the pretext.

MITRE lists several variations:

• Links aimed at the email reader itself, including embedded images meant to exploit the end system.
• Look-alike sites built from special characters, known as IDN homograph attacks.
• URL tricks that use quirks in the URL format, such as integer or hexadecimal host names, and the way text before an at sign is discarded. MITRE's defanged example is hxxp://google.com@1157586937.
• Consent phishing, where a link sends the user to a legitimate sign-in page that asks them to grant a malicious application access. No password is stolen, but the application receives a token.

How to detect it

MITRE's detection chain is a malicious URL in an email, then a user click recorded in logs, then a browser that starts unusual child processes or downloads.

By platform:

• Windows: click recorded in Office logs, then the browser starting PowerShell or cmd, or download activity.
• Linux: mail logs and proxy logs show the click, then a shell or interpreter launches from the browser process.
• macOS: Mail.app logs correlated with Safari or Chrome access to newly registered or lookalike domains, then osascript or Terminal started unexpectedly.
• OAuth: an inbound email with an OAuth URL, a consent page visited, then unusual token grants in identity provider logs.

Proxy logs are the workhorse here. Newly registered domains and lookalikes of your own brand are common ingredients, and a click from a mail client followed by a download is a strong pairing.

How to reduce the risk

MITRE lists five mitigations.

1. Software Configuration. Use SPF and DKIM and enforce them with DMARC so recipients can check sender domains and message integrity.
2. Restrict Web-Based Content. Decide whether certain websites used for spearphishing are necessary for business. Block them if activity cannot be monitored well or poses a significant risk.
3. Audit. Review applications and their permissions so access is limited to what is necessary.
4. User Account Management. For Azure AD, restrict the ability of users to grant consent to unfamiliar or unverified third-party applications.
5. User Training. Teach users to spot social engineering, including consent phishing. MITRE adds that visual checks of domains are hard because of homographs and URL tricks, and suggests email warning banners for external mail.

The consent control matters most for SaaS-heavy companies. Set a policy so that users cannot approve any application on their own, and route requests through an admin.

Check your own environment

• Can users approve third-party application consent without review? Check the setting in your identity provider.
• List current application grants and look for anything unfamiliar with broad mail or file access.
• Are links rewritten or detonated at the gateway, and can you search by clicked URL?
• Do you alert on newly registered domains in proxy logs?
• Do external emails carry a banner?

A read-only check on your sender policy:

dig +short TXT _dmarc.example.com

Investigating a click

Start from the URL. Find every recipient, every click and every download. Check whether the page asked for credentials or an application grant. If it was a grant, revoke it and review the token's activity. If it was credentials, reset them, revoke sessions and check for new mailbox rules. If it was a download, work from the endpoint chain: browser, child process, network.

Why training alone is not enough

MITRE says that visual checks may fail against homographs and URL schema obfuscation. That is a good argument for design choices that do not rely on people: link rewriting, domain age rules, consent restrictions and phishing-resistant sign-in methods. Training still matters for what to do next, which is to report.

Quick check

Sources

• MITRE ATT&CK T1566.002, Spearphishing Link