A signature written by your own team for the malware that targeted you last week is often the fastest detection you can deploy, and also the easiest to get wrong. MITRE D3FEND names this countermeasure File Content Rules (D3-FCR), with the synonyms File Signatures and File Content Signatures, and defines it as "Employing a pattern matching rule language to analyze the content of files." It sits under the Detect tactic as a child of File Content Analysis (D3-FCOA), itself a child of File Analysis (D3-FA). D3FEND names two implementations, YARA and ClamAV. This card covers how rule-based file detection works, which ATT&CK techniques D3FEND relates to it, how to run a rule lifecycle from intelligence to production, and how to verify rules fire without flooding the SOC. Rule syntax in depth is in the YARA Rules Guide; this page stays on the countermeasure. Tools are listed alphabetically.
Key takeaways
- Public and private rule sets do different jobs. D3FEND notes that rules are distributed broadly by commercial vendors or written by enterprise teams for highly targeted or custom malware; the technology is the same, the adversaries differ.
- Every rule is a trade-off. D3FEND lists three: matching fidelity against false positives, the computational load of scanning, and the engine's resilience to adversarial content designed to defeat or exploit it.
- Rules cannot see through encoding. Simple signatures against raw content cannot match encoded, encrypted or sufficiently obfuscated content, so rules work best on unpacked files, memory or decoded script content.
- The ATT&CK mapping is inferred. D3FEND relates D3-FCR to the same broad set of file-based ATT&CK techniques as its parent; actual coverage is whatever your rules describe.
- Test against goodware before production. A rule that matches a common library or installer generates thousands of alerts in minutes; a clean-file corpus test is part of the control.
D3-FCR at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FCR (d3f:FileContentRules) |
| Synonyms | File Signatures, File Content Signatures |
| Tactic | Detect |
| Parent technique | File Content Analysis (D3-FCOA), under File Analysis (D3-FA) |
| Digital artefact | File (analyzes File, inherited from File Analysis) |
| Implementations named by D3FEND | ClamAV, YARA |
| D3FEND references | Four patents: CrowdStrike, "Computational modeling and classification of data streams" and "Detecting script-based malware"; Bit9, "Distributed meta-information query in a network"; Palo Alto Networks and Cyber Secdo, logical identification of malicious threats across end-point devices |
| Main limitation | Detects only what a rule describes; blind to encoded or encrypted content |
How it works
D3FEND describes the mechanism in three parts: rules, often called signatures, are expressed in a domain specific language, deployed to software that scans files for matches, and used for both generic and targeted detection. D3FEND also notes that engines vary: some support file parsing and normalisation for high-fidelity matching, others support only simple regular expression matching against raw data.
The two named engines
| Engine | Rule forms | Testing tools (from project docs) |
|---|---|---|
| ClamAV | Body-based signatures: extended (.ndb), logical (.ldb), container metadata (.cdb) and bytecode (.cbc). Hash signatures for whole files (.hdb, .hsb) and PE sections (.mdb, .msb). YARA rules (.yar, .yara) from ClamAV 0.99. Allowlists (.fp, .sfp) and ignored signatures (.ign2) | clamscan -d <rules> <sample> to test a database; sigtool --test-sigs to show where a signature matches, useful for false positive analysis |
| YARA | Rules with optional meta and strings sections and a required condition. Text, hex (with wildcards, jumps and alternatives) and regular expression strings; modifiers including nocase, wide, ascii, xor, base64, fullword and private; modules such as pe and hash; global and private rules; external variables | yara -s to print matching strings; -r recursive; -p threads; --timeout; --skip-larger (YARA 4.2.0 and later); yarac to precompile rules, loaded with -C |
One operational note from the ClamAV documentation: loading a test database with -d stops the standard signature databases loading, which can disable some unpacking and Authenticode trust checks. Test in a way that matches production, or results will differ.
What a good rule anchors on
- File type first: a cheap structural check (for YARA, a PE header test such as the IsPE example in the documentation) stops a rule running its expensive strings against every file.
- Several independent indicators: distinctive strings, a code byte pattern with wildcards for changing operands, and a structural feature such as an import hash, combined so one changed string does not break the rule.
- Bounded conditions: a file size limit and position constraints keep matching fast and reduce false positives.
- Metadata for the SOC: author, date, reference, family and confidence in the rule's meta section, so an analyst knows what a hit means.
Sigma rules look similar but describe log events, not file content. They belong to the detection pipeline in the Sigma Rules Guide, and the two are often written as a pair from the same intelligence.
ATT&CK techniques D3FEND relates to D3-FCR
Relationship type: inferred only. D3FEND derives every row from the File artefact: the ATT&CK technique involves a File and D3-FCR analyzes File. D3FEND labels these relations "inferred, experimental" (D3FEND knowledge graph 1.6.0, checked November 2026). The same list appears for the parent, File Content Analysis. 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.
Rules are most useful where an adversary leaves a distinctive file: web shells (T1505.003), malicious DLLs placed for hijacking (T1574.001), Office template macros (T1137.001), persistence scripts and the attachments behind T1566.001. For masquerading files (T1036.005, T1036.006) a content rule identifies the payload whatever its name. Defensive context is in the T1505 Server Software Component Defensive Guide and the T1036 Masquerading Defensive Guide.
Running the rule lifecycle
- Source the rule. Public sets from vendors and community projects cover common families. Private rules come from your own incident response, malware analysis and shared intelligence; government malware analysis reports, such as those from CISA, often include YARA rules with their indicators.
- Review before import. Read every third-party rule. Check its conditions, its file size bounds and whether it uses expensive patterns such as unbounded regular expressions or very short strings.
- Test against known bad. Run the rule against the samples it targets, unpacked and packed, and record which variants it catches.
- Test against known good. Run it against a clean-file corpus: your gold OS images, common installers and your own software builds. Any match is a false positive to fix before deployment.
- Deploy in report mode. Push to a pilot ring or run as a retrospective sweep first, collect matches, then promote to blocking where the engine supports it.
- Version and own it. Keep rules in version control with an owner, review date and test results. D3FEND notes that libraries grow large over time and affect scanning performance, and that vendors delete old signatures; retire private rules that no longer earn their cost.
- Roll back. If a rule causes false positives in production, revert to the previous rule set version, release quarantined files after review and add the false positive file to the clean corpus.
Where it is implemented
| Placement | Typical use of rules | Note |
|---|---|---|
| Endpoint protection with custom rule support | Private rules applied on access or on demand | Check the product's documented rule syntax and limits |
| Mail and web gateways | Rules on attachments and downloads before delivery | Only as good as the gateway's ability to unpack containers |
| Malware sandboxes and analysis pipelines | Rules on dropped files and memory dumps, where content is already unpacked | See the Malware Sandbox Guide |
| Incident response sweeps | New intelligence applied across many hosts at once | See the IOC Scanners Guide |
| Storage and repository scanning | Rules on file shares, upload buckets and build artefacts | Schedule around write volume |
How to verify it works
- Per-rule unit tests: each rule has at least one positive sample (or a safe synthetic file that contains the matched strings) and runs clean against the goodware corpus in CI before merge.
- Engine path test: place a harmless file built to match a dedicated test rule on each scan path and confirm the alert reaches the SIEM with rule name, file path and hash.
- Performance check: measure scan time on a representative host before and after a rule set change. A large jump usually points to one expensive rule.
- Retro-hunt: when a new rule is written from an incident, run it against stored samples and recent sandbox output to see whether the family was already present.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Private rules with a positive test and a clean goodware run | 100% | Untested rules are the main source of false positives |
| Time from new intelligence to rule in production | Within one working day for priority families | Speed is the main advantage of private rules |
| False positives per rule per month | Tracked, with an owner for each noisy rule | Keeps analyst trust in rule hits |
| Rules past their review date | Falling quarter on quarter | Library growth slows scanning, as D3FEND notes |
| Scan time change per rule set release | Measured on every release | Catches expensive rules before they reach every host |
Limits, bypasses and failure patterns
- Obfuscated content: as D3FEND states, simple signatures against raw content cannot match encoded, encrypted or sufficiently obfuscated content. Apply rules after unpacking, to memory, or to decoded script content. See the T1027 Obfuscated Files or Information Defensive Guide.
- Brittle single-string rules: a rule keyed on one string from a sample breaks on the next build. Combine independent indicators.
- Adversarial content against the engine: D3FEND notes that some content is designed to exploit or defeat scanning engines. Keep engines patched and run scanning with the least privilege the product allows.
- Unreviewed public rule imports: large community sets imported without testing bring both false positives and performance problems.
- Rule sprawl: thousands of private rules with no owner or review date slow every scan and nobody knows which still matter.
- Rule content as sensitive data: private rules reveal what you know about an adversary. Store them with access control like other detection content.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 Malicious Code Protection | Signature-based malicious code detection and updates |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Rule hits as monitoring events |
| NIST CSF 2.0 | DE.CM-09, ID.RA-03 | Monitoring software and data; recording threats that rules are written for |
| CIS Controls v8.1 | Control 10 Malware Defenses | Anti-malware with current signatures |
| MITRE ATT&CK mitigation | M1049 Antivirus/Antimalware | Closest ATT&CK mitigation (NHI Mgmt Group view); see M1049 Antivirus/Antimalware |
| MITRE D3FEND | D3-FCOA, D3-FCR | Parent and technique |
Related countermeasures
- File Content Analysis (D3-FCOA): the parent, which also covers parsers, heuristics and learned models. See D3-FCOA File Content Analysis.
- File Hashing (D3-FH): exact-match detection, often used alongside rules for the same intelligence. See D3-FH File Hashing.
- Emulated File Analysis (D3-EFA) and Dynamic Analysis (D3-DA): produce the unpacked content and memory that rules match best against. See D3-EFA Emulated File Analysis and D3-DA Dynamic Analysis.
Practitioner checklist
- Keep private rules in version control with owner, reference and review date.
- Read and test every public rule before import.
- Start rules with a file type check and bound them by size.
- Test each rule against target samples and a clean-file corpus before release.
- Deploy new rules in report mode or as a sweep before blocking.
- Measure scan time on every rule set release.
- Apply rules to unpacked files and memory, not only raw files on disk.
- Retire rules that no longer earn their scanning cost.
Standards and references
- MITRE D3FEND: File Content Rules (D3-FCR)
- CISA: Malware Analysis Report AR25-261A (example report with YARA rules)
- MITRE D3FEND: File Content Analysis (D3-FCOA)
- ClamAV Documentation: Signatures
- YARA Documentation: Writing YARA rules
- YARA Documentation: Running YARA from the command line
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-3 Malicious Code Protection)
- NIST: SP 800-83 Rev. 1 Guide to Malware Incident Prevention and Handling for Desktops and Laptops
Related NHI Mgmt Group resources: YARA Rules Guide · Sigma Rules Guide · Malware Analysis Guide for Defenders · IOC Scanners Guide · MITRE D3FEND Guide