A file hash tells you exactly which file you are looking at, and a reputation lookup tells you whether anyone has already seen that file do harm, but the two together only help if the verdict arrives in time and the hash is still current. MITRE D3FEND names this countermeasure File Hash Reputation Analysis (D3-FHRA) and defines it as "Analyzing the reputation of a file hash." It sits under the Detect tactic as a child of Identifier Reputation Analysis (D3-IRA), which in turn sits under Identifier Analysis. This card explains what D3-FHRA does and does not catch, how D3FEND relates it to ATT&CK, where it is implemented, and how to prove your hash verdicts are working. It is written for detection engineers and SOC leads who already run endpoint protection and a threat intelligence feed.
Key takeaways
- Exact match, high precision. A cryptographic hash identifies one exact file, so a known-bad match is rarely a false positive, but a single changed byte produces a new hash and a clean lookup.
- No ATT&CK mapping in D3FEND. D3FEND 1.6.0 records no ATT&CK technique that acts on the File Hash artefact, so D3-FHRA has no direct or inferred ATT&CK relations; its value comes from the file-based techniques that deliver known malware.
- Unknown is a verdict too. The most useful signal is often not "bad" but "never seen before", applied to executables arriving by email, download or removable media.
- Hashes sit at the bottom of the Pyramid of Pain. David Bianco rates hash values as trivial for an adversary to change, so FHRA is a fast filter, not a strategy on its own.
- Verify the whole path. Hash computation must be switched on, lookups must reach the reputation source and verdicts must reach the alert queue; any one gap fails silently.
D3-FHRA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FHRA (d3f:FileHashReputationAnalysis) |
| Tactic | Detect |
| Parent technique | Identifier Reputation Analysis (D3-IRA), under Identifier Analysis (D3-ID) |
| Digital artefact | File Hash (D3FEND relation: analyzes File Hash). D3FEND defines a File Hash as a fixed-length digital fingerprint produced by applying a cryptographic hash function to a file's contents. |
| D3FEND reference | Patent US20060253584A1, "Reputation of an entity associated with a content item" |
| ATT&CK relations in D3FEND | None (checked November 2026) |
| Typical data sources | Endpoint protection telemetry, process creation and driver load events with hashes, email and web gateway attachment hashes, file upload scanning |
| Effort | Low where endpoint protection already does lookups; medium for a SIEM-side matching pipeline |
| Main limitation | Detects only files already known; a recompiled or repacked sample has a new hash |
How it works
D3FEND gives no "how it works" text for D3-FHRA beyond the definition, so the description here follows the artefact and the parent technique. The countermeasure has three parts.
- Compute: hash the file at the point of interest: on write, on execution, on driver or module load, or when an attachment passes a gateway. SHA-256 is the default to standardise on; MD5 and SHA-1 still appear in feeds but are weaker identifiers (see the Hashing Guide).
- Look up: query one or more reputation sources: the endpoint vendor's cloud, a threat intelligence platform, a commercial or community multi-scanner service, your own internal block and allow lists, and known-good sets. For example, the VirusTotal API returns a file report from
GET /api/v3/files/{id}, where the id is a SHA-256, SHA-1 or MD5. - Decide: map the answer to an action. Known bad: block or alert. Known good: suppress. Unknown or first seen: apply extra scrutiny such as detonation, a prevalence check or a hold for review.
Known-good sets are the other half of the technique. The NIST National Software Reference Library publishes a Reference Data Set (RDS) of digital signatures of known, traceable software applications. NIST notes that the RDS also contains hashes of software some would consider malicious, such as steganography tools and hacking scripts, so a match means "known", not "safe".
ATT&CK techniques D3FEND relates to D3-FHRA
Relationship type: none recorded. D3FEND derives ATT&CK relations through shared digital artefacts, and no ATT&CK technique in D3FEND 1.6.0 acts on the File Hash artefact (checked November 2026). The table below is therefore an NHI Mgmt Group view of where hash reputation helps in practice, not a D3FEND mapping. Every ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Where a hash verdict helps (NHI Mgmt Group view) | Why it can miss |
|---|---|---|---|
| T1204.002 | User Execution: Malicious File | A commodity payload opened by a user matches a known-bad hash on write or execution | Per-victim builds and password-protected archives |
| T1588.001 | Obtain Capabilities: Malware | Reused off-the-shelf malware and tools keep the same hashes across victims | Builders that generate a unique binary each time |
| T1036 | Masquerading | A file named like a system binary whose hash does not match the known-good copy | Requires a reliable known-good baseline |
| T1027 | Obfuscated Files or Information | Rarely: packing changes the hash, which is exactly why exact matching fails here | Use behaviour, fuzzy hashing or import hashing instead |
Defensive treatment of the mitigations sits in M1049 Antivirus/Antimalware and M1038 Execution Prevention; this page does not repeat them.
Where it is implemented
| Implementation class | What it provides | Hash source | Fits when |
|---|---|---|---|
| Endpoint protection and EDR | Cloud reputation at execution plus custom file indicators. Microsoft Defender for Endpoint, for example, accepts SHA-256, SHA-1 and MD5 file indicators with allow, audit and block actions | Computed by the agent | Default for every managed endpoint |
| Process telemetry plus SIEM matching | Hashes in logged events matched against an indicator index. Sysmon logs hashes in Event ID 1 (process creation), 6 (driver loaded), 7 (image loaded, off by default) and 15 (FileCreateStreamHash) | Sysmon HashAlgorithms: MD5, SHA1, SHA256, IMPHASH or * | You need retrospective search and your own lists |
| Email and web gateways | Attachment and download hash lookups before delivery | Computed by the gateway | Most malicious files still arrive by mail or browser |
| Threat intelligence platform | Aggregated verdicts, sightings and expiry from several feeds | Feeds and internal analysis | Several feeds need de-duplication and scoring |
| Application control | Hash-based allow rules for known-good binaries | Policy authoring | High-assurance servers and kiosks (see the Application Allowlisting Guide) |
Two product facts matter when you add your own indicators in Defender for Endpoint. First, file hash computation must be enabled (the "Enable File Hash Computation" policy or Set-MpPreference -EnableFileHashComputation $true), with cloud-delivered protection on and Defender Antivirus in active mode. Second, Microsoft documents that file blocks are typically enforced within 15 minutes, 30 minutes on average, and up to 2 hours, so a new indicator is not instant protection. For SIEM-side matching, Elastic's indicator match rule maps a source field such as file.hash.sha256 to threat.indicator.file.hash.sha256 and by default searches indicators ingested in the last 30 days.
Implementation steps
- Standardise on SHA-256. Configure agents, Sysmon and gateways to record SHA-256, keep MD5 and SHA-1 only where a feed still requires them, and normalise case and field names in the SIEM.
- Turn on the hash data you need. Enable hash computation on endpoints and confirm process creation and driver load events carry hashes. Add image load events only where volume allows.
- Choose reputation sources and an order. Internal allow and block lists first, then vendor cloud, then external intelligence. Record each source's licence terms, especially whether uploading files (rather than hashes) is allowed: never submit confidential documents to a public multi-scanner service.
- Define verdict handling. Known bad: block in prevention tools and alert. Unknown executables from email, browser download or removable media: alert or detonate (NIST SP 800-53 SC-44 Detonation Chambers). Known good: suppress downstream noise.
- Pilot in audit mode. Load custom indicators as audit or alert-only for one to two weeks, review every hit, and remove any indicator that matches legitimate software before switching to block.
- Expire indicators. Give each custom hash indicator an owner, a source and a review date. Stale block lists grow without limit and hide the few indicators that still matter.
- Plan rollback. Keep a tested way to remove or switch a hash block to audit quickly, and remember the enforcement delay applies to removal as well as to blocking.
How to verify it works
- Safe test file: on an approved test host, write the EICAR anti-malware test file and confirm detection, the logged hash and the alert in the queue.
- Custom indicator test: create a harmless test executable, add its SHA-256 as an audit indicator, run it, and time how long the alert takes against the vendor's stated window.
- Telemetry coverage check: query the SIEM for the share of process creation events with a non-empty SHA-256 field, per operating system and per business unit.
- Retro match test: load a hash already present in last week's telemetry into the indicator index and confirm the matching rule fires.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Process events carrying SHA-256 | Above 99% of managed endpoints | No hash, no lookup |
| Time from indicator creation to enforcement | Within the vendor's documented window | Shows the policy path is healthy |
| Custom hash indicators past review date | Zero | Stale lists hide useful indicators |
| First-seen executables from email or web that were triaged | Tracked weekly | The unknown verdict is where FHRA earns most value |
| False positive blocks from hash indicators | Close to zero after pilot | Confirms audit-mode review works |
Limits, bypasses and failure patterns
- Trivial evasion: recompiling, repacking or appending a byte creates a new hash. Bianco's Pyramid of Pain places hash values at the bottom for this reason and places fuzzy hashes such as ssdeep higher because they survive small changes.
- Unknown treated as clean: many pipelines only alert on known bad, so the targeted, never-seen file passes. Treat first-seen executables from risky entry points as suspicious.
- Known good treated as safe: a legitimate signed remote access tool or admin utility has a clean reputation and is still widely abused. Reputation says what a file is, not whether its use is authorised.
- Policy precedence surprises: in Defender for Endpoint, application control enforcement and antivirus exclusions take precedence over file indicators, and a certificate block wins over a hash allow. Check precedence before relying on an allow or block.
- Hash computation off: lookups silently return nothing when agents or Sysmon do not compute the needed hash type.
- Data leakage through lookups: uploading internal files to public scanning services can expose them to other subscribers. Submit hashes, not files, unless the content is cleared for sharing.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Signature and reputation based detection of malicious code |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, SI-5 Security Alerts, Advisories, and Directives | Monitoring telemetry and acting on received indicators |
| NIST SP 800-53 Rev 5 | SC-44 Detonation Chambers | Handling unknown files |
| NIST CSF 2.0 | DE.CM-09, DE.AE-07, ID.RA-02 | Monitoring software and runtime environments; integrating threat intelligence; receiving threat intelligence |
| MITRE ATT&CK | M1049 Antivirus/Antimalware | The mitigation most hash reputation lives in |
| MITRE D3FEND | D3-ID, D3-IRA, D3-FHRA | Grandparent, parent and technique |
Related countermeasures
- Identifier Reputation Analysis (D3-IRA): the parent, covering domains, IP addresses and URLs as well as hashes. See D3-IRA Identifier Reputation Analysis.
- Identifier Activity Analysis (D3-IAA): searching your own telemetry for where a known-bad hash has already been. See D3-IAA Identifier Activity Analysis.
- Process Spawn Analysis (D3-PSA): behaviour-based detection that still works when the hash is new. See D3-PSA Process Spawn Analysis.
Practitioner checklist
- Record SHA-256 for process creation and driver load events on every managed endpoint.
- Enable hash computation where the endpoint product requires it for custom indicators.
- Order reputation sources: internal lists, vendor cloud, external intelligence.
- Submit hashes, not files, to public services unless the content is cleared for sharing.
- Treat first-seen executables from email, web and removable media as suspicious.
- Pilot every new block list in audit mode and review each hit.
- Give each custom hash indicator an owner, source and review date.
- Test with the EICAR file and a custom audit indicator each quarter and record the timings.
- Pair hash verdicts with behavioural detections for packed and per-victim payloads.
Standards and references
- MITRE D3FEND: File Hash Reputation Analysis (D3-FHRA)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-3, SC-44)
- NIST: National Software Reference Library (NSRL)
- Microsoft Learn: Create indicators for files (Defender for Endpoint)
- Microsoft Learn: Sysmon
- Elastic Docs: Indicator match rules
- VirusTotal Docs: Get a file report
- David Bianco: The Pyramid of Pain
Related NHI Mgmt Group resources: MITRE D3FEND Guide · EDR Guide · IOC Scanners Guide · YARA Rules Guide · Hashing Guide