A cryptographic hash identifies one exact file, which makes hash matching the fastest and least ambiguous way to find a known malicious file across an estate, and useless the moment one byte changes. MITRE D3FEND names this countermeasure File Hashing (D3-FH) and defines it as "Employing file hash comparisons to detect known malware." It sits under the Detect tactic as a child of File Analysis (D3-FA), alongside File Content Analysis, Dynamic Analysis and Emulated File Analysis. D3FEND's own entry is short: the technique needs a list of hashes to compare against, and its stated consideration is performance on large files or very large numbers of files. This card adds the practical layer: where hashes are computed, which algorithms to use, how to run hash blocklists and sweeps, how to verify them and where hash matching fails. It is written for SOC analysts, incident responders and endpoint engineers. Background on hash functions is in the Hashing Guide.
Key takeaways
- Exact match, near-zero ambiguity. A SHA-256 match means the same bytes, so a hit on a confirmed-malicious hash needs little triage; the cost is that any change to the file produces a new hash.
- The list is the control. D3FEND states the technique requires a list of hashes; its quality, freshness and source decide what the control catches.
- Use SHA-256 as the key. Many tools still accept MD5 and SHA-1, but both have practical collision attacks; keep them for lookups in older data, and key blocking on SHA-256.
- Telemetry makes it retrospective. When process, driver and file creation events carry hashes, a new indicator can be swept across past data, not only blocked going forward.
- Reputation is a separate technique. Asking an external service what is known about a hash is File Hash Reputation Analysis (D3-FHRA); D3-FH is the comparison against a list you hold.
D3-FH at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FH (d3f:FileHashing) |
| Tactic | Detect (inherited from File Analysis) |
| Parent technique | File Analysis (D3-FA) |
| Sibling techniques | Dynamic Analysis (D3-DA), Emulated File Analysis (D3-EFA), File Content Analysis (D3-FCOA) |
| Digital artefact | File (analyzes File, inherited from File Analysis) |
| D3FEND consideration | Performance on large files or very large numbers of files |
| D3FEND reference | Munin, an open source hash checker for VirusTotal and other online services (Florian Roth) |
| Inputs | A hash list (blocklist of known malware, or allowlist of known software) and file hashes computed on hosts, gateways or storage |
| Main limitation | Detects only identical files already on the list |
How it works
File hashing has two halves: computing a hash of each file of interest, and comparing it with a list. The comparison is cheap; the computation is where D3FEND's performance consideration bites, because hashing a large file means reading all of it.
Where hashes are computed
- Endpoint protection: antimalware and EDR agents hash files on access or execution and compare them with vendor and custom indicator lists. Products that support custom file indicators document the hash types they accept and how long a new indicator takes to apply; check your product's documentation for both.
- Endpoint telemetry: Microsoft Sysmon, for example, records the hash of the process image in event ID 1 (process creation), hashes with signature information in event 6 (driver loaded) and 7 (image loaded, off by default), and stream hashes in event 15 (FileCreateStreamHash). Its
HashAlgorithmssetting accepts MD5, SHA1, SHA256 and IMPHASH, or*for all. - Signature engines: ClamAV hash signatures match whole files (.hdb, .hsb) or PE sections (.mdb, .msb), generated with
sigtool --md5,--sha1,--sha256or--mdb. YARA's hash module exposeshash.md5,hash.sha1andhash.sha256over a byte range, and returns lowercase strings, so comparison values must be lowercase. - Gateways and storage: mail, web and file transfer gateways and storage scanners hash content in transit or at rest.
- Forensics: disk images are hashed so investigators can filter out known software. NIST's National Software Reference Library (NSRL) publishes a Reference Data Set of file profiles for known, traceable software applications for this purpose; NIST notes that some entries, such as hacking tools, may be considered malicious, so an NSRL match means "known", not "safe".
Choosing hash types
| Hash type | What it identifies | Use it for | Caution |
|---|---|---|---|
| SHA-256 | Exact file | Primary key for blocklists, allowlists and sharing indicators | Still exact-match only |
| SHA-1, MD5 | Exact file | Matching older indicator feeds and historical telemetry | Practical collision attacks exist; do not use as the only key for allow decisions. See Hash collision attacks |
| PE section hash | One section of a Windows executable | Catching repacked files that keep a malicious section | Engine-specific format (ClamAV .mdb, .msb) |
| Import hash (imphash) | The import table of a PE file | Clustering builds of one family; hunting | Shared by unrelated files built with common toolchains; a lead, not a verdict |
| Fuzzy or locality sensitive hash (for example TLSH) | Similarity between files | Finding variants and clustering samples; TLSH gives a distance score where 0 means almost identical | TLSH's default mode needs at least 50 bytes of sufficiently varied input; scores need thresholds you tune |
ATT&CK techniques D3FEND relates to D3-FH
Relationship type: inferred only. D3FEND derives every row from the File artefact: the ATT&CK technique involves a File and D3-FH analyzes File. D3FEND labels these relations "inferred, experimental" (D3FEND knowledge graph 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques D3FEND relates through the File artefact |
|---|---|
| Initial Access | T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service |
| Execution | T1204.002 Malicious File, T1059 Command and Scripting Interpreter, T1072 Software Deployment Tools, T1127.001 MSBuild |
| Persistence and Privilege Escalation | T1037.001 to T1037.004 logon and RC scripts and Login Hook; T1546.002, .004, .005, .006, .008, .009, .010, .013, .014, .015 event triggered execution (Screensaver, Unix Shell Configuration Modification, Trap, LC_LOAD_DYLIB Addition, Accessibility Features, AppCert DLLs, AppInit DLLs, PowerShell Profile, Emond, COM Hijacking); T1547.001, .006, .007, .008, .009 autostart (Registry Run Keys / Startup Folder, Kernel Modules and Extensions, Re-opened Applications, LSASS Driver, Shortcut Modification); T1543.001, .002, .004 (Launch Agent, Systemd Service, Launch Daemon); T1137.001 Office Template Macros, T1137.003 Outlook Forms; T1505.003 Web Shell; T1548.002 Bypass User Account Control, T1548.003 Sudo and Sudo Caching; T1647 Plist File Modification |
| Stealth | T1055.001, .002, .003, .009, .014 process injection variants; T1218.005 Mshta, T1218.011 Rundll32; T1574.001 DLL, T1574.004 Dylib Hijacking, T1574.006 Dynamic Linker Hijacking, T1574.007 to T1574.009 path interception, T1574.012 COR_PROFILER; T1014 Rootkit; T1036.001 Invalid Code Signature, T1036.003 Rename Legitimate Utilities, T1036.005 Match Legitimate Resource Name or Location, T1036.006 Space after Filename; T1027.001 Binary Padding, T1027.002 Software Packing, T1027.004 Compile After Delivery; T1564.002, .003, .006, .007 hide artefacts; T1220 XSL Script Processing; T1070.004 File Deletion; T1140 Deobfuscate/Decode Files or Information |
| Defense Impairment | T1556.002 Password Filter DLL, T1556.003 Pluggable Authentication Modules; T1685.006 Clear Linux or Mac System Logs; T1690 Prevent Command History Logging |
| Credential Access | T1555.003 Credentials from Web Browsers, T1003.007 Proc Filesystem, T1003.008 /etc/passwd and /etc/shadow, T1552.001 Credentials In Files, T1552.003 Shell History, T1187 Forced Authentication, T1649 Steal or Forge Authentication Certificates |
| Discovery | T1033 System Owner/User Discovery, T1083 File and Directory Discovery, T1018 Remote System Discovery, T1016 System Network Configuration Discovery |
| Collection | T1005 Data from Local System, T1119 Automated Collection, T1074.001 Local Data Staging, T1114.001 Local Email Collection, T1560.001 to T1560.003 Archive Collected Data |
| Lateral Movement | T1534 Internal Spearphishing, T1072 Software Deployment Tools |
| Command and Control, Exfiltration | T1071.001 Web Protocols, T1573.002 Asymmetric Cryptography, T1041 Exfiltration Over C2 Channel, T1048.002 Exfiltration Over Asymmetric Encrypted Non-C2 Protocol |
| Impact | T1486 Data Encrypted for Impact, T1565.001 Stored Data Manipulation, T1565.003 Runtime Data Manipulation |
D3FEND still lists four IDs that ATT&CK v20 has revoked; the table shows the successors: Plist Modification is now T1647 Plist File Modification, DLL Side-Loading is folded into T1574.001 DLL, Clear Linux or Mac System Logs is now T1685.006, and Impair Command History Logging is now T1690 Prevent Command History Logging. D3FEND also lists Launchd, which ATT&CK v20 marks deprecated with no successor, so it is left out.
Hash matching is strongest for commodity tools and malware reused unchanged across many victims, and for confirming the spread of a file already found in an incident. It is weak against T1027.001 Binary Padding and T1027.004 Compile After Delivery, which change the hash by design, and against renamed utilities (T1036.003), where the hash is that of a legitimate tool. For those rows, pair it with D3-FCR File Content Rules and behavioural detection. Context is in the T1027 Obfuscated Files or Information Defensive Guide.
Implementation steps
- Turn on hashing in telemetry. Configure endpoint agents or Sysmon to record SHA-256 on process creation, driver and image loads, and file creation where volume allows. Confirm the fields arrive in the SIEM.
- Define list sources. Blocklist entries come from your own incidents, trusted intelligence sharing and government advisories. Record source, date added, confidence and expiry for each hash.
- Load blocklists in audit first. Where the endpoint product supports an audit action for custom indicators, use it for new bulk imports and review hits before switching to block.
- Protect against self-harm. Before blocking, check each hash against your software inventory and known-good sources so a mistaken entry does not block a business application or OS component.
- Sweep history. For every new high-confidence hash, search retained telemetry for past executions and file writes. A historical hit is an incident, not just a detection.
- Expire entries. Remove or downgrade entries after a review period, keeping incident hashes for retrospective search.
- Roll back. If an entry blocks legitimate software, remove it, release affected files from quarantine after review and add the file to the known-good list used in step 4.
Allowlists use the same mechanism
Hash allowlisting inverts the list: only listed files may run. It is a prevention control rather than detection and belongs with the Application Allowlisting Guide. Hash rules there need updating on every software release, which is why publisher and path rules are often preferred for frequently updated software.
How to verify it works
- Test indicator: create a harmless test file, add its SHA-256 to the blocklist in audit or block mode, deliver it to a pilot host and confirm the detection, the hash field and the alert routing. Record the time from adding the indicator to enforcement.
- Telemetry completeness: sample process creation events per host and confirm the hash field is populated with the expected algorithm.
- Retro-search drill: pick a hash from a past incident and time how long a full-history search takes across the estate.
- List hygiene review: check for duplicate, malformed or uppercase hashes where the tool expects lowercase, and for entries without a source.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Process creation events carrying SHA-256 | Above 99% of hosts in scope | Without hashes there is nothing to compare |
| Time from indicator receipt to enforcement | Within hours for high-confidence hashes | Exact-match indicators lose value quickly |
| Time to sweep full telemetry history for one hash | Minutes, not days | Shows the retrospective use is practical |
| Blocklist entries with source, date and expiry | 100% | Unowned entries cannot be reviewed or defended |
| Blocks of legitimate software after go-live | Zero, with each case reviewed | Shows the known-good check is working |
Limits, bypasses and failure patterns
- One-byte changes: recompiling, repacking or padding a file defeats an exact hash. Treat hash lists as a fast first layer, not a strategy.
- Stale lists: attackers rotate builds quickly, so a large list of old hashes catches little while costing lookup time.
- Weak algorithms for allow decisions: MD5 or SHA-1 used to allow files can be abused with collisions. Key allow decisions on SHA-256 or on code signing.
- Hashing skipped for performance: agents may skip hashing large files or files on network shares, which is D3FEND's performance consideration in practice. Know your product's settings and the gaps they create.
- Leaking hashes and files externally: sending hashes to online services can reveal what you are investigating, and some tools can also submit files or comments. The Munin documentation, for example, lists options that post comments, trigger rescans or download samples. Agree what may leave the organisation before using reputation services.
- Treating "known" as "good": a match in a known-software set means the file is catalogued, not that it is safe in your environment.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Detection of known malicious code |
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity | Integrity verification of software, where hashes of known-good files are compared |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring software and data; analysing detections |
| CIS Controls v8.1 | Control 10 Malware Defenses | Anti-malware with current indicators |
| MITRE ATT&CK mitigation | M1049 Antivirus/Antimalware | Closest ATT&CK mitigation (NHI Mgmt Group view); see M1049 Antivirus/Antimalware |
| MITRE D3FEND | D3-FA, D3-FH | Parent and technique |
Related countermeasures
- File Hash Reputation Analysis (D3-FHRA): asks external or internal reputation sources about a hash. See D3-FHRA File Hash Reputation Analysis.
- File Content Analysis (D3-FCOA) and File Content Rules (D3-FCR): catch variants that hash matching misses. See D3-FCOA File Content Analysis.
- File Integrity Monitoring (D3-FIM): uses hashes the other way round, to detect change to known files. See the File Integrity Monitoring Guide.
Practitioner checklist
- Record SHA-256 in process, driver, image load and file creation telemetry.
- Key blocklists on SHA-256; keep MD5 and SHA-1 only for older data.
- Give every list entry a source, date, confidence and expiry.
- Check new block entries against software inventory before enforcing.
- Sweep retained telemetry for every new high-confidence hash.
- Agree what hashes and files may be sent to external services.
- Test enforcement time with a harmless test file after each product change.
- Pair hash matching with content rules and behavioural detection.
Standards and references
- MITRE D3FEND: File Hashing (D3-FH)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-3, SI-7)
- NIST: National Software Reference Library (NSRL)
- Microsoft Learn: Sysmon
- ClamAV Documentation: Signatures
- YARA Documentation: Hash module
- Trend Micro: TLSH project
- Munin: Online hash checker
Related NHI Mgmt Group resources: Hashing Guide · IOC Scanners Guide · Indicators of Compromise vs Indicators of Attack Guide · Application Allowlisting Guide · MITRE D3FEND Guide