Definition
Determining if a URL is benign or malicious by analyzing the URL or its components.
How it works
URLs may contain components, for example:
These components are used as features in analysis algorithms.
Contextual information about a URL such as where it is embedded (ex. emails, files, network protocols), header, path, location, and origin information, as well as information about the content returned from the URL request, may be incorporated into an analytic for URL analysis. For example, if a URL indicates a .pdf file but an executable is actually returned, the combination of these two pieces of information indicates suspicious activity.
Additional techniques include:
URL analysis may trigger follow-on analytics such as **File Analysis**
- scheme
- userinfo
- host name
- port
- path
- query
- fragment
- Extracting features of a URL such as domain name length, ratio of consecutive consonants, percentage of digits in a domain, and number of vowels. Values for each feature are combined to develop a score for the URL.
- Determining the probability of a character occurring in the URL given the preceding two characters. For example, for google.com, the probability of a 'g' occurring at the beginning of a word, the probability of an 'o' occurring after a "g, the probability of an o" occurring after a 'g' and "o, and so forth. A dictionary or a list of known good domains is used to determine probability. Probabilities are multiplied to develop a score for the URL.
Considerations
- Volume of URLs being analyzed, combined with the speed at which they are analyzed
- Fidelity of analysis technique at detecting brand new URLs versus analyzing URLs of established domains
Implementation perspective
URL Analysis should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes URL.
Use the technique to identify suspicious, unauthorized, or abnormal activity through observable evidence and repeatable analysis.
Questions to ask
- Which events, states, or artifacts must be observed for the analysis to work?
- What analytic logic, threshold, comparison, or signature turns observations into a finding?
- How are expected false positives, blind spots, and environmental variations documented?
- Who receives the result, and what action is expected when the technique produces a finding?
Evidence and validation
- Telemetry and data-source configuration records
- Analytic logic, thresholds, signatures, and version history
- Test cases demonstrating expected positive and negative results
- Alert, triage, escalation, and tuning records
Common failure patterns
- Required telemetry is missing, delayed, or transformed in a way that invalidates the analysis.
- The technique produces alerts without an accountable triage and response process.
- Detection coverage is claimed from product deployment without testing the relevant analytic behavior.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (1)
ATT&CK Enterprise mitigation relationships
These links come from the D3FEND ontology’s ATT&CK mitigation mapping. They help users navigate between the knowledge bases and do not guarantee mitigation effectiveness.
D3FEND note: M1021 scope is broad, touches on an wide variety of techniques in d3fend.
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
ATT&CK Enterprise (4)
ATT&CK for ICS (1)
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Method and Apparatus for Detecting Malicious Websites ↗Endgame Inc · John Burnet MUNRO, IV; Jason Aaron Trost; Zachary Daniel HANIF · PatentReference
- Method and system for detecting restricted content associated with retrieved content ↗Sophos Ltd · Fraser Howard; Paul Baccas; Vanja Svajcer; Benjamin John Godwood; William James McCourt · PatentReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.