Detecting and Mitigating Spearphishing Links for Information (T1598.003)

Spearphishing Link (T1598.003) is a sub-technique of Phishing for Information, in the reconnaissance tactic of MITRE ATT&CK. Its platform is PRE. The message carries a link, and the link leads to a place where the victim is asked for information, usually credentials.

This is the form of phishing most people picture: an email that asks you to sign in. The details are where it gets interesting, because the tricks have moved well past misspelled domains.

How attackers use it

MITRE says all forms of spearphishing are electronically delivered social engineering aimed at a specific individual, company or industry. Here, the emails contain links, usually with text that coaxes the user to click or to copy and paste a URL into a browser.

The destination may be a clone of a legitimate site, such as an online or corporate login portal. It may look close to a real site and have a URL that contains elements of the real one.

MITRE documents several variations.

URL obfuscation. URLs can be obscured by using quirks in the URL schema, such as the acceptance of integer or hexadecimal hostname formats and the automatic discarding of text before an at sign. MITRE's example is a defanged address that looks like a familiar domain followed by an at sign and a long number.

Tracking pixels. Adversaries may embed tracking pixels, web bugs or web beacons in messages to confirm that an email was received, and potentially to profile the victim, for example by IP address. They are often one-pixel images or other obscured objects delivered as HTML with a link to a remote server.

Browser-in-the-browser. Adversaries may spoof a whole website using a fake browser pop-up window with an HTML-based address bar that appears to hold a legitimate URL, such as an authentication portal. That lets them ask for credentials while sidestepping the usual habit of checking the URL.

Adversary-in-the-middle phishing. MITRE says phishing kits can proxy the connection between the victim and the legitimate website. After a successful login, the victim is sent on to the real site while the adversary captures the session cookie as well as the username and password. That can let them get past multi-factor authentication by using the web session cookie.

QR codes. Malicious links can also be delivered as QR codes, sometimes called quishing, which direct the victim to a credential phishing page.

The consistent theme is that visual checks stop working. MITRE's own mitigation text says homographs in ASCII and in internationalized domain names, plus URL schema obfuscation, can make manual checks difficult.

How to detect it

MITRE's detection advice covers email, browsers and the network.

Email:

• Look for suspicious email activity, such as numerous accounts receiving messages from one unusual or unknown sender.
• Use DKIM and SPF filtering or header analysis to spot spoofed senders.
• Use URL inspection in email, including expanding shortened links and identifying obfuscated URLs, to find links to known malicious sites.

Browser and network:

• Monitor for references to uncategorized or known-bad sites.
• Monitor browser logs for homographs, meaning ASCII or internationalized domain names that mix character sets, such as Cyrillic and Latin versions of a trusted site.
• Monitor network traffic for those homographs as well.
• Analyze traffic patterns and packet contents for protocols that do not follow expected standards, using SSL/TLS inspection for encrypted traffic where your policy allows it.
• Look at uncommon data flows, and treat processes that use the network but do not normally, or have never been seen doing so, as suspicious.

Two practical additions for the newer variants:

• A sign-in that succeeds from one location, followed shortly by use of the same session from another, is the shape of a stolen session cookie. Alert on it.
• Treat QR codes in email as links. Gateways that only scan text will miss them, so ask your email vendor whether images are inspected.

How to reduce the risk

MITRE lists two mitigations.

1. User Training. Train users to identify social engineering and spearphishing attempts. MITRE says visual checks of domains can help but may be hard because of homographs and URL obfuscation, so training should raise awareness to check URLs before visiting sites and, where possible, not rely on looking alone.
2. Software Configuration. Use anti-spoofing and email authentication, filtering on the sender domain with SPF and message integrity with DKIM. Enable these through policies such as DMARC so recipients, inside the organization and across domains, can do similar filtering and validation.

Because adversary-in-the-middle kits capture session cookies, a code sent by text message or app may not be enough on its own. That is an inference from how MITRE describes the technique, and it points toward sign-in methods that are tied to the real site. If your identity provider offers phishing-resistant options, prefer them for administrators and for anyone with access to sensitive systems.

Also set expectations for staff:

• Open sensitive sites from a bookmark or the app, not from a link in a message.
• Report the message even if you did not click. Reports let you remove the same message from every mailbox.

Check your own environment

Check SPF and DMARC for your domain (any OS with dig):

dig +short TXT your-domain.example
dig +short TXT _dmarc.your-domain.example

Then work through this list:

• Does your gateway expand shortened links and inspect URLs at delivery and again at click time?
• Can you search all mailboxes for one message and remove it quickly?
• Do browser or proxy logs flag lookalike domains with mixed character sets?
• Do you alert on one session cookie being used from two places?
• Is there a one-click way to report phishing?

Quick check

Sources

• MITRE ATT&CK, Spearphishing Link (T1598.003)