Most phishing and drive-by attacks still need a person or a program to fetch a URL, and checking that URL against what is already known about it is one of the cheapest detections a defender can run. MITRE D3FEND names this countermeasure URL Reputation Analysis (D3-URA) and defines it in one line: "Analyzing the reputation of a URL." It sits under the Detect tactic as a child of Identifier Reputation Analysis, next to Domain Name Reputation Analysis, IP Reputation Analysis and File Hash Reputation Analysis. This card covers what D3-URA does, which ATT&CK techniques D3FEND relates it to, where the check runs in a real estate (mail, browser, proxy, DNS and SIEM enrichment), how to prove it fires, and where it fails. It is written for detection engineers and email and web security owners who want more than the definition.
Key takeaways
- It is a lookup, not an analysis of the page. D3-URA asks "what is already known about this URL?" Inspecting the URL's structure or the content behind it is a different D3FEND technique, URL Analysis (D3-UA).
- D3FEND relates it to link-borne initial access. The D3FEND site lists inferred relations through the URL artefact to Malicious Link (T1204.001), Spearphishing Link (T1566.002) and Spearphishing via Service (T1566.003) and Drive-by Compromise (T1189).
- Where you check decides what you catch. A check at mail delivery misses a URL that turns malicious an hour later; a check at click time or at the proxy catches it. Mature estates check at more than one point.
- New URLs have no reputation. Attackers rotate fresh domains and paths faster than lists update, so treat "unknown" as a risk signal, not as "clean".
- Verify with safe test URLs. Add a harmless internal test URL to your own block list (or use a test page your provider documents); a scheduled click on it per enforcement point proves the block and the log both work.
D3-URA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-URA (d3f:URLReputationAnalysis) |
| Tactic | Detect |
| Parent technique | Identifier Reputation Analysis (D3-IRA) |
| Definition | "Analyzing the reputation of a URL." |
| Digital artefact | URL (D3FEND relation: analyzes URL) |
| D3FEND reference | Patent US8839418B2, "Finding phishing sites" (also cited for Domain Name and IP Reputation Analysis) |
| Typical inputs | URLs in email bodies and attachments, chat messages, documents, browser navigation, proxy and DNS logs |
| Typical outputs | Verdict (malicious, suspicious, unknown, clean), category, threat type, cache lifetime, block or warning page |
| Main limitation | Only knows what has already been seen and reported somewhere |
D3FEND has no "How it works" or "Considerations" article for D3-URA (D3FEND knowledge graph 1.6.0, checked November 2026). The practical sections below are NHI Mgmt Group's guidance, built from the product documentation cited.
How it works
Every implementation follows the same three steps.
- Extract: pull URLs out of the object being inspected: a message body, a QR code image, an attachment, a chat message, an HTTP request or a DNS query (where only the hostname is visible).
- Look up: compare the URL, or a canonicalised form or hash of it, with one or more reputation sources. These are commercial threat intelligence, a vendor's own telemetry, public feeds and your own block and allow lists.
- Act: block, warn, rewrite the link for a later check, hold the message, or simply enrich an alert with the verdict.
Two design choices matter most.
- Privacy of the lookup: sending full URLs to a cloud service can leak internal links, tokens in query strings and personal data. Google's Safe Browsing API v5 documentation describes a hash-based search where the client computes SHA256 hashes locally and sends only a 4-byte hash prefix, and it notes that the plain
urls.searchmethod has no URL confidentiality. - Caching: verdicts are cached for speed. The Safe Browsing Lookup API returns a
cacheDurationtelling the client how long a match must be treated as unsafe. A cached "clean" verdict is the gap attackers use when they arm a link after delivery.
ATT&CK techniques D3FEND relates to D3-URA
Relationship type: inferred only. D3FEND lists these relations as inferred and experimental, derived through the shared URL artefact (D3FEND 1.6.0, checked November 2026). They show where a reputation check can see the attack, not that it stops it.
| ATT&CK ID | Technique | D3FEND relation | What a reputation check can catch |
|---|---|---|---|
| T1566.002 | Spearphishing Link | Inferred: analyzes URL | A link in an email that points to a known phishing kit or credential harvesting page |
| T1566.003 | Spearphishing via Service | Inferred: analyzes URL | Links sent through chat, social media or collaboration tools, where the email gateway never sees them |
| T1204.001 | Malicious Link | Inferred: analyzes URL | The click itself, at browser, endpoint or proxy level |
| T1189 | Drive-by Compromise | Inferred: analyzes URL (T1189 produces URL) | Navigation to a known compromised or exploit-hosting site, including through redirects |
Each ID was checked against ATT&CK v20. For the attacker side of these techniques, see the MITRE ATT&CK T1566 Phishing, T1204 User Execution and MITRE ATT&CK T1189 Drive-by Compromise pages.
Where it is implemented
| Enforcement point | When the check runs | Strength | Blind spot |
|---|---|---|---|
| Email security gateway or cloud mail filter | At delivery, sometimes again at click through link rewriting | Stops the message before a user sees it | Links armed after delivery unless time-of-click checks run |
| Browser protection | At navigation and download | Covers links from any source, including chat and documents | Unmanaged browsers and devices |
| Secure web gateway or proxy | On each HTTP request | Central policy and logs for every managed device routed through it | Traffic that bypasses the proxy; full path visibility needs TLS inspection |
| Protective DNS resolver | On name resolution | Cheap, wide coverage, works for servers and IoT | Sees only the hostname, so a malicious path on a legitimate host passes (that is domain reputation, D3-DNRA) |
| SIEM or SOAR enrichment | After the event, during triage | Adds verdicts to alerts and hunts retrospectively | Detects, does not block |
Example platform features follow, listed alphabetically by publisher. Naming them explains the mechanism; it is not a recommendation.
- abuse.ch URLhaus: a community project sharing URLs used for malware distribution. It offers a query API, database dumps, a DNS Response Policy Zone (RPZ), a hosts file, a plain-text URL list and Snort/Suricata rules. Downloads need a free Auth-Key; commercial users may need the paid API under its terms.
- Google Safe Browsing: an API that checks URLs against Google's lists of unsafe resources (social engineering and malware sites). The v4 Lookup API accepts up to 500 URLs per
threatMatches:findrequest with threat types such asMALWAREandSOCIAL_ENGINEERING; v5 adds hash-prefix search and Real-Time and Local List modes. - Microsoft Defender: SmartScreen in Windows checks visited sites against a dynamic list of reported phishing and malware sites and evaluates URL reputation; it is managed through Group Policy or Intune. Safe Links in Defender for Office 365 rewrites email URLs and checks them at click time in email, Teams and supported Office apps. Policy settings include "Apply real-time URL scanning for suspicious links and links that point to files", "Wait for URL scanning to complete before delivering the message" and "Let users click through to the original URL".
Feature design and licence requirements change; confirm settings against each publisher's current documentation. Wider choices for web and mail controls are in the Secure Web Gateway and Web Filtering Guide, the Protective DNS Guide and the Email Security Guide.
Implementation steps
- Map the link paths. List every way a URL reaches a user or a system: email, chat and collaboration tools, documents, SMS and QR codes, browser bookmarks, automated jobs that fetch URLs (webhooks, CI pipelines, AI agents with browsing tools). Each path needs at least one check.
- Turn on time-of-click checks in mail. Delivery-time scanning alone is not enough. Enable link rewriting or an API-based click check, and decide whether users may click through a warning (the safer choice is no).
- Cover the browser and the network. Enforce browser protection by policy on managed devices, and route web traffic through a proxy or protective DNS so links from chat or personal mail are also checked.
- Feed your own intelligence back. Add URLs from confirmed incidents and user reports to your block list within minutes, and remove stale allow-list entries on a schedule. An allow list that grows forever becomes the bypass.
- Enrich alerts. Add reputation verdicts to proxy, DNS and email events in the SIEM, and keep the raw URL so a URL that turns malicious later can be hunted retrospectively.
- Pilot, then enforce. Start in warn or log-only mode for one group for two weeks, review false positives (often marketing trackers and newly registered partner domains), then switch to block. Roll back by returning the policy to warn mode, not by disabling it.
Where identity fits
Link-based phishing is mainly a credential theft problem: the URL leads to a fake sign-in page or an adversary-in-the-middle proxy that steals the session. A reputation block helps, but phishing-resistant authentication is what makes a stolen password or a proxied sign-in useless. See the AiTM Phishing Guide and Consent Phishing and Illicit OAuth Grants Guide. Non-human callers matter too: an AI agent or integration that fetches URLs on instruction should go through the same proxy and reputation checks as a person, because it can be steered to an attacker's page by prompt injection.
How to verify it works
- Synthetic click test: monthly, from a managed test device, open your internal test URL (a harmless page you have placed on the block list) or a provider-documented test page through every enforcement point (mail link, browser, proxy, DNS). Confirm the block page appears and the event reaches the SIEM with user, device and verdict.
- Time-of-click test: send a test message whose link is benign at delivery and is then pointed at a test URL. If no warning appears at click, the estate relies on delivery-time scanning only.
- Bypass path test: try the same test URL from a chat tool, a document and an unmanaged browser profile. Each path that is not blocked is a coverage gap to record.
- Retro-hunt test: take URLs from a recent public report and search 30 days of proxy and DNS logs. If you cannot answer "did anyone visit this?", logging is the gap.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Enforcement points passing the monthly test URL check | 100% | Proves block and log work end to end |
| Share of user-reported phishing URLs already blocked when reported | Rising quarter on quarter | Shows how fresh the reputation sources are |
| Time from confirmed malicious URL to local block | Under 30 minutes | Limits exposure for the rest of the campaign |
| Warning click-through rate | Near zero, or click-through disabled | A warning users ignore is not a control |
| Allow-list entries older than 12 months | Reviewed and justified | Stale allow lists are a standing bypass |
Limits, bypasses and failure patterns
- Fresh infrastructure: new domains, new paths and one-time links have no history. Pair D3-URA with URL Analysis (D3-UA) and newly registered domain controls.
- Trusted hosting: phishing pages on reputable cloud storage, form builders or document sharing services inherit the host's good reputation. Path-level reputation and content inspection are needed there.
- Delayed arming: a link that is clean at delivery and malicious at click passes any check that runs only once.
- Cloaking: pages that show benign content to scanners (by IP, user agent or geolocation) and the payload to targets defeat crawl-based reputation building.
- Channels without checks: QR codes in images, SMS, personal webmail and chat apps outside the managed estate never reach the gateway.
- Broad allow lists: a wildcard entry such as a whole file-sharing domain, added to stop one false positive, exempts every malicious page hosted there.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE D3FEND | D3-IRA, D3-URA | Parent and technique |
| MITRE ATT&CK mitigations | M1021 Restrict Web-Based Content, M1017 User Training | Blocking known-bad sites; teaching users to report links |
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection, SI-4 System Monitoring, SC-7 Boundary Protection | Scanning at entry points, monitoring web traffic, filtering at the boundary |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Monitoring networks for adverse events; analysing them |
The control-side detail is in M1021 Restrict Web-Based Content and M1017 User Training.
Related countermeasures
- Identifier Reputation Analysis (D3-IRA): the parent technique. See D3-IRA Identifier Reputation Analysis.
- Domain Name and IP Reputation Analysis: the same lookup applied to hostnames and addresses. See D3-DNRA Domain Name Reputation Analysis and D3-IPRA IP Reputation Analysis.
- URL Analysis (D3-UA): inspects the URL itself and catches what reputation misses. See D3-UA URL Analysis.
Practitioner checklist
- List every channel that delivers URLs to people and to automated systems.
- Enable time-of-click URL checks in mail, not only delivery-time scanning.
- Enforce browser URL protection by policy on managed devices.
- Route web and DNS traffic through a proxy or protective DNS with reputation checks.
- Disable click-through on warning pages where the business allows it.
- Push URLs from confirmed incidents to local block lists within minutes.
- Review allow-list entries on a schedule and remove wildcards on shared hosting domains.
- Keep raw URLs in logs for retrospective hunting.
- Run a monthly test URL check per enforcement point and record the result.
Standards and references
- MITRE D3FEND: URL Reputation Analysis (D3-URA)
- Google Patents: US8839418B2 Finding phishing sites
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- abuse.ch: URLhaus API and feeds
- Google for Developers: Safe Browsing API v5 reference
- Google for Developers: Safe Browsing Lookup API (v4)
- Microsoft Learn: Safe Links in Microsoft Defender for Office 365
- Microsoft Learn: Microsoft Defender SmartScreen
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Secure Web Gateway and Web Filtering Guide · Protective DNS Guide · MITRE ATT&CK T1566 Phishing · Remote Browser Isolation Guide