A Windows hard link issue occurs when multiple directory entries reference the same underlying file data, which can confuse access checks, auditing, or file management logic. Attackers may use hard links to redirect trusted processes toward sensitive content or preserve access after deletion. Defenders should verify file identity carefully, control link creation, and avoid trusting path names alone.
Why a Windows hard link issue happens
A hard link issue starts with how NTFS stores file identity. A hard link is another directory entry for the same file record, so the name you see is not the same thing as the data object being accessed. Problems appear when software assumes a path uniquely identifies a file, or when deletion, permission changes, or logging logic only tracks one name.
That design becomes security-relevant because a trusted process may open one path while the underlying file content is reachable through another. If defenders or applications rely on path-based checks alone, hard links can create mismatches between what is displayed, what is audited, and what is actually read or modified. The issue is therefore usually a metadata and trust problem, not a storage corruption problem.
On Windows, the practical failure mode is that multiple names can point to the same content while access decisions are made elsewhere. If a service writes to a file after checking a benign path, an attacker who can create or preserve a hard link may be able to steer that write toward a different location with the same file record. This is why hard link handling matters anywhere file identity influences privilege or integrity decisions.
What attackers and defenders should watch for
Attackers use hard links because they can preserve access to content even after one filename is removed, and because they can confuse tools that think in terms of folders and names rather than file records. That can support redirection of trusted file operations, concealment of a target path, or persistence of access to material that administrators believe has been cleaned up. The weakness is strongest when the application runs with elevated rights and does not revalidate the object it is about to touch.
Defenders should treat link-aware file handling as a verification problem. The important question is not just “what is the path?” but “what object is this path actually bound to right now?” Tools and scripts that enumerate files, apply permissions, or make cleanup decisions need to account for hard links, especially in directories where sensitive content, temporary files, or privileged service activity coexist. CWE Top 25 Guide is useful context here because file identity, path equivalence, and TOCTOU-style weaknesses often show up together in the same failure pattern.
For deeper defensive coverage, link following and object mediation issues are also usefully framed through MITRE D3FEND Guide, which helps map how to detect suspicious file relationships and constrain file access paths. If you need a broader adversary view, MITRE ATT&CK Enterprise Matrix is the right reference for understanding how credentialed access and file abuse can combine in a real attack chain.
How to reduce hard link exposure on Windows
Prevention starts with controlling who can create links and where privileged processes operate. If ordinary users can create links in directories that privileged software later processes, the trust boundary is too loose. The safer pattern is to restrict link creation, verify file identity at the point of use, and avoid writing sensitive outcomes into locations that untrusted actors can influence.
When patching or redesigning is not immediate, use compensating controls that reduce the chance of path confusion. Review services that delete, rename, move, or overwrite files after a preliminary check, because those are the operations most likely to be redirected by a hard link. Also examine cleanup scripts and backup workflows, since they can silently preserve or propagate the wrong file object if they rely on names alone. A practical hardening baseline is often easier to enforce through CIS Benchmarks, especially where operating system configuration and file-system permissions need to be tightened consistently.
Risk and Threat Considerations
Hard links become dangerous when a process with more privilege than the attacker trusts filename context more than file identity. That can turn an ordinary file operation into an integrity or exposure problem, especially where cleanup, logging, or service-account actions touch sensitive paths.
Failure mechanism: A privileged process resolves a path, but the underlying object is shared through another directory entry, so the process acts on content different from what the security logic assumed.
Impact: The result can be unauthorized modification, concealment of access, retention of sensitive content after deletion, or audit records that do not accurately reflect the object actually used.
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, 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 |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Hard link abuse is reduced by tighter OS and file-system hardening. |
| Recommendation — Harden file-system and account settings to limit who can influence privileged file operations. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Privileged file operations are the main abuse path for hard-link redirection. |
| AU-9 — Protection of Audit Information | Hard links can distort file audit trails and make object tracing unreliable. | |
| Recommendation — Limit privileged file access so untrusted users cannot steer trusted file actions. Protect audit evidence so file identity and access records remain trustworthy. | ||
| MITRE ATT&CK | T1096 — NTFS File Attributes and Alternate Data Streams | Windows file-system abuse includes object tricks that alter how files are handled. |
| Recommendation — Map file-system abuse to ATT&CK and hunt for suspicious object redirection activity. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions and Authorizations | Hard-link issues are driven by incorrect assumptions about who may influence file access. |
| Recommendation — Enforce permission checks that prevent untrusted users from influencing privileged file access. | ||
Practitioner Guidance
What to verify: Before trusting file-handling code, confirm whether it validates the object itself, not just the path string. Any workflow that uses a temporary file, cleanup step, or privileged write should be reviewed for link-awareness.
Common mistake: Treating “deleted” as equivalent to “unreachable” is unsafe on NTFS when another directory entry still references the same file record. That assumption is where many operational surprises begin.
Practitioner takeaway: The real control objective is object identity, not path familiarity. If a Windows workflow can affect sensitive data, it must be designed so that link tricks do not change what the process believes it is reading, writing, or deleting.