How do attackers use NTFS hard links?

How NTFS hard links change the attacker’s playbook

An ntfs hard link is not a copy of the file, it is another directory entry pointing to the same underlying file data. That means an attacker can make one payload look like it exists in several places at once, which complicates cleanup, muddies provenance, and can preserve access even after a defender deletes one visible path. Detection has to focus on file identity, not just filenames.

Attackers value hard links because many defensive workflows still reason about paths, not file records. If a trusted utility, scheduled task, or administrator action targets one pathname, a linked path can keep the same malicious content reachable under a different label. That is why file integrity monitoring should compare inode-style identity relationships, link counts, timestamps, and parent-child placement together rather than treating each path as an independent object.

Hard links also help with abuse of trust boundaries. A file that appears in a benign location can be made reachable from a more sensitive or more frequently scanned location, which may influence review, quarantine, or deletion decisions. The useful analyst question is not just “where is the file?”, but “which other paths resolve to the same file object, and which one is the authoritative location for operations?”

Where defenders get blindsided by hard link abuse

Hard link abuse is most effective when defenders rely on single-path investigations, path-based allowlists, or deletion actions that do not verify every reference to the file. A file can be removed from one directory and still persist elsewhere through another hard link, so an apparently successful cleanup may leave the underlying content intact. This is a classic persistence and visibility problem, not a storage quirk.

Attackers can also use hard links to create confusion around attribution and remediation. If a security tool marks one path as suspicious but another trusted path still points to the same file data, responders may see inconsistent results across scanners, backups, or manual review. The risk is greatest when the file is executable, scriptable, or consumed by a privileged process that trusts location more than identity.

For Windows environments, the strongest defensive signal is often unexpected link relationships rather than malicious content alone. A sudden increase in links to a sensitive binary, a file that appears to “move” without a normal rename event, or a deletion that does not reduce the file’s reachability should prompt deeper inspection of file metadata and usage history.

What makes hard link abuse operationally dangerous

Hard links become dangerous when they are used to stretch the life of a file beyond the control assumptions attached to its original path. That can defeat simple containment steps, interfere with incident response, and create a mismatch between what the operator believes was removed and what still exists on disk. The abuse is subtle because the file itself has not been duplicated, only re-exposed through another directory entry.

The problem is compounded when monitoring systems, backup jobs, or cleanup scripts use path-based logic. A tool may conclude that a file is gone, while the same file data remains available through a second path that was never reviewed. In practice, this can delay eradication, preserve attacker tooling, or let a dangerous file survive a partial response.

When the file also carries a trusted name, the attacker may gain an extra layer of camouflage. The danger is not only stealth, but also the possibility that a legitimate maintenance action, software inventory check, or integrity check is pointed at the wrong reference and produces misleading assurance.

Risk and Threat Considerations

Hard links are risky because they break the simple one-path, one-object assumption that many response and integrity workflows depend on. If defenders do not account for all links to the same file record, malicious content can survive deletion, remain reachable through a trusted path, or produce conflicting evidence during investigation.

Failure mechanism: The attacker creates or reuses additional hard links so that a single malicious file remains reachable after one visible path is removed, quarantined, or inspected. Path-centric tooling then underestimates persistence and can miss the surviving reference.

Impact: Cleanup can appear successful while the underlying file data still exists, allowing continued execution, delayed eradication, or mistaken trust in file integrity results. In an incident, that can extend dwell time and complicate scoping.

Practitioner Guidance

What to verify: Check whether the file has multiple links before trusting any deletion or quarantine result. Confirm the file’s identity relationships, not just its pathname, and treat a surviving hard link as an unresolved containment issue.

Decision rule: If a suspicious file can still be reached by another path, treat it as present for remediation purposes until every reference has been accounted for. If the file touches a privileged workflow or trusted location, escalate the review before relying on path-based cleanup.

What good looks like: Investigators can explain which paths point to the same file object, which reference is authoritative, and whether any trusted process can still reach the content after response actions. That is a stronger standard than simply confirming that one filename was removed.

Practitioner takeaway: The key defensive shift is from path thinking to object thinking, because hard links let an attacker keep the same file alive under more than one name.

Related resources from NHI Mgmt Group

• Guide: MITRE D3FEND Guide
• 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?