NtCreateFile is a Windows native system call that creates or opens a file, directory, or named pipe. It exposes low-level control over file access, sharing, and attributes, and is used by the operating system, applications, and malware that need direct file I/O.
What NtCreateFile Does
NtCreateFile is the Windows native file-system call used to create or open files, directories, and named pipes directly through the kernel interface. Because it sits below higher-level Win32 APIs, it exposes precise control over desired access, sharing, disposition, and file attributes, which makes it both powerful for system software and attractive to malware.
At a practical level, NtCreateFile is less about “making a file” than about requesting a specific object state from the Windows object manager and file system stack. That includes whether an object should be opened or created, what access should be granted, whether other processes may share the handle, and how the file system should treat the request if the object already exists or does not yet exist.
Why Native File Creation and Open Semantics Matter
The security significance of NtCreateFile is in its low-level semantics. A caller can shape file access in ways that affect data integrity, locking behaviour, handle sharing, and whether security checks succeed or fail. In Windows, these details can determine whether software behaves reliably under concurrency, whether a process can write to protected locations, and whether a security tool can intercept or monitor the operation cleanly.
This is also why the call is heavily used by system components, EDR products, installers, backup tools, and malware. Native file I/O can bypass assumptions built into higher-level libraries, reduce visible abstraction layers, and make behaviour harder to interpret from user-mode telemetry alone.
How NtCreateFile Is Used in Real Systems
In legitimate software, NtCreateFile is common when a program needs exact control over file disposition, reparse handling, or device-like paths that standard library calls do not express well. It is also used for named pipes and directories, so the term covers more than ordinary document creation. The same flexibility helps software implement atomic writes, log rotation, locking strategies, and controlled access to shared resources.
In offensive tradecraft, the same interface can support stealthy staging, persistence, or tampering with files that defenders expect to be accessed through normal application paths. That does not make the call malicious by itself; it means analysts should interpret it in context, especially when the calling process, path pattern, and follow-on behaviour look unusual.
Security Monitoring and Defensive Interpretation
Defenders should treat NtCreateFile activity as one signal among many, not as a verdict. Suspicious use often becomes meaningful when combined with unusual parent processes, unexpected directories, repeated failures on protected paths, or a pattern of file creation followed by execution or modification. High-fidelity monitoring needs context about the process image, requested access, target path, and whether the call was part of a normal application workflow.
It is also useful to distinguish direct native API usage from benign software that simply depends on lower-level Windows libraries. Security teams should avoid over-alerting on the API name alone and instead focus on what object was targeted, which access rights were requested, and whether the resulting file activity matches expected system behaviour.
Risk and Threat Considerations
NtCreateFile is sensitive because it gives a process direct influence over one of the most common persistence and tampering surfaces in Windows, the file system. Abuse of the call can support data modification, staging, hidden dropper behaviour, or manipulation of files and pipes that other controls assume are benign.
Failure mechanism: A malicious or compromised process can use native file-open and file-create semantics to write, replace, or access objects in ways that are difficult to distinguish from normal system activity, especially when higher-level application logs are absent.
Impact: The result can be loss of integrity, stealthier malware execution, weaker forensic clarity, and greater difficulty proving whether a file was legitimately accessed, created, or modified.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Native file calls can request more access than needed, so least privilege limits file-system abuse. |
| AU-2 — Event Logging | NtCreateFile activity is best interpreted through logged file-system events and process context. | |
| Recommendation — Restrict file access rights to the minimum needed for each process. Log file-create and file-open activity with process and path context. | ||
| MITRE ATT&CK | T1055 — Process Injection | Native file activity often accompanies malware staging, unpacking, or injection workflows. |
| Recommendation — Correlate suspicious file creation with downstream process injection behaviours. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | File-access investigations depend on retained, searchable logs of suspicious object access. |
| CIS-10 — Malware Defenses | Malware commonly uses low-level file I/O during staging, dropping, and persistence. | |
| Recommendation — Centralise and retain logs needed to investigate suspicious file activity. Inspect file-system activity for malicious payload staging and persistence patterns. | ||
Practitioner Guidance
What to watch for: Focus on the combination of caller, target path, access mask, and follow-on activity rather than the API name alone. NtCreateFile becomes operationally meaningful when it appears in unusual processes, sensitive directories, or workflows that do not normally require native file access.
Governance implication: Security operations should define which software is expected to use native Windows file APIs and treat everything else as an exception worth explaining. That gives analysts a clearer baseline for detecting abuse without drowning in false positives.
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org