How do attackers use Hard Link?

How attackers abuse hard links in practice

Attackers use hard link to make a single file appear under more than one path, which can help them blend malicious content into a trusted location, bypass simple path-based checks, or keep access to a target file after one name is removed. The technique matters most when defenders rely on filename alone instead of the underlying inode or object relationship.

Hard links are especially useful when the attacker wants the file to look ordinary at the path level. A cleanup job may remove one visible name while the file still exists through another link, so the content survives until every link is removed. That makes hard links a persistence and concealment aid rather than a standalone payload.

On Windows and Linux alike, the practical question is whether the system allows creation of links into sensitive areas and whether monitoring can distinguish a true file copy from a second directory entry to the same object. The MITRE D3FEND Guide is useful here because it maps defensive techniques for file control, integrity checking, and artifact analysis to the underlying behaviour defenders need to observe.

What makes hard links attractive to attackers?

Hard links exploit a gap between what a human operator sees and what the filesystem actually stores. If an alert, allowlist, or triage process only inspects a path name, a malicious file can appear harmless when accessed through a different directory entry. This is why hard links are often used to frustrate review, not just to store data.

They can also complicate incident response. If investigators delete one copy by name, the file may still remain reachable through another link, which means cleanup can fail quietly unless the team understands link counts and object identity. In practice, that is the core failure mode: the object survives even when the obvious filename disappears.

For attackers, this creates a low-noise way to preserve access, delay detection, and make forensic work slower. The technique is not about privilege by itself, but about abusing filesystem semantics to make malicious content harder to remove or classify.

That overlap between filesystem semantics and detection is why the technique aligns well with the common weakness pattern documented in the CWE Top 25 Guide, especially where path handling, race conditions, and link-following mistakes create security-relevant gaps.

How defenders should think about detection and cleanup

Defenders should look for unexpected link relationships on sensitive systems, especially where protected files, staging directories, or cleanup targets may be involved. A normal file inventory is not enough if it does not surface link count, inode identity, or filesystem object metadata.

Response should focus on the object, not just the pathname. If a suspicious file is discovered, the response workflow should determine whether other directory entries still reference the same object before assuming deletion is complete. Where possible, validate file identity through metadata, not just by name, size, or location.

The most useful control point is upstream: limit who can create links, monitor for link creation in sensitive areas, and treat link abuse as a sign that cleanup or integrity assumptions may already be wrong. The The State of NHI & AI Agent Breach Report 2026 is a strong companion source for the broader attacker tradecraft pattern of using trusted access paths and residual access to stay hidden after initial compromise.

Risk and Threat Considerations

Hard links become a real security risk when teams trust filenames more than filesystem objects. That can let malicious content survive deletion, evade simple filters, or remain reachable after a path is removed, which increases the chance of persistence and incomplete cleanup.

Failure mechanism: The attacker creates or preserves an alternate directory entry to the same underlying file, so controls that act only on the visible path miss the true object and may leave it accessible.

Impact: Cleanup can fail silently, malicious content can remain active, and responders may believe a system is remediated when the underlying object is still present.

Practitioner Guidance

What to verify: Check whether your file integrity, EDR, or administrative review process records inode or object identity, not just pathname. If it does not, you have a blind spot for hard-link abuse.

Decision rule: If a sensitive file is unexpectedly linked from another location, treat it as a containment issue first and a cleanup issue second. Remove access paths in a way that confirms the underlying object is no longer reachable.

What good looks like: Sensitive systems log link creation, reviewers can distinguish copies from hard links, and remediation validates that no remaining link keeps the object alive.

Practitioner takeaway: Hard-link abuse is most dangerous when operations assume “deleted by name” means “removed in reality”; the defender’s job is to validate object identity, not just pathname hygiene.

Related resources from NHI Mgmt Group

• What is the impact of using hard-coded credentials on security?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?