Windows Hard Link

How Windows Hard Links Work

A hard link is not a copy of a file. It is another directory entry that points to the same file record, so the content, metadata, and access state are shared until the last link is removed. That is why a file can appear under more than one name while still being a single underlying object.

This behaviour is normal file-system functionality, but it matters because name-based logic can be misleading. If a control, script, or review process assumes that one path equals one file, the same object can be reached through another name and the security decision can drift away from the actual file being acted on.

Why Hard Links Are Security-Relevant

Hard links become risky when security tooling or privileged software reasons about a file by path alone. An attacker who can create or preserve a hard link may influence what a trusted process opens, modifies, archives, or deletes, even though the process believes it is handling an ordinary file in a benign location.

That makes hard links useful for confusion, persistence, and access preservation. The same object can be reachable through multiple names, so path-based checks, allowlists, and cleanup routines may miss the real target unless they verify the object identity behind the name.

File-system semantics are the important issue here, not the link name itself. The NTFS hard link behaviour discussed in defensive technique catalogues is a reminder that defenders should reason about object identity, link count, and file metadata together.

Common Abuse Patterns

Attackers may use hard links to preserve access to sensitive content after a file is moved, renamed, or partially cleaned up. They may also use them to make a monitored or protected file look ordinary, or to steer privileged activity toward an object that should not have been reachable through that path.

On Windows, the abuse often becomes more effective when paired with privileged automation, maintenance jobs, or security tools that trust file names too much. If a process acts on a path without checking whether it is the expected file object, a hard link can turn an ordinary operation into an unintended security action.

Defensive knowledge of file identity validation aligns with the MITRE D3FEND Guide, which maps file and process artefacts to countermeasures such as file content verification and local file access mediation.

Detection and Defensive Handling

Detection starts with inventorying where hard links exist and which processes interact with them. Defenders should compare file identity, not only filename, when reviewing suspicious modifications, unexpected deletions, or access to high-value files. That includes checking whether multiple paths resolve to the same on-disk object.

Good defensive handling also means tightening write access to directories where hard links matter, limiting privileged file operations, and validating file metadata before a trusted process takes action. Windows hard links are often visible only when you look for them explicitly, so audit and telemetry should include file-object relationships, not just path events.

For broader weakness patterns that lead to path confusion, the CWE Top 25 Guide is useful background because several weaknesses in that family involve path equivalence, race conditions, and insecure file-handling assumptions.

Risk and Threat Considerations

Hard links create risk when security logic treats a filename as a trustworthy security boundary. That can let an attacker preserve access to sensitive data, influence privileged file handling, or hide the true object being acted on by tools that only inspect the visible path.

Failure mechanism: A trusted process or control validates the path, but not the underlying file object, so a second name to the same object defeats the intended separation between “safe file” and “sensitive file.”

Impact: The result can be unauthorized disclosure, unintended modification, persistence of access to protected content, or manipulation of privileged workflows that were assumed to be acting on a different file.

Practitioner Guidance

Why practitioners should care: Hard links are a low-level file-system feature, but they become a security issue whenever privileged tools, cleanup jobs, or monitoring workflows rely on names instead of file identity. That is a common and easy-to-miss failure mode in Windows environments.

What to watch for: Investigate unexpected link counts, suspicious file reuse across directories, and privileged processes touching files that do not match their normal object-level identity. When in doubt, verify the object behind the path before trusting the action.

Related resources from NHI Mgmt Group

• Why do native Windows tools make persistence hard to detect?
• What are the signs that Windows Server licensing is becoming hard to manage?
• Hard Link
• NTFS Hard Link