How do attackers use NTFS links?

What NTFS links let attackers do

NTFS links give an attacker a second way to point at the same underlying file or directory, so a tool may follow one path while a human reviewer sees another. That makes links useful for hiding staging locations, disguising file movement, and steering software toward a target the operator did not intend to inspect.

The practical issue is not just renaming. A link can change how a path is interpreted, so defenders need to know whether they are looking at a real object, a hard link, a junction point, or a symbolic link before they trust what the pathname appears to mean.

On Windows systems, this matters because security tooling, backup jobs, synchronisation tools, and incident responders often reason from paths. If a link crosses from a trusted directory into an untrusted one, or vice versa, the apparent location can be misleading even when the underlying file content is unchanged.

Why links are useful for concealment and path confusion

Attackers use NTFS links to create ambiguity between the visible path and the real storage location. That can help them keep malicious files inside apparently normal folders, disguise where execution will occur from, or preserve access to the same content after cleanup activity has removed only one reference.

They are also useful for evasion because many investigations begin with directory names, timestamps, and location-based trust assumptions. If a defender assumes that a path label is proof of provenance, the attacker can exploit that assumption by making the path look benign while the target still resolves to an undesirable object.

When defenders investigate file-based persistence or malware staging, the relationship between trusted and untrusted locations matters more than the label on the path itself. The safest interpretation is to verify object identity, not just pathname text. A useful defensive reference for artefact-focused detection is the MITRE D3FEND Guide, which helps map file and path-related behaviour to defensive techniques.

How defenders should validate and respond

Verification should start with object resolution. Check whether the item is a regular file, directory, junction, hard link, or symbolic link, and compare the resolved target against expected trust boundaries. If a link connects a high-trust location to a low-trust one, treat that as a meaningful investigative lead, not just a filesystem quirk.

Response should focus on impact rather than the link alone. If the link is part of persistence, staging, or tampering with a security control, review the resolved target, nearby execution artefacts, and any process that created or modified the link. A broader breach-focused reference point is The State of NHI & AI Agent Breach Report 2026, which highlights how attackers abuse access paths and artefacts to hide activity and move laterally.

When a suspicious link is found, the response decision is usually to preserve the evidence, inspect the resolved target, and determine whether the link was used for concealment, privilege boundary crossing, or tool redirection. If cleanup is needed, remove the malicious reference and the underlying abuse path, not just the visible name.

Risk and Threat Considerations

NTFS links create a trust problem because they separate what a reviewer sees from what the operating system may actually open, enumerate, or execute. That can undermine audit quality, conceal malicious placement, and let a threat actor preserve access to a target through an alternate reference even after one path is discovered.

Failure mechanism: A defender or tool trusts the visible path name instead of resolving the link target, so a malicious object appears to live in a safe location or a cleanup action misses an alternate reference to the same data.

Impact: The attacker can hide staging content, interfere with investigation, bypass path-based assumptions in tooling, or maintain persistence through additional references that survive partial remediation.

Practitioner Guidance

What to verify: Confirm the object type and the resolved destination before you trust any file path in an alert, script, backup set, or triage note. Path text alone is not enough when links are present.

Decision rule: If a link crosses trust boundaries, points into a suspicious directory, or is used by a security-sensitive workflow, treat it as a high-priority artefact and inspect the target as well as the link source.

Common mistake: Deleting only the visible alias or excluding the apparent folder from review while leaving the underlying malicious object, alternate reference, or redirected execution path untouched.

Practitioner takeaway: The main defensive question is not “what does the path say?”, it is “what object will the system actually follow, and does that object belong in this trust boundary?”

Related resources from NHI Mgmt Group

• 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?
• How do attackers turn stolen npm secrets into broader compromise?