Live Active security incident? Get immediate response
MITRE ATT&CK® Data Component

DC0039: File Creation

A new file is created on a system or network storage. This action often signifies an operation such as saving a document, writing data, or deploying a file. Logging these events helps identify legitimate or potentially malicious file creation activities. Examples include logging file creation events (e.g., Sysmon Event ID 11 or Linux auditd logs).

EnterpriseDC0039Data ComponentObject v3.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

File creation telemetry is a foundational evidence source: it shows when new content is written to a system or network storage. For leaders, its value is not that every new file is suspicious, but that many investigations, compliance questions, and containment decisions depend on proving what was created, where, when, and by which activity or account when that context is available locally.

Executive priority

Treat this as a baseline SOC and incident-response visibility requirement. If file creation logging is absent, inconsistent, or retained for too short a period, teams may struggle to validate whether sensitive data, tools, scripts, documents, or other files were introduced during an incident. Budget and control decisions should focus on coverage, retention, and searchability rather than assuming raw file events alone provide detection.

Technical view

ATT&CK defines DC0039 as creation of a new file on a system or network storage, with examples such as Sysmon Event ID 11 and Linux auditd logs. Because no tactics, platforms, relationships, or official detection analytics are supplied, defenders should validate this data component as a general telemetry source: confirm which systems and storage locations generate file creation events, whether events include file path, timestamp, user/process context where available, and whether those events are normalized into the SIEM or detection platform.

Likely telemetry

  • File creation event logs from endpoint or host monitoring tools
  • Sysmon Event ID 11 where deployed and configured
  • Linux auditd file creation records where deployed and configured
  • Network storage or file service logs that record newly created files
  • Central SIEM or log platform records containing file path, timestamp, host, user, and process context when available

Detection direction

  • Validate collection first: confirm file creation events are actually generated, forwarded, parsed, retained, and searchable for relevant systems and storage locations.
  • Tune for context rather than volume alone; normal business activity creates many files, so useful analytics usually require path, file name, user, process, host, frequency, or rarity context from the local environment.
  • Identify blind spots such as unmanaged endpoints, unmonitored network shares, missing process attribution, short retention, or log filtering that drops high-volume file events.
  • Use file creation telemetry as supporting evidence in investigations even when it is not sufficient by itself to prove malicious behavior.
  • Because no ATT&CK relationships or official detection guidance are supplied, avoid mapping this data component to specific techniques without additional ATT&CK or local analytic context.

Mitigation priorities

  • Prioritize reliable logging and retention for file creation events across systems and network storage that matter to business operations and investigations.
  • Standardize event normalization so SOC and IR teams can search by host, path, user, time, and process context where available.
  • Define retention and access requirements that support incident response, audit evidence, and legal or compliance needs.
  • Reduce noise through scoped collection, allowlisting of known high-volume benign paths, and enrichment rather than disabling the telemetry entirely.
  • Regularly test whether analysts can answer basic incident questions such as what file was created, where it appeared, when it appeared, and what local context is available.
Analyst notes and limits

This is a data component, not an attack technique. Its defensive value depends heavily on local logging configuration, endpoint coverage, storage architecture, and SIEM normalization. The supplied ATT&CK object provides examples of possible log sources but no specific detection logic.

Platforms, tactics, relationships, and official detection guidance were not supplied. This take therefore does not assert technique coverage, adversary behavior, active exploitation, or guaranteed detection outcomes.

Official MITRE ATT&CK definition

File Creation

A new file is created on a system or network storage. This action often signifies an operation such as saving a document, writing data, or deploying a file. Logging these events helps identify legitimate or potentially malicious file creation activities. Examples include logging file creation events (e.g., Sysmon Event ID 11 or Linux auditd logs).

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
3.0
Created
Modified
Raw hash
f8df00a285ac8be7...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 3.0 Current bundle f8df00a285ac…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DC0039
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.