An NTFS hard link is another directory entry for the same file data on an NTFS volume. Deleting one link does not remove the underlying content until all links are gone. Attackers can use hard links to hide file presence or confuse file-based controls, so defenders track unexpected link counts and paths.
How NTFS hard links represent one file through multiple directory entries
An ntfs hard link is not a copy of a file. It is another name for the same file record on the same NTFS volume, so each link points to the same underlying data and metadata. That means the file content survives until the last link is removed, and path-based tools may see one file through several locations.
Because a hard link is a filesystem reference, not a separate object, permissions, timestamps, and content changes are shared at the file level. The practical consequence is that deletion semantics are count-based, not path-based, which is why hard links can surprise administrators who expect one path to equal one object.
NTFS also treats hard links differently from shortcuts and symbolic links. A shortcut is just a user-facing pointer, and a symbolic link resolves to a target path, but a hard link is an equal peer entry to the same file data. That distinction matters when you are reasoning about file identity, retention, and control coverage. For background on how filesystem artefacts fit into defensive analysis, see the MITRE D3FEND Guide.
Why hard links can confuse detection, deletion, and file integrity checks
Hard links create a visibility problem when defenders rely on a single pathname to represent a file’s presence. If one path is deleted or monitored in isolation, the same file content may still exist under another name, which can hide retention, complicate cleanup, or make an executable appear to disappear while it remains reachable elsewhere.
File-based controls can also be misled when they key only on path or filename. A security tool that trusts the first observed path may miss that the same inode-like file object is still live through another directory entry. That is why link count and unexpected alternate paths are useful review signals, especially on systems where attackers may try to frustrate response workflows or preserve access to a payload.
From a weakness-analysis perspective, hard-link abuse sits close to broader filesystem handling problems such as link-following mistakes, path confusion, and permission edge cases. Those issues are often easier to exploit when tools assume that a file’s name is its identity. The CWE Top 25 Guide is useful context for the kinds of root-cause weaknesses that make pathname-based assumptions brittle.
How to verify, investigate, and control hard links in practice
For defenders, the first step is to confirm whether the file is expected to have more than one link. A high link count is not automatically malicious, but unexpected multiplicity in sensitive directories deserves review because it can indicate deliberate concealment, duplicate placement, or an attempt to keep content alive after cleanup.
Good investigation pairs path review with file identity review. Check which directories reference the same file, whether those paths match normal application behavior, and whether the link count changes in step with creation or deletion events. If the file is executable or script-like, verify whether the same content is reachable through a location that your standard file policy does not cover.
For control design, prefer detection logic that evaluates both the path and the underlying file object relationship. Hard-link awareness should be part of endpoint monitoring, file integrity review, and incident response runbooks, especially where cleanup actions depend on removing a single named file. If you are building detection logic around adversary behavior and filesystem artefacts, the MITRE ATT&CK Enterprise Matrix is a useful companion reference.
Risk and Threat Considerations
Hard links create security risk when teams assume that deleting a path removes the object, or when they treat filename changes as evidence that a file has been eliminated. An attacker can use that gap to retain access to the same file content under a different directory entry, complicate triage, or make file-based controls report an incomplete picture.
Failure mechanism: Path-centric controls, cleanup jobs, or monitoring rules act on one directory entry while other hard links keep the same underlying file data reachable, so the object survives, remains executable, or escapes ordinary deletion workflows.
Impact: Response teams may believe content has been removed when it has not, integrity checks may miss duplicate references, and hostile artefacts can persist long enough to support evasion or re-use.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1036 — Masquerading | Hard-link abuse can hide file presence behind alternate names. |
| T1070 — Indicator Removal on Host | Removing one link while content persists can frustrate cleanup and triage. | |
| Recommendation — Map suspicious file naming patterns to masquerading and hunt for alternate paths. Correlate deletions with remaining file references and residual artefacts. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Link-aware integrity checks help verify file identity beyond path names. |
| AU-6 — Audit Review, Analysis, and Reporting | Unexpected link counts and paths are useful audit signals for investigation. | |
| Recommendation — Verify file integrity using object-aware checks, not pathname alone. Review file activity for unexpected link changes and duplicate references. | ||
Practitioner Guidance
What to verify: Confirm that your investigation and monitoring stack can see link count, full file location set, and the underlying file object relationship, not only the visible pathname. A single suspicious path is often less important than an unexpected pattern of shared file identity across places that should not normally share it.
Decision rule: If a hard link appears in a sensitive directory, treat it as a review trigger when the file is executable, scriptable, or used in a trust-sensitive workflow. If the content is expected and benign, document the exception; if not, assess whether cleanup, replacement, or policy enforcement needs to target every remaining link.
Practitioner takeaway: Hard links are a filesystem identity problem disguised as a naming problem, so the safe way to manage them is to validate object-level presence and path-level reachability together.
Related resources from NHI Mgmt Group
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 October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org