A hard link is an additional directory entry that points to the same underlying file content as another name. Attackers can use hard links to hide or preserve malicious files, while defenders should watch for unexpected link counts and avoid assuming a single pathname uniquely identifies a file.
What a hard link actually points to
A hard link is not a copy of a file and not a shortcut to a pathname. It is another directory entry that points to the same underlying file data on disk, so both names resolve to the same inode or equivalent file record. Deleting one name does not delete the content until the last hard link is removed.
This matters because the filesystem tracks the object, not the label. If two names reference the same file content, changes through either name affect the same data, which is why link count is a real signal and pathname alone is not a reliable uniqueness check.
Why hard links behave differently from other links
Hard links are constrained by the filesystem structure, which is why they are usually limited to the same filesystem and typically cannot point to directories. That design prevents cycles and keeps reference counting manageable. By contrast, symbolic links store a target path, so they can cross filesystem boundaries and can become broken if the target moves.
The practical difference is that a hard link preserves identity at the storage layer, while a symbolic link preserves a reference to a name. If your tooling assumes one pathname equals one file, hard links can defeat that assumption without changing the file’s contents at all. CWE Top 25 Guide is useful here because link-following and path-equivalence weaknesses are common failure patterns around file handling.
Operational consequences for defenders and attackers
Attackers can use hard links to preserve access to a malicious file, hide it under an innocuous name, or keep a sensitive object reachable after one path is removed. Defenders should therefore treat unexpected hard links as a filesystem integrity concern, especially when the same inode appears under multiple names in places that should not share content.
Unexpected link counts can also undermine incident response. If an analyst deletes one suspicious filename without checking whether other links still exist, the underlying content may remain active. MITRE D3FEND Guide is relevant because file creation analysis, local file access mediation, and credential and artifact hardening all help reduce this kind of persistence and concealment.
Risk and Threat Considerations
Hard links create a small but real trust problem for file-based controls: they can make a file appear removed, relocated, or separately owned when the underlying content is still present. That becomes material in environments that rely on path-based allowlists, cleanup jobs, quarantine workflows, or manual review of suspicious files.
Failure mechanism: Security tooling or operators key decisions off the pathname instead of the underlying file identity, so a second directory entry preserves access or obscures persistence.
Impact: Malicious content can survive deletion attempts, evade simple inventory checks, or remain reachable through a benign-looking name, which complicates containment and evidence handling.
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 OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-10 — Data Recovery | Hard links affect file integrity and recovery assumptions after deletion or cleanup. |
| Recommendation — Verify file integrity and recovery outcomes after deletion or quarantine actions. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Hard links can preserve malicious content and complicate integrity validation. |
| Recommendation — Validate file integrity and investigate unexpected file identity reuse. | ||
| MITRE ATT&CK | T1096 — NTFS File Attributes | File-system tricks can hide or preserve content under alternate metadata or names. |
| Recommendation — Hunt for filesystem-based concealment and validate object identity, not just pathnames. | ||
| OWASP ASVS | V5 — File Handling | File handling controls must account for alternate file references and path-based assumptions. |
| Recommendation — Enforce file-handling checks that rely on canonical identity, not only filenames. | ||
Practitioner Guidance
What to verify: Check link counts, inode identity, and ownership together before you trust a file deletion, quarantine, or cleanup action. If a suspicious file has more than one hard link, assume there may be additional reachable paths that also need review.
Common mistake: Treating a filename as the file. For investigation and policy enforcement, compare metadata and content hashes where appropriate, then confirm whether multiple directory entries reference the same object.
Practitioner takeaway: Hard links are usually a storage feature, but in security operations they become a visibility problem when teams trust names more than file identity.