An NTFS junction point is a reparse point that redirects a directory path to another directory on the same machine. It is often used for compatibility or path redirection. Attackers can abuse junctions to redirect tools, hide locations or influence file access, so defenders check for unexpected reparse points and path changes.
How an NTFS junction point redirects a path
An NTFS junction point is a directory-level reparse point. When a process opens the junction path, Windows resolves that path to a different directory on the same machine and then continues file operations there. The junction itself does not copy data or create a second folder, it changes where the path resolves at access time.
That distinction matters because the junction behaves like a normal directory to many tools until they explicitly inspect the reparse metadata. A path can therefore appear local and ordinary while actually landing somewhere else on disk, which is why administrators often need to resolve the target rather than trust the visible path alone.
Junctions are useful for compatibility, migration, and legacy path preservation. In practice, they let older software keep using a familiar directory name while the real storage location changes underneath it. The same mechanism also means a change in directory layout can be introduced without rewriting every application path that points to the old location.
Why junction points affect security and file handling
Because junctions change path resolution, they can influence which files, folders, or tools are reached during access. That is why defenders treat unexpected reparse points as a control issue, not just a filesystem curiosity. A path that is redirected without approval can alter backup scope, script behavior, update locations, or where administrative tools read and write.
Attackers can abuse that same redirection to hide content, mislead operators, or steer a trusted process toward an unintended directory. If a security tool, installer, or maintenance task follows the redirected path blindly, the junction can create a different effective target than the one the operator thought was being used. MITRE ATT&CK Enterprise Matrix is useful here because junction abuse often shows up as a technique for redirecting execution or data flow through ordinary filesystem activity.
Junctions are especially important in environments that depend on fixed paths, elevated maintenance tasks, or automated file operations. A benign-looking directory move can become risky if a privileged process traverses a redirected path, so path validation and target inspection are part of safe handling. NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with this because it supports configuration, integrity, and access controls around filesystem behavior.
How to confirm and control junction behavior
The first step is to verify whether a directory is a junction before you trust its apparent location. On Windows, that means checking reparse-point metadata and confirming the real target path, especially for administrative shares, migration directories, backup trees, and any folder touched by privileged automation. If the target is unexpected, treat it as a configuration or security finding.
Control is mostly about limiting surprise. Keep junction use documented, review directory changes that introduce reparse points, and make sure operational tools report the resolved path rather than only the apparent one. NIST Cybersecurity Framework 2.0 supports this operational discipline by tying together asset visibility, protective controls, and detection of unauthorized change.
For systems that rely heavily on path redirection, the safest pattern is to separate compatibility use from security-sensitive storage. NIST AI Risk Management Framework is not about NTFS itself, but its broader risk-thinking reminder applies: understand the dependency, the trust boundary, and the failure mode before you let automation act on it.
Risk and Threat Considerations
Junctions create a trust problem when software assumes a visible directory name is the final destination. A redirected path can cause privileged tools to read, write, delete, or scan a different location than intended, which can affect integrity, detection, and recovery.
Failure mechanism: An attacker or misconfiguration introduces or changes a junction so that a trusted process follows the redirect and operates on an unintended directory. That can hide files, defeat location-based checks, or steer maintenance and security tooling away from the real target.
Impact: The result can be data exposure, missed scanning, incorrect cleanup, broken backups, or unintended privilege effects if elevated software follows the redirect. In the worst case, path redirection becomes a persistence or evasion aid inside an otherwise normal Windows file workflow.
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 NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | Junction abuse can support path-based persistence or execution redirection. |
| Recommendation — Map suspicious reparse-point use to ATT&CK and investigate path redirection as a persistence or evasion path. | ||
| NIST CSF 2.0 | DE.CM-01 — Anomalies and Events | Unexpected junctions are observable filesystem anomalies that need monitoring. |
| Recommendation — Monitor for unauthorized reparse-point changes and alert on unexpected directory redirection. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Junctions can alter integrity expectations for file paths and trusted operations. |
| CM-2 — Baseline Configuration | Approved filesystem redirection should be part of the documented system baseline. | |
| Recommendation — Validate directory targets before trusted processes act on redirected paths. Document and review approved junction usage as part of the system configuration baseline. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detecting unwanted junction changes depends on logging and review of filesystem events. |
| Recommendation — Collect and review filesystem and privilege activity that shows unexpected path redirection. | ||
Practitioner Guidance
What to verify: Before trusting a directory in an incident review, patching task, or cleanup job, confirm whether it is a real folder or a reparse point and record the resolved target. If the path feeds privileged automation, verification should happen before execution, not after.
Common mistake: Treating junctions as harmless because they are “just filesystem shortcuts.” That shortcut thinking breaks down when backup software, deployment tooling, or security scanners follow the redirected path without warning.
Practitioner takeaway: The security question is not whether the junction exists, it is whether any trusted process is allowed to act on the redirected target without explicit review.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org