[German]I'm going to bring up a security issue surrounding Windows 11 24H2 that has been on my mind for about a week now. Security researchers at Zero Solarium have found a way to exploit the Windows file WerFaultSecure.exe to steal LSASS passwords from the cache. On the other hand, security applications can be frozen using WerFaultSecure.exe and a corresponding tool. However, Microsoft Defender detects this attempt to freeze the system. And the LSASS dump requires copying a Windows 8.1 file to the Windows 11 system.
EDR freeze using WerFaultSecure.exe
I first came across information about a problem in Windows on September 21, 2025, via the following tweet.
In the article EDR-Freeze: A Tool That Puts EDRs And Antivirus Into A Coma State, Zero Solarium describes how Windows' built-in tools can be used to disable security software (endpoint detection and response, EDR, antivirus software) in the operating system. To do this, the WerFaultSecure.exe file of the Windows Error Reporting function could be abused.
WerFaultSecure abused
Security researchers at Zero Solarium discovered this issue while developing a tool for dumping the WSASS LSA process (see below). There, the security researcher obtained some information about the WerFaultSecure.exe program.
"WerFaultSecure supports execution with PPL protection at the WinTCB level," writes the author of the Zero Solarium article. The abbreviation PPL stands for Protected Process Light, a security feature introduced in Windows 8.1 to protect important system processes from manipulation or termination. The mechanism is designed to protect sensitive services such as antivirus solutions and EDR systems from unauthorized interference. WinTCB are a class of specially protected processes with special privileges. So if WerFaultSecure.exe runs at WinTCB level and supports PPL protection, you can use the tool to do all sorts of nonsense in Windows.
Analysis of the situation by security researchers
The folks at Zero Solarium discovered that the MiniDumpWriteDump function runs very quickly, so users may not even notice that the target process was suspended while the minidump was being written. This raised the question of how this mechanism could be expanded.
If a normal process can execute a new process with PPL protection, the child PPL process can be forcibly suspended during CreateProcess using the CREATE_SUSPENDED flag. The processes that need to be permanently frozen are often EDR and antivirus processes, but these are usually protected by PPL (Protected Process Light). It is therefore necessary to bypass PPL protection in order to interact with these processes.
With the parameters for executing WerFaultSecure, backported from an earlier project, the MiniDumpWriteDump function can be activated with any desired process. And in combination with the CreateProcessAsPPL tool, WerFaultSecure can be used to bypass PPL protection. If we can call the OpenProcess function with PROCESS_SUSPEND_RESUME permission for PPL processes also has the option of suspending this process.
The TwoSevenOneT tool EDR-Freeze
Based on the findings from the above article, security researcher TwoSevenOneT wrote the EDR-Freeze tool and published it on GitHub. This tool exploits the WerFaultSecure software vulnerability to halt the processes of EDRs and anti-malware programs without having to use the BYOVD (Bring Your Own Vulnerable Driver) attack method.
EDR-Freeze stops protection software
EDR-Freeze operates in user mode, so you do not need to install any additional drivers. It can run on the latest version of Windows. The tool temporarily suspends all antimalware/EDR processes for a period of 1–3 seconds. If the tool is called via script, it could also freeze security processes for long periods of time.
The tests during development were performed using the current fully patched version of Windows 11 24H2. In this tweet, another party confirms that the approach works.
Protection against this attack
Steven Lim, whom I quoted in the above tweet, has developed a tool called DefenderXDR KQL to detect such attacks by mapping the WerFaultSecure PID to core MDE processes.
Security researcher Florian Roth points out in the above tweet that the first examples have been uploaded to VirusTotal. However, there is no cause for alarm. I had already seen a tweet a few days ago saying that it doesn't work on Windows 11 Enterprise because "security features" prevent the attack (but I can't find this source anymore).
t Bleeping Computer asked Microsoft about this and cited a Microsoft speaker: "Customers using Microsoft Defender are not affected by this tool, and any attempt will be detected and blocked before execution. We continue to evaluate and secure Windows against this and other potential attack techniques."
Hackers use WerFaultSecure for LSASS password dump
Then I saw the following tweet – and a reader also pointed it out to me (thanks for that).
Cyber Security News describes in this article how attackers can exploit outdated versions of the Windows error reporting program WerFaultSecure.exe to extract the memory space of the Local Security Authority Subsystem Service (LSASS.EXE). These dumps can be used to collect cached login credentials from fully patched Windows 11 24H2 systems. This article also refers to the approach outlined above by Zero Solarium for exploiting WerFaultSecure.exe.
Attackers need an unencrypted memory dump
After attackers have gained access to a system, they often try to dump the LSASS memory. This is because it contains login credentials that attackers can use to extend their privileges and move laterally within the network.
Normally, an LSASS memory dump is stored in encrypted form. Hackers therefore resort to a trick: Windows 8.1 had a vulnerability that could be exploited to cause WerFaultSecure.exe to write crash dumps without applying the encryption routines integrated in the operating system. As a result, unencrypted dump files are stored on the hard drive, from which passwords can be extracted.
Using old WerFaultSecure.exe in Windows 11
Security researchers at Zero Solatium simply took a WerFaultSecure.exe from Windows 8.1 and copied it to a Windows 11 24H2 computer. I haven't tested it, but the Windows 8.1 copy of WerFaultSecure.exe is signed by Microsoft and can apparently be launched from any folder (in the example, from C:\Tmp\). The security researchers were then able to use their own tool to write the LSASS memory as a raw dump to the hard disk via WerFaultSecure.exe under the protection of the PPL extension.
Zero Salarium reported here, that the exploit sequence requires WerFaultSecure.exe to be executed with undocumented switches. These options were discovered through reverse engineering:
- /h to call the secure hidden crash mode,
- /pid [pid] to address the LSASS process,
- /tid [tid] to set its main thread, and
- /file [handle] to set an unencrypted output handle.
All of this was combined into a tool that writes the LSASS cache as an unencrypted dump to a file and disguises it as a PNG image file. After running the tool, you can copy the proc.png file from the folder where WSASS.exe is located.
If you change the first 4 bytes back to the values {0x4D, 0x44, 0x4D, 0x50} (MDMP), you have a normal minidump file. Tools such as Mimikatz can then be used to search this minidump for login information.
The blog reader who also brought this topic to my attention raised the question of whether it is possible to explicitly specify in Applocker, SRP, or Software Deployment that the WerFaultSecure.exe file may only be called from Windows directories. If so, the above approach would only be necessary with administrative permissions to copy the file. So, my question to the specialists is: Would this approach be feasible and, if so, how?
