Hacking Windows Defender Protection Using the Folder Redirection Trick

The technique described below is provided solely for educational and defensive research purposes. Red Dog Security does not endorse or authorize its use to compromise systems or bypass protections, and disclaims any liability for misuse or damages arising from implementation. If you believe you’ve discovered a security issue, please contact the vendor or Red Dog Security to arrange responsible disclosure.

I. Why this matters
Antivirus and Endpoint Detection and Response (EDR) systems are central to endpoint security. Attackers therefore devote significant effort to bypassing or disrupting these protections. Historically, techniques range from exploiting vulnerable drivers to manipulating update and service mechanisms. Understanding these attack vectors is essential for defenders and system architects.

This article examines a class of risks that arises from how protective software locates and selects its runtime components during updates. While the details of an exploit are included here, the goal is to explain the attack surface, highlight operational risk, and show how defenders can reduce exposure.

This article will show you a simple method for hacking the folder containing Windows Defender's executable files. Thanks to this technique, you can hijack control of the Defender service, insert your own libraries, damage critical files, and even disable the service. Most importantly, all this is done using the standard tools of the Windows OS itself, without additional utilities.

II. Method Details

1. Where does the Windows Defender service get its executable files?
   Defender's files are stored in a special directory:

ProgramData\Microsoft\Windows Defender\Platform\[Version]

Every time an update is installed, a new subfolder is created with the number of the current version, where the fresh executable files for the WinDefend service are placed.

Every time an update is installed, a new subfolder is created with the number of the current version, where the fresh executable files for the WinDefend service are placed.
What happens when Windows Defender switches from a previous version to a new one?

• It enumerates all existing versions by calling the QueryDirectory function in the Platform folder.
• It selects the folder with the highest version number, meaning the newest available version.
• It creates a new instance of the Defender service with the executable from the selected folder, after which the old process is terminated.
• It updates the configuration of the WinDefend service to point to the new folder; from this point on, the service will run from the specified folder until the next version appears.

Windows Defender always prohibits writing files to its working directories, and the Platform folder is no exception. But what happens if I create a new folder instead of writing files?

Aren't you curious? As you can see in the image above, I am able to create any folder with any name inside the Platform folder.

Using the knowledge of how Windows Defender performs version switching, suppose I create a folder in the Platform folder with the highest version number. Will Defender then use my folder as its working directory?

2. Exploiting Defender's update mechanism to perform Execution Folder Hijacking.
   First, I copy Defender's current working folder to C:\TMP\AV. This folder will be used for further manipulations: DLL hijacking, deleting important Defender files, and so on, as it will become the new workspace for Defender.

Then I create a symbolic link (SYMLINK) in the Platform folder pointing to the new path (C:\TMP\AV). The name of the symbolic link must correspond to the highest version number of the existing versions in the Platform folder. For example, if the current version is 4.18.25070.5-0, it is necessary to create a symbolic link named 5.18.25070.5-0.

mklink /D "C:\ProgramData\Microsoft\Windows Defender\Platform\5.18.25070.5-0" "C:\TMP\AV"

Now just restart the computer. After the reboot, Defender starts again, but now it uses the file located in the folder we control.

You see, now Defender uses the executable file from the C:\TMP\AV folder. Here we can freely add, delete, or modify any files. You can try to inject your code into Defender's processes via DLL side-loading or simply delete files to cause the service to stop working.

3. A Simple Experiment: Permanently Disabling Windows Defender.
   After hijacking the folder and launching Defender from the controlled location, let's check if it can be disabled. Instead of destroying the executable file itself, I will delete the symbolic link between the version folder in Platform and the folder I own. When Defender tries to start again, it will not be able to find the required folder with the executable files, which will lead to a startup error.

rmdir "C:\ProgramData\Microsoft\Windows Defender\Platform\5.18.25070.5-0"

The Windows Security page became inactive because the service is no longer running: all components related to Defender failed to start successfully.

III. FINALE
The struggle between malware and protective software, or more precisely, between antiviruses and attackers, represents an endless game of cat and mouse. Each side continuously searches for new methods and tries to exploit the opponent's weaknesses.

For a hacker, it is important to be able to either avoid detection by security solutions or completely disable them — both approaches are part of the attacker's daily routine, necessary for effectively conducting security testing.

Due to the great popularity of Windows Defender, it is necessary to be able to deal with it. Flaws in Defender's version update mechanism, demonstrated by me earlier, allow compromising the integrity of a key component of protection its executable folder, using a symbolic link.

Antivirus programs and EDRs always run with elevated privileges and are often protected by special drivers. If such applications contain vulnerabilities, malware can exploit them by masquerading as a trusted program, such as an antivirus or EDR. Thus, undeletable malware appears on the victim's machine, or the antivirus and EDR lose their ability to function.

IV. Defensive Recommendations (Actionable for Administrators — Not Exploit Details)

1. Enforce strong integrity checks: Services should verify code signatures and cryptographic hashes before launching updated binaries or loading libraries.
2. Harden file system permissions: Limit who can create or rename version directories under update/Platform folders. Use least-privilege principles and monitor for unexpected folder creations or permission changes.
3. Validate path resolution: Software should detect and reject unexpected filesystem objects (symbolic links, reparse points) in protected directories unless explicitly allowed and validated by the vendor.
4. Audit update logic: Ensure that selection of the “latest” version relies on signed manifests or vendor metadata rather than on purely manipulable attributes like folder names.
5. Monitor for anomalies: Log and alert on unusual directory enumeration behaviors, service restarts that follow file system changes, or failed signature validations.
6. Fail safe: If validation fails, services should refuse to run from the untrusted location and should instead fall back to a safe, known good state (or halt with a clear alert), rather than continuing in an insecure mode.
7. Defense-in-depth: Combine host hardening (disk encryption, secure boot, tamper-resistant configuration) with endpoint monitoring and network segmentation to limit an attacker’s ability to reach the update directories in the first place.