Most phishing and drive-by attacks need one thing from the victim: a click on a URL, and the URL itself often carries the evidence that it is hostile. MITRE D3FEND names this countermeasure URL Analysis (D3-UA) and defines it as "Determining if a URL is benign or malicious by analyzing the URL or its components." It sits under the Detect tactic as a child of Identifier Analysis (D3-ID), alongside Homoglyph Detection, Identifier Activity Analysis and Identifier Reputation Analysis. This card explains what D3-UA analyses, which ATT&CK techniques D3FEND relates it to, where it runs, how to verify it and where it fails. It is written for email security, web security and detection engineering teams; user-facing advice on spotting bad links is in Phishing links.
Key takeaways
- The URL is a feature set. D3FEND lists scheme, userinfo, host name, port, path, query and fragment as components used as features in analysis algorithms, together with context such as where the URL was embedded.
- Content mismatch is a strong signal. D3FEND's own example: a URL that indicates a .pdf file but returns an executable is suspicious, which is why URL analysis often triggers follow-on file analysis.
- The mapping is to link-borne initial access. Through the URL artefact, D3FEND relates D3-UA to Drive-by Compromise (T1189), Malicious Link (T1204.001), Spearphishing Link (T1566.002) and Spearphishing via Service (T1566.003).
- Time of click beats time of delivery. Attackers weaponise links after delivery, so analysis at click time, as well as at delivery, is what catches delayed payloads.
- New domains are the hard case. D3FEND's considerations name volume, speed and fidelity on brand new URLs as the limits, which is where lexical and content analysis must stand in for reputation.
D3-UA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-UA (d3f:URLAnalysis) |
| Tactic | Detect |
| Parent technique | Identifier Analysis (D3-ID) |
| Digital artefact | URL (D3FEND relation: analyzes) |
| Sibling techniques | Homoglyph Detection (D3-HD), Identifier Activity Analysis (D3-IAA), Identifier Reputation Analysis (D3-IRA) |
| D3FEND references | Patents from Endgame (detecting malicious websites) and Sophos (detecting restricted content associated with retrieved content) |
| Where it runs | Email gateways and cloud email security, secure web gateways and DNS or proxy filters, browsers, endpoint protection, SIEM analytics |
| Main limitation | New, clean-looking URLs and redirect chains that only turn hostile later or for some visitors |
How it works
RFC 3986 (Internet Standard STD 66) defines the generic URI syntax that D3-UA takes apart: scheme, authority made of optional userinfo, host and optional port, then path, query and fragment. Its example foo://example.com:8042/over/there?name=ferret#nose shows each part. The RFC also warns, in section 3.2.1, that userinfo can be "misleadingly crafted to look like a trusted domain name", one of the oldest URL tricks. D3FEND groups the analysis methods into three families.
Lexical and structural features
D3FEND names features such as domain name length, the ratio of consecutive consonants, the percentage of digits in a domain and the number of vowels, combined into a score. It also describes a character probability model: the probability of each character given the two before it, learned from a list of known good domains, multiplied into a score. Algorithmically generated and random-looking domains score badly. Other practical structural signals include userinfo present in a web URL, raw IP addresses as hosts, unusual ports, very long or deeply encoded query strings and brand names in the path or subdomain rather than the registered domain.
Context of the URL
Where the URL was found (email body, attachment, chat, QR code, file, network protocol), the headers and origin of the message that carried it and the location and path all feed the analytic. A link to a file-sharing service in a message from a first-time external sender carries different weight from the same link in an internal wiki.
Content returned
Fetching the URL in a controlled environment and comparing what comes back with what the URL implies catches mismatches: a .pdf link returning an executable, a "document" page that is a credential form, or a redirect chain ending on a newly registered domain. This is where URL analysis hands over to file analysis and sandboxing.
Reputation lookups belong to the sibling D3-URA URL Reputation Analysis, and lookalike characters to Homoglyph Detection. In practice products combine them, but D3FEND keeps the analysis of the URL itself separate from reputation lists.
ATT&CK techniques D3FEND relates to D3-UA
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-UA. The rows below are inferred because D3-UA analyzes the URL artefact and these ATT&CK techniques produce or access URLs in the D3FEND ontology; the D3FEND site labels them inferred and experimental (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Shared artefact (D3FEND relation) | What URL analysis can catch |
|---|---|---|---|
| T1189 | Drive-by Compromise | URL (produces) | Redirects to exploit or malware delivery pages from compromised or malvertising sites |
| T1204.001 | Malicious Link | URL (accesses) | Click-time checks on the link the user is about to open |
| T1566.002 | Spearphishing Link | URL (produces) | Credential harvesting and payload links in email, analysed at delivery and at click |
| T1566.003 | Spearphishing via Service | URL (produces) | Links sent through social media, chat or collaboration services outside the mail gateway |
D3FEND's ICS view also relates URL to Drive-by Compromise in ATT&CK for ICS (T0817). Technique detail is in MITRE ATT&CK T1189 Drive-by Compromise, T1204 User Execution and MITRE ATT&CK T1566 Phishing.
Where it is implemented
Product classes are listed alphabetically; the named features are examples from vendor documentation, not recommendations.
| Implementation class | Example feature (from vendor docs) | When the URL is analysed | Covers |
|---|---|---|---|
| Browser and URL lookup services | Google Safe Browsing Lookup API v4: the threatMatches.find method checks up to 500 URLs per request against Safe Browsing lists identified by threat type, platform type and threat entry type | At navigation or on demand | Known malicious URLs; lexical and content checks must be added separately |
| Email security with click-time protection | Microsoft Defender for Office 365 Safe Links: URL rewriting in email, time-of-click checks in email, Teams and Office apps, "Apply real-time URL scanning for suspicious links and links that point to files" and "Wait for URL scanning to complete before delivering the message"; click events in the UrlClickEvents advanced hunting table | At delivery and at click | Spearphishing Link; Teams coverage reaches part of Spearphishing via Service |
| Secure web gateway and DNS filtering | URL categorisation, newly registered domain policies and content inspection on the proxy | At request time for every user and workload | Drive-by Compromise and any link opened from any channel |
| SIEM and detection analytics | Scoring URLs from proxy, DNS and email logs with lexical features and joins to click and download events | After the event, for hunting and correlation | Gaps between controls, retro-hunting when a URL turns bad |
For gateway design and policy see the Secure Web Gateway and Web Filtering Guide; for mail-side controls see the Email Security Guide.
Implementation steps
- Inventory the channels. List where URLs reach users and workloads: email, chat and collaboration tools, SMS and mobile, QR codes, documents, browsers, and automated fetchers such as AI agents and integration services.
- Turn on click-time analysis. Enable time-of-click checks for email, chat and office documents, and set the policy to hold messages until URL scanning completes where your platform offers it.
- Route all web traffic through analysis. Make sure managed devices, servers and remote users all reach the internet through a gateway or DNS filter, so links opened from unscanned channels are still analysed.
- Add lexical and content scoring in the SIEM. Score URLs from proxy and DNS logs with structural features (userinfo, IP hosts, digit ratio, length, brand terms outside the registered domain) and join them to click and download events.
- Keep exceptions narrow. Use exact host and path entries in "do not rewrite" or allow lists. Microsoft's Safe Links documentation, for example, notes that
contoso.comcovers only that host while*.contoso.com/*covers subdomains and paths, so wide wildcards silently exclude a lot. - Close the loop. When a URL is confirmed malicious, search click logs for everyone who opened it, block it at the gateway, and feed it to reputation lists. The Phishing Incident Response Playbook covers the response steps.
- Roll back safely. If a new policy blocks business links, add an exact exception and record it with an owner and expiry rather than switching off scanning.
How to verify it works
- Safe test URLs: use the test pages provided by your filtering or browser vendor, or an internal test domain, to confirm each channel (email, chat, browser, server egress) blocks or warns and logs the event.
- Delayed weaponisation test: with approval, send a link to an internal test page that is benign at delivery and changed afterwards, and confirm time-of-click analysis catches it.
- Lexical rule tests: feed a set of crafted, harmless URLs (userinfo, IP hosts, long encoded queries, brand words in subdomains) through the SIEM scoring and confirm expected scores.
- Phishing simulation data: check that simulated phishing clicks appear in click logs with user and device, proving the telemetry exists for real investigations.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Channels with click-time or request-time URL analysis | All channels in the inventory | Unscanned channels are the bypass |
| Test URLs blocked or warned per channel | All quarterly tests | Proves coverage end to end |
| Time from confirmed bad URL to block and retro-search | Under one hour | Limits the number of further clicks |
| Allow list and no-rewrite entries with owner and expiry | 100% | Stops exceptions becoming permanent holes |
| User-reported phishing URLs already blocked at report time | Tracked monthly | Shows how often analysis is ahead of users |
Limits, bypasses and failure patterns
- Brand new domains: D3FEND names fidelity on brand new URLs as a consideration. In the Twilio Breach 2022, SMS links pointed to lookalike domains such as twilio-sso.com and twilio-okta.com; brand words outside the real registered domain are exactly the lexical signal URL analysis should score, and SMS was a channel outside the email gateway.
- Channels that bypass the gateway: SMS, personal messaging and QR codes reach users without passing email scanning. See the QR Code Phishing (Quishing) Guide.
- Cloaking and conditional content: pages that show benign content to scanners and hostile content to targets defeat content analysis that runs once from a known scanner address.
- Trusted platforms as hosts: links to legitimate file-sharing, form and document services inherit good reputation; only path, context and content analysis help.
- Over-broad exceptions: wildcard allow entries for partner or marketing domains exclude whole subdomain trees from analysis.
- Automated fetchers left out: integration services and AI agents that open URLs on behalf of users often egress directly; give them the same gateway path and log their fetches.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-8 Spam Protection, SI-3 Malicious Code Protection | Mail and content scanning that carry URL analysis |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Web gateways and filtering at the boundary |
| NIST SP 800-53 Rev 5 | SC-44 Detonation Chambers | Controlled fetching and analysis of URL content |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | SIEM scoring and retro-hunting |
| NIST CSF 2.0 | DE.CM-01, DE.CM-09, DE.AE-02 | Monitoring networks and software for adverse events; analysing them |
| MITRE D3FEND | D3-ID, D3-UA | Parent and technique |
Practitioner checklist
- Inventory every channel through which URLs reach users and workloads.
- Enable time-of-click analysis for email, chat and office documents.
- Hold messages until URL scanning completes where supported.
- Send all web egress, including servers and automated fetchers, through a gateway or DNS filter.
- Score URLs in the SIEM with structural features and join them to click events.
- Keep allow and no-rewrite lists exact, owned and time-limited.
- Retro-search click logs whenever a URL is confirmed malicious.
- Test each channel quarterly with safe test URLs.
Standards and references
- MITRE D3FEND: URL Analysis (D3-UA)
- IETF: RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
- MITRE ATT&CK: T1566.002 Spearphishing Link
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-44, SI-8)
- Microsoft Learn: Safe Links in Microsoft Defender for Office 365
- Google for Developers: Safe Browsing Lookup API (v4)
Related NHI Mgmt Group resources: Phishing Guide · Secure Web Gateway and Web Filtering Guide · Email Security Guide · D3-URA URL Reputation Analysis · MITRE D3FEND Guide