How do attackers use NTFS junction points?

How NTFS junction points help attackers redirect trust

NTFS junction points let an attacker make one directory path resolve to another location on disk. That matters because many tools and workflows trust the visible path, not the resolved target, so the same content can be checked in one place and executed, loaded, or consumed from another.

In practice, this technique is useful when an attacker wants a benign-looking path to point at a malicious directory, a staged payload, or a different copy of a file tree. It is especially effective when security logic makes decisions before path resolution is fully understood, or when operators rely on folder names and location-based allowlists.

Where junction abuse creates operational blind spots

Junction abuse is most effective against path-based checks, file validation routines, backup or sync jobs, and security tooling that records the apparent path but not the final resolved target. The same issue can also confuse investigators if they compare only the displayed directory name instead of the reparse point chain and the real destination.

Attackers may use this to hide malicious content in a trusted-looking tree, redirect scanning away from the real payload, or influence software that assumes a directory lives in one location when it actually points elsewhere. The defensive problem is not the junction itself, but the gap between what the system shows and what the file system will actually follow.

That gap is a classic file-system integrity problem, and defensive countermeasure guidance for MITRE D3FEND Guide is useful here because it frames how to validate file artifacts, follow real path resolution, and detect suspicious link-like objects instead of trusting surface paths alone.

How defenders should confirm and contain the abuse

Validation should start with the resolved target, not the apparent folder name. Review reparse points, compare the visible path with the actual destination, and check whether the junction creates an unexpected hop into a privileged, writable, or execution-relevant location. If a junction is present in a sensitive workflow, treat it as part of the attack surface rather than a harmless filesystem convenience.

When the path is used for execution, loading, installation, or content staging, verify whether the linked target can be modified by a lower-privilege account. If it can, the junction may be giving an attacker a way to influence code or content that appears to come from a trusted path. File integrity checks and allowlists are only reliable when they account for the resolved target, not just the original pathname.

For broader attacker tradecraft around redirected paths, file abuse, and persistence-adjacent placement, the patterns documented in The State of NHI & AI Agent Breach Report 2026 are relevant because attackers often exploit trust boundaries by moving through places defenders assume are safe.

Practitioner Guidance

What to verify: Check whether the junction points into a directory that changes execution, trust, or write access. A junction is most suspicious when it redirects into a location that would normally be protected, scanned differently, or excluded from standard review.

Decision rule: If the apparent path and the resolved target would receive different security treatment, investigate before allowing the workflow to proceed. If the difference changes who can write, what can execute, or what gets scanned, treat it as a security-relevant condition rather than a cosmetic filesystem feature.

Common mistake: Analysts often inspect only the named folder and miss the target object entirely. The practical check is to resolve the path end-to-end and compare permissions, ownership, and content at the final destination.

Practitioner takeaway: Junction abuse is dangerous because it turns path trust into a control bypass, so the real control is verifying the resolved target wherever a directory name is used to make a security decision.

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?