An NTFS hard link is a directory entry that points to the same file data as another name on the same NTFS volume. Attackers may use it to disguise modified files, preserve access after renaming, or complicate detection. Defenders should verify file identity, permissions, and unexpected link counts.
What an NTFS hard link does
An NTFS hard link is not a copy of a file, it is another directory entry that resolves to the same underlying file data on the same NTFS volume. That makes the object logically “one file, many names,” which is useful for storage efficiency but important for evidence handling and file trust.
Because the file content is shared, changing the data through any one name changes what all linked names point to. That is why defenders often inspect link counts and path history rather than assuming a file’s current name tells the whole story.
Why hard links are useful and why they are easy to misuse
Hard links are legitimate filesystem features, but they can create ambiguity in investigations and content control. A renamed file can still remain reachable through an older link, and a malicious actor can use an alternate link name to keep access to modified content or make a changed file look less suspicious.
The security issue is not the link itself, it is the way it can separate file identity from filename-based assumptions. That matters when teams rely on directory paths, simple allowlists, or file renaming as a trust signal.
How NTFS hard links affect detection and verification
Detection usually has to move beyond name-based checks. File identity should be verified through metadata, link count, timestamps, permissions, and where possible hashes or other integrity checks on the underlying content. That is especially important when the same bytes are reachable through several paths.
Windows investigators also need to distinguish hard links from other NTFS link types such as junctions and symbolic links. MITRE D3FEND Guide is useful here because it frames defensive artifact analysis, file verification, and local file access mediation in terms that map well to this kind of filesystem ambiguity.
Operational and security implications for defenders
Hard links mainly matter when an organisation is trying to prove what changed, what still exists, and whether a file is being used in an unexpected way. They can complicate incident response, endpoint triage, software integrity checks, and forensic timelines, especially if analysts only review one visible path.
Teams should treat unexpected link counts as a signal to look for stealthy modification, persistence through alternate names, or tampering with trusted file locations. MITRE ATT&CK Enterprise Matrix helps place those behaviours in the wider context of defense evasion and file-system abuse, while CIS Benchmarks provide hardening guidance that supports tighter local file and system configuration discipline.
Risk and Threat Considerations
Hard links are attractive in post-compromise scenarios because they can preserve access to a file after a rename, obscure that a file has been altered, and make path-based monitoring less reliable. They are also useful for blending malicious or tampered content into ordinary filesystem activity.
Failure mechanism: Security tools or analysts key off the filename instead of the underlying file object, so the same content appears trustworthy under one path and suspicious under another.
Impact: Modified files can be missed during review, malicious changes can persist longer, and incident responders may draw the wrong conclusion about what was executed, replaced, or retained.
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 | T1036 — Masquerading | NTFS hard links can hide a changed file behind another name. |
| Recommendation — Hunt for masquerading paths and validate file identity, not just filenames. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Hard links can complicate integrity and malware detection on endpoints. |
| Recommendation — Strengthen endpoint defenses and integrity checks around suspicious file paths. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | File identity verification and unexpected link counts support integrity validation. |
| Recommendation — Apply integrity checks to confirm the underlying file object has not been altered. | ||
Practitioner Guidance
What to watch for: Investigate files that appear in multiple locations with unexpected link counts, especially when the file is in a sensitive path or is tied to startup, tooling, or administrative activity. Use the link count as a prompt to validate whether the object is genuinely expected to have multiple directory entries.
Governance implication: Treat file identity checks as part of integrity assurance, not just malware hunting. Where the file matters operationally, build review steps that confirm content identity and permissions rather than trusting the visible pathname alone.