File creation can indicate malware delivery, staging, persistence, or the preparation of exfiltration material. Attackers often create scripts, binaries, archives, shortcut files, or temporary artefacts before later execution. Defenders should correlate new files with the creating process, location, and timing, and investigate creation in user-writable paths, startup locations, or unusual system directories.
What file creation is telling you
file creation is a small event with outsized value because it often appears at the start of an intrusion chain. A new file may be the payload itself, a launcher for later execution, or a staging artefact that prepares data or tools for the next step. The key question is whether the file is ordinary business output or part of an attack workflow.
Creation becomes more suspicious when the file type and location do not fit the process that created it. Scripts dropped into user-writable folders, binaries written into temporary paths, archives appearing just before execution, or shortcut files created in places users commonly browse can all point to malicious preparation rather than normal application behaviour.
File creation also matters because it can show intent before impact. Attackers often need to place content on disk before they can execute it, persist with it, or use it to move laterally. If a newly created file is later opened, run, renamed, copied, or moved into a startup or staging location, that sequence is often more informative than the creation event alone.
Which attack patterns commonly create files
Malware delivery is one of the most common explanations. Droppers, loaders, scripts, and embedded payloads frequently write artefacts to disk before execution, and that first write can be the earliest reliable sign that a compromise is unfolding. Staging activity is another common pattern, where attackers place tools, archives, or data bundles on the system before a later action such as execution, collection, or transfer.
Persistence often leaves file artefacts behind as well. Startup folders, scheduled task payloads, logon scripts, and other autostart mechanisms rely on files being created in locations that the system or user will revisit. When creation occurs in those paths without a clear administrative reason, it can indicate an attempt to survive reboot, re-login, or routine cleanup.
Exfiltration preparation is a third pattern. Attackers may create archives, temporary bundles, or script output to package data before sending it out, and those files can expose the preparation step even when the transfer itself has not yet occurred. For defenders, the important clue is not just that a file exists, but that it was created in a workflow that supports later abuse.
How defenders should interpret file creation events
Interpret the event by combining three questions: what created the file, where it was created, and what happened next. Process context is critical, because the same filename may be harmless in one application flow and suspicious in another. Location matters because user-writable paths, temporary directories, startup locations, and unusual system directories are where attackers most often try to hide activity.
Correlate file creation with nearby process execution, command-line activity, parent-child process lineage, and subsequent file access. A single file write is often weak evidence on its own, but a write followed by execution, privilege change, archive creation, or network activity is much stronger. That sequence can separate normal application churn from an intrusion that is assembling its tools in stages.
File creation should also be checked against the normal behaviour of the host. Build servers, software deployment tools, backup jobs, and installer processes create files routinely, so context is essential. When the creating process is unexpected, the path is atypical, or the timing lines up with an unusual login or remote session, the event deserves escalation rather than dismissal.
Risk and Threat Considerations
File creation is an early warning signal because attackers often need to write something to disk before they can execute payloads, establish persistence, or package data for exfiltration. The risk is highest when the new file appears in a place that is both writable and operationally meaningful, because that often turns a simple write into an execution or persistence opportunity.
Failure mechanism: A malicious process writes a script, binary, archive, or shortcut into a location that later gets executed, indexed, launched, or trusted by the user or operating system.
Impact: The file can become the foothold for malware execution, repeated access, staged tooling, or data theft preparation, especially when defenders treat creation as benign until after execution occurs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | File creation often follows staged tool delivery before execution. |
| T1053 — Scheduled Task/Job | Persistence often uses files created for scheduled or startup execution. | |
| T1027 — Obfuscated Files or Information | Attackers may create archives or disguised artefacts before later use. | |
| Recommendation — Map created payloads to ingress-tool transfer and hunt for follow-on execution. Review newly created task or job files for persistence paths and autorun use. Inspect suspicious new files for concealment, packaging, or staged execution. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Correlation of file creation with process and timing depends on durable logging. |
| Recommendation — Retain file, process, and authentication logs long enough to reconstruct the sequence. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Investigating creation events requires logged process and file activity. |
| Recommendation — Generate audit records for file creation and related process activity. | ||
Practitioner Guidance
What to verify: Confirm whether the creating process is expected for that host, user, and time window. A legitimate installer, updater, or build job should have a clear parent process, path, and business context; if not, treat the file as suspicious until proven otherwise.
Decision rule: If the file was created in a user-writable path, startup location, temporary directory, or unusual system folder, prioritise correlation with process lineage and subsequent execution over the filename itself. If it also appears near login, privilege change, or outbound traffic, escalate immediately.
Practitioner takeaway: File creation is most useful when you treat it as the opening move of a sequence, not as isolated noise; the best investigations ask what wrote the file, why that location was used, and what the host did next.