RedirectionGuard: Mitigating unsafe junction traversal in Windows

As attackers continue to evolve, Microsoft is committed to staying ahead by not only responding to vulnerabilities, but also by anticipating and mitigating entire classes of threats. One such threat, filesystem redirection attacks, has been a persistent vector for privilege escalation. In response, we’ve developed and deployed a new mitigation in Windows 11 called RedirectionGuard. This blog outlines how RedirectionGuard proactively closes off a major attack surface by preventing unsafe junction traversal, reinforcing our commitment to secure-by-design-principles and reducing the burden on developers and defenders.

Why is file path redirection a problem?

Problems arise when privileged local Windows services access file paths containing redirection without realizing it. For example, a service may use a temporary folder, C:\MyService, where it stores some data in a file. Once finished, the service deletes everything in C:\MyService with SYSTEM level privileges. But what if an unprivileged user replaces the MyService folder with a junction C:\MyService that points to C:\Windows\System32? Now when the service cleans up its temporary directory, it follows the junction and deletes files in C:\Windows\System32, corrupting important system files.

Past mitigations

File system attacks and mitigations are not new concepts. One previously common attack method involved hard links, which maliciously redirect file operations from one target file to another on the same volume. However, this technique has been largely mitigated by requiring the creator of a hard link to have WRITE_ATTRIBUTES permission on the target file.

Object manager symlinks can only be reached directly through an object manager path, which most local Windows services don’t accept. Otherwise, the file operation must be pointed at the object manager first with another redirection primitive such as a junction. Symbolic links, while powerful, require administrator privileges or developer mode to create, making them unavailable to standard users.

Junctions remain the biggest existing gap. Outside of a sandbox, they can be created by standard users and target any folder on the system. Additionally, they can be combined with other forms of redirection, like object manager symlinks, to effectively redirect both folders and files.

Primitive

Restrictions and Mitigations

Hard links

• Can only target files

• Target must be on the same volume

• Creator must have WRITE_ATTRIBUTES access to target

Object manager symbolic links

• Source must be in the object manager namespace, but destination can be anywhere on the filesystem or in the object manager namespace

• When the creator is sandboxed, processes outside the sandbox will be unable to follow any links created from inside the sandbox

Symbolic Links

• Creator must have administrator privileges or developer mode must be enabled

Junctions

• By themselves can only target folders

• Creator must have FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES access to source

• Source directory must be empty

• When the creator is sandboxed, they must also have FILE_GENERIC_WRITE access to target directory

Given the success of the hard link mitigation, applying a similar approach to junctions might seem straightforward. After all, creators of junctions already need FILE_GENERIC_WRITE access to the destination directory of the junction when sandboxed. So, why not just require FILE_GENERIC_WRITE access to the destination directory for junctions created from outside the sandbox as well? The challenge lies in how junctions are typically used on Windows. While hard links generally target files the creator already has full access to, junctions are used in more varied scenarios. Broadly requiring FILE_GENERIC_WRITE on the target directory would break too many valid scenarios.

Scoping the attack scenario

To create a viable solution, it’s necessary to define the problem in concrete terms. The attack scenario in this case is as follows:

• The attacker has compromised a local standard user on a Windows machine.

• They can create files, folders, and junctions in locations on the local disk according to the compromised account’s permissions.

• They can interact with other programs as that user.

• Their goal is to elevate their privileges to that of a local admin or perform some other privileged operations that the compromised user can’t already do.

Because this is a filesystem-based elevation of privilege attack, the attacker must influence programs that interact with the filesystem and possess permissions to perform privileged operations that they can’t execute themselves. This limits the number of programs affected by potential mitigations, primarily Windows services running with Administrator or SYSTEM privileges. Programs running as other users in a multi-user machine may also be of some interest.

Programs that fit these criteria may be vulnerable to other types of filesystem attacks that don’t leverage junctions. For example:

• A naive service might accept a full path to a file that it then deletes without any redirection needed. In such cases, no change to junctions will mitigate the vulnerability.

• The service may have a relative path traversal vulnerability that allows an attacker to redirect the file operation to any location on the drive.

• If a service is impersonating a compromised user, that user could change their device mappings to redirect the file operation.

In 2024, MSRC released 42 CVEs for path redirection vulnerabilities. Among these cases, only 10 out of 42 involve scenarios where an attacker has full control over the file path, can exploit relative path traversal, or where the service impersonates the compromised user, making them a small minority overall. The remaining 32 cases rely on attacker-created junctions to exploit the service. Given this breakdown, it is reasonable to scope mitigations to only target cases where the attacker doesn’t already have arbitrary control of the target of the file operation through other means.

Threat model

To summarize the threat model, the mitigation assumes an attacker has the following permissions and access:

1. An attacker has compromised a local standard user (non-admin) account and can operate freely on the system subject to the account’s permissions.

2. The attacker can trigger filesystem operations in more privileged processes that run under a privileged (admin) security context or the context of another user.

3. The operations can be of any type and can be triggered any number of times targeting a path. The path can be influenced by an attacker, but they cannot control the start element which must point to an NTFS volume.

The attacker above, after exploitation, would have these general goals:

• Elevation of Privilege

• Execute arbitrary code in the context of a privileged process. This can be achieved through tampering with system code/script files or code/command injection.

• Information Disclosure

• Disclose the contents of files without having permissions to access those files.

• Denial of Service

• Cause information loss or system corruption by deleting or tampering files without having permissions to access those files.

Out of scope

The mitigation cannot prevent exploits that do not rely on junctions or access remote paths, so the following restrictions are placed on the attack scenario:

1. The start of the path is NOT controlled by the attacker AND

2. The start of the path points to an element within the filesystem namespace AND

3. The attacker can NOT do path traversal AND

4. The filesystem is NOT controlled or otherwise compromised by the attacker (i.e. the attacker cannot modify the raw NTFS volume) AND

5. The operation does NOT take place under security impersonation of the compromised account.

Enter RedirectionGuard

To mitigate file redirection vulnerabilities within the defined threat model, RedirectionGuard, a new junction mitigation, must block junction traversal when an attacker is attempting to maliciously redirect a file operation. However, it must also minimize regressions by allowing as many safe junction traversals as possible.

Therefore, junction traversal is only blocked when both of the following conditions are met:

1. The junction is being followed by a process that has opted in to the RedirectionGuard mitigation AND

2. The junction was created by a non-admin user account.

When junctions are created or modified, the privilege level of the creator/modifier is stored in an admin-only alternate data stream with the file. When Redirection Guard is enabled by a process, the process will only follow “trusted” junctions, which are junctions that are one of the following:

1. Were created by an Administrator OR

2. Do not contain the privilege metadata (indicating the junction was last modified prior to the mitigation being available).

This design mitigates all junction file redirection vulnerabilities within the defined threat model. Think back to the earlier example of a service that deletes all the files in some attacker-controlled temporary directory. Previously, the service had to carefully check all folders along the file path for any forms of redirection. These checks had to be performed around every file operation, taking significant development time, slowing down the program, and increasing code size. The only way for an attacker to redirect the file operations is with a junction, so with the mitigation enabled, any junction created by an attacker will be marked as untrusted and cause the file operations to fail. By simply adding a few lines of code to enable the mitigation, developers can secure all file operations in their program against path redirection bugs.

Enabling RedirectionGuard

As mentioned earlier, many processes would not benefit from enabling this mitigation because they either don’t run with elevated permissions or don’t interact with the filesystem in an exploitable way. To avoid potential compatibility issues, the mitigation is opt-in. The focus is on enabling the mitigation in components with a history of filesystem redirection vulnerabilities first. The User Profile Service, AppX Deployment Service, and Installer Service, three of the top sources of path redirection CVEs, have already enabled the mitigation in Windows Insider builds.

The easiest way to enable the mitigation for a program is through code using the SetProcessMitigationPolicy API. It can be enabled in audit mode to log violations in event log, or in enforce mode to block junction traversal. Here is an example of how a program might do that:

ULONG
SetProcessMitigationMode(
    _In_ MODE_OPTION Option
    )
{
    ULONG Error = ERROR_SUCCESS;
    PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY ReparsePointPolicy = {0};

    if (Option == MODE_OPTION::Enforce) {
        ReparsePointPolicy.EnforceRedirectionTrust = 1;
    } else if (Option == MODE_OPTION::Audit) {
        ReparsePointPolicy.AuditRedirectionTrust = 1;
    }

    if (!SetProcessMitigationPolicy(
            ProcessRedirectionTrustPolicy,
            &ReparsePointPolicy,
            sizeof(PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY))) {
        Error = GetLastError();
        LogError(Error, "Failed to set image mitigation policy options");
    }

    return Error;
}

For testing and research purposes, it is possible to see if a process has the mitigation enabled using James Forshaw’s NtObjectManager PowerShell module. To check all mitigations enabled for a running process with PID 1496, for example, use the command:

Get-NtProcessMitigations -ProcessId 1496

This command can be run without any process ID to list the mitigations of all currently running processes.

Bug bounty

RedirectionGuard is part of our Windows Insider Preview bounty program along with generic path redirection vulnerabilities. A RedirectionGuard bypass is a path redirection vulnerability within the scope of the threat model that can still be exploited despite the mitigation being enabled. If you believe you have found a path redirection vulnerability or RedirectionGuard bypass, please write up a report with a proof of concept and submit via our MSRC Researcher Portal.

Conclusion

RedirectionGuard is a mitigation many Windows services rely on to prevent path redirection vulnerabilities. With each new release, more services are enabling it, closing off an attack vector that was once the second most common source of Windows MSRC cases.

Thanks

Special thanks to Georgios Baltas for his prior contributions to the mitigation’s development, and to James Forshaw for providing feedback during development and for the NtObjectManager PowerShell module.