Most intrusions write something to disk, and the moment a file is created in the wrong place, by the wrong process, is one of the cheapest points at which to catch them. MITRE D3FEND names this countermeasure File Creation Analysis (D3-FCA) and defines it as "Analyzing the properties of file create system call invocations." It sits under the Detect tactic as the child of System Call Analysis (D3-SCA). This card explains what D3-FCA looks at, which ATT&CK techniques D3FEND relates to it, how to collect file create telemetry on Windows, Linux and macOS, how to prove the detections fire, and where the technique runs out. It is written for detection engineers and SOC leads who already collect endpoint telemetry and want to use file create events with intent rather than by volume.
Key takeaways
- It is an analytic, not a product. D3-FCA means writing logic over file create events: which process created which file, where, with what name and type. The sensor (Sysmon, auditd, an EDR) only supplies the events.
- D3FEND's own mapping is narrow. D3FEND 1.6.0 relates D3-FCA to two ATT&CK techniques through the Create File artefact: Local Data Staging (T1074.001) and Compiled HTML File (T1218.001). Both are inferred relations.
- The references show the real use. D3FEND cites MITRE CAR analytics for scheduled task files created outside the Task Scheduler service, and for credential dumping, which is where file create analysis earns its keep in practice.
- Context is everything. A file created is noise; a file created in C:\Windows\System32\Tasks by a process other than svchost.exe is a detection. Good rules pair path, creating process and file type.
- Test with harmless synthetic files. Each rule should have a unit test that creates a benign file in the watched location from the expected and an unexpected process, so silent breakage is caught.
D3-FCA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FCA (d3f:FileCreationAnalysis) |
| Tactic | Detect |
| Parent technique | System Call Analysis (D3-SCA), itself under Process Analysis |
| Digital artefact | Create File (D3FEND relation: analyzes Create File) |
| D3FEND references | MITRE CAR-2020-09-001 Scheduled Task - FileAccess; MITRE CAR-2019-07-002 Lsass Process Dump via Procdump |
| Typical data sources | Sysmon Event ID 11 (FileCreate), Linux audit records for file-creating system calls, osquery file_events, EDR file telemetry |
| Effort | Low to start if endpoint telemetry exists; ongoing tuning per rule |
| Main limitation | Sees creation only; in-memory activity and modification of existing files need other techniques |
How it works
D3FEND's parent technique, System Call Analysis, describes system calls as the interface between a user application and the operating system, captured by hooking or kernel APIs. D3-FCA narrows that to one family: calls that create a file. Each event carries a small set of properties, and the analytic tests them.
- Path: autostart folders, scheduled task directories, web server roots, temporary and download directories, staging folders. Sysmon's documentation calls out exactly these: Event ID 11 "is useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places malware drops during initial infection."
- Creating process: the image that made the call. CAR-2020-09-001 is built on this: it selects file create events under C:\Windows\System32\Tasks and C:\Windows\Tasks where the creating image is not C:\WINDOWS\system32\svchost.exe.
- Name and type: double extensions, executable content where documents are expected, archive files in unusual places, dump files (.dmp) appearing outside crash handling.
- Volume and timing: many archive or copy files created in one directory in a short window suggests staging before exfiltration.
The second D3FEND reference, CAR-2019-07-002, detects ProcDump being used against lsass.exe. Its pseudocode actually keys on process creation and command line, not on file creation, but the dump file it writes is a natural file create pivot. An NHI Mgmt Group suggestion, not a D3FEND mapping: pair that analytic with a file create rule for new .dmp files outside expected crash dump paths, so the dump is caught even when the tool is renamed.
ATT&CK techniques D3FEND relates to D3-FCA
Relationship type: inferred only. D3FEND 1.6.0 lists no direct ATT&CK mapping for D3-FCA; both rows below are inferred because the ATT&CK technique creates a file, the artefact D3-FCA analyses (checked November 2026). IDs verified against ATT&CK v20.
| ATT&CK ID | Technique | Tactic (v20) | File create signal to look for |
|---|---|---|---|
| T1074.001 | Local Data Staging | Collection | Bursts of archive or copied files written to one local directory, often under temp or user profile paths, by a shell, scripting host or archiver |
| T1218.001 | Compiled HTML File | Stealth | A .chm file written from a browser, mail client or archive extraction, and files dropped by hh.exe afterwards |
The CAR references add two more techniques that file create analysis supports in practice, although D3FEND does not list them as relations of D3-FCA: Scheduled Task (T1053.005), via task files created outside the Task Scheduler service, and LSASS Memory (T1003.001), via dump files. For the techniques themselves see T1074 Data Staged, T1218 System Binary Proxy Execution Defensive Guide, T1053 Scheduled Task/Job Defensive Guide and T1003 OS Credential Dumping.
Where it is implemented
Sensors are listed by platform. Any EDR or SIEM can host the analytic once the events arrive.
| Platform | Event source | Fields available | Notes |
|---|---|---|---|
| Linux | Linux Audit (auditd) syscall rules on file-creating calls, or path and directory rules with write permission | Syscall, path, executable, user and audit key | The auditctl man page marks the older -w watch form as deprecated "due to poor system performance" and shows the replacement form -a always,exit -F arch=b64 -F dir=... -F perm=wa |
| Linux, macOS, Windows | osquery file_events (inotify on Linux, FSEvents on macOS), ntfs_journal_events on Windows | Action, target path, category, MD5, SHA1 and SHA256 where possible | Off by default; paths are grouped in named file_paths categories, and invalid exclude_paths categories are dropped silently |
| Windows | Sysmon Event ID 11 FileCreate; Event ID 29 FileExecutableDetected for new PE files; Event ID 15 FileCreateStreamHash for named streams such as Zone.Identifier | Image, TargetFilename, creation time, hashes (for 15 and 29) | Event 11 fires when a file is created or overwritten; filter by include rules in the Sysmon configuration to control volume |
| Any | EDR file telemetry | Usually process tree, file path, hash and reputation | Check the product documentation for sampling or deduplication of file events, which can hide single creations |
Configuration detail for the Windows sensor is in the Sysmon Guide, and for Linux in the Linux Logging and auditd for Defenders Guide.
Implementation steps
- Choose the locations first. List the directories where a new file is meaningful in your estate: task and cron directories, startup and autostart folders, web roots, service binary paths, and the temp and download folders used for staging. Writing rules for "all files" produces volume, not detections.
- Collect only those paths at high fidelity. Use Sysmon include rules, audit directory rules or osquery categories scoped to the list. Confirm event volume per host in a pilot ring before fleet rollout.
- Write each rule as path plus creator. Model on CAR-2020-09-001: watched path, expected creating process, alert on anything else. Record the expected creators per path (package managers, deployment agents, the Task Scheduler service) as an allow list with an owner.
- Add type checks. Use Sysmon Event ID 29 or a hash and extension check to flag executables written where documents or data belong.
- Pilot in alert-only mode. Run for two to four weeks on a representative group. Tune benign creators by adding them to the allow list with a reason, not by widening the path.
- Roll out and keep a rollback. Deploy the sensor configuration through your usual management channel with the previous version kept; if volume spikes or a host slows, revert the configuration rather than disabling the sensor.
How to verify it works
- Unit test per rule: CAR lists a unit test per analytic. Mirror that: for the scheduled task rule, create a harmless text file in the task directory from a test shell and confirm the alert, then create a real task through the Task Scheduler and confirm no alert.
- Staging test: copy a set of dummy files into an archive in a temp folder from a test account and confirm the staging rule fires on volume and archive type.
- Sensor health: alert when a host stops sending file create events for longer than its normal interval; a stopped sensor looks identical to a quiet host.
- Configuration drift: compare the deployed Sysmon or audit configuration hash on each host with the approved version.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Rules passing their monthly unit test | 100% | Proves the path from sensor to alert works |
| Hosts reporting file create events in the last 24 hours | Above 98% of managed endpoints | Coverage gaps are invisible otherwise |
| Alerts per rule per week after tuning | Low and stable | A noisy rule gets ignored |
| Allow list entries with an owner and reason | 100% | Unowned exclusions become blind spots |
Limits, bypasses and failure patterns
- Fileless activity: code that runs only in memory, or reads and writes the registry, creates no file. Pair D3-FCA with D3-PSA Process Spawn Analysis and memory-focused techniques.
- Modification of existing files: a create rule does not see an attacker editing an existing script or binary. That is File Integrity Monitoring territory, covered in D3-FIM File Integrity Monitoring.
- Trusted creators: if the allow list trusts a deployment tool or package manager, an attacker who controls that tool writes files without alerts. Watch the tool's own configuration and its service identity.
- Timestamp games: attackers can change a file's creation time. Sysmon Event ID 2 records explicit changes to file creation time; its documentation also notes many processes do this legitimately.
- Overwritten files and renames: check how your sensor treats overwrite and rename; Sysmon logs overwrite as Event ID 11, but a rename into a watched path may surface differently per sensor.
- Volume suppression: broad rules on busy paths lead to sampling, filtering or ignored queues, which is how real creations get missed.
Where identity fits
The creating process runs as an identity, and in servers that is usually a service account or workload identity. Recording the user or service account on each file create event lets the rule say "the backup service account created a scheduled task", which is both higher fidelity and a pointer to which non-human credential to rotate. The CAR LSASS reference is the same story from the other side: a dump file on disk is credential material for every identity that was logged on.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE D3FEND | D3-SCA, D3-FCA | Parent and technique |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring the system to detect attacks and indicators of potential attacks |
| NIST SP 800-53 Rev 5 | AU-6 Audit Record Review, Analysis, and Reporting | Review and analysis of the collected file events |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring computing hardware, software and runtime environments; analysing potentially adverse events |
| MITRE CAR | CAR-2020-09-001, CAR-2019-07-002 | Reference analytics D3FEND cites |
Practitioner checklist
- List the directories where a new file is meaningful and scope collection to them.
- Write every rule as watched path plus expected creating process.
- Keep an owned allow list of legitimate creators per path.
- Flag executables written where documents or data belong.
- Record the creating user or service account on each event.
- Give every rule a unit test and run it monthly.
- Alert on hosts that stop sending file create events.
- Pair D3-FCA with process and integrity monitoring for activity it cannot see.
Standards and references
- MITRE D3FEND: File Creation Analysis (D3-FCA)
- MITRE CAR: CAR-2020-09-001 Scheduled Task - FileAccess
- MITRE CAR: CAR-2019-07-002 Lsass Process Dump via Procdump
- Microsoft Learn: Sysmon
- Linux man-pages: auditctl(8)
- osquery: File Integrity Monitoring and file_events
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: D3-SCA System Call Analysis · D3-FIM File Integrity Monitoring · Sysmon Guide · MITRE D3FEND Guide