An NTFS link is a file system reference that lets one path point to another object on an NTFS volume, such as a file or directory. It can simplify access but also obscure the real target. Defenders verify the target path, ownership and creation context, especially when access controls or malware investigations depend on location.
What an NTFS link actually does
An ntfs link is a filesystem pointer, not a second copy of the data. It lets one pathname resolve to another object on the same NTFS volume, which means users and tools may follow the link and reach the target transparently. The practical effect is convenience, but also a gap between the name you opened and the object you actually touched.
The key operational detail is that the link changes path resolution, not the underlying object’s existence or contents. That is why defenders care about the target path, the link type, and the context in which it was created. A link can make a legitimate location easier to reach, or it can make an unexpected target harder to notice during review.
How NTFS links are used in practice
NTFS supports several link-like behaviors, including hard links, junction points, and symbolic links. They differ in what they can point to and how the filesystem resolves them, but the security question is similar in each case: does the name the operator sees match the object that is really being accessed? That distinction matters for file handling, incident response, and system administration.
Operationally, links are useful for compatibility, legacy pathing, software migration, and convenience when multiple paths need to reach the same content. They also create ambiguity when tools report a directory or file path without clarifying whether it is the link itself or the destination. When review depends on location, path-based assumptions are not enough on their own.
Because NTFS links are part of normal filesystem behavior, they are not inherently suspicious. The issue is control and traceability: who created the link, what it points to, whether it crosses trust boundaries, and whether the destination’s permissions and ownership still match the intended use. Those questions become especially important when the link is used to disguise access to sensitive locations or to redirect activity into an unexpected tree.
Why NTFS links can complicate security analysis
NTFS links can obscure the real target path and create a mismatch between visible structure and effective access. That can matter in malware analysis, where a payload may be launched from an apparently benign location, or in access-control reviews, where a user appears to interact with one path while the underlying object has different permissions or provenance. For deeper defensive mapping, the MITRE D3FEND Guide is useful because it frames file, path, and artifact analysis as part of control coverage and detection design.
Links also affect how defenders reason about integrity. If a directory entry is only a reference, then a path listing alone may not tell you whether the target changed, whether a privileged actor created the reference, or whether a malicious actor abused the reference to blend in with expected filesystem structure. That is why NTFS link review often belongs alongside broader file-system and artifact inspection rather than as a standalone check.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | NTFS links can redirect access to objects with different permissions. |
| AU-3 — Content of Audit Records | Link use and creation context matter when tracing filesystem activity. | |
| SI-7 — Software, Firmware, and Information Integrity | Links can obscure the true object accessed during integrity-sensitive reviews. | |
| Recommendation — Enforce least privilege on file and directory access paths that links may expose. Record the object path, target, and actor context in file activity logs. Validate the resolved target before relying on filesystem integrity checks. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Path-based access decisions can shift when a link resolves to another object. |
| Recommendation — Verify resolved object access before granting or reviewing file-system permissions. | ||
| MITRE ATT&CK | T1020 — Data Exfiltration | Filesystem indirection can help hide movement toward sensitive data locations. |
| Recommendation — Hunt for unexpected link-based access paths when tracing data movement. | ||
Practitioner Guidance
What to verify: Confirm the exact target, the link type, and the creation context before trusting what a path appears to represent. If a review, containment action, or access decision depends on a location, resolve the link and inspect the destination object directly rather than relying on the displayed pathname alone.
What practitioners underestimate: The link itself is often less important than the trust boundary it can blur. A benign-looking reference can still point to content with different ownership, permissions, or sensitivity, so path-based allowlists and manual triage can miss the real exposure if they do not resolve links.
Practitioner takeaway: Treat NTFS links as a name-resolution feature with security consequences, not as a data object in their own right, and always validate the destination before making an access or investigation decision.