Defender Pretender: When Windows Defender Updates Become a Security Risk

The SafeBreach Labs team is committed to conducting original research to uncover new threats and ensure our Hacker’s Playbook provides the most comprehensive collection of attacks. As part of our recent research efforts, we discovered a vulnerability in the Windows Defender update process that could effectively allow an unprivileged user to take full control of the Windows Defender tool and leverage it for future malicious activities. 

We first presented this research at Black Hat USA 2023 and are sharing it with the broader security community in this post. Below, we will provide a high-level overview of the background information that served as the foundation for our latest discovery. We will then explain the research process that led us to successfully exploit the Windows Defender update process to deliver malicious updates and maintain persistence on affected systems as an unprivileged user without possessing a forged certificate or executing a sophisticated man-in-the-middle (MITM) attack. We will also provide an overview of the attack vectors we used to validate our findings. Finally, we will highlight the vendor response and identify how SafeBreach is sharing this information with the broader security community to help organizations protect themselves.

Background

SafeBreach Labs delivers cutting-edge vulnerability and cybersecurity research based on real-world insights and observations of “in-the-wild” attacks. The inspiration for our research came from one such observation: Flame malware. In 2012, researchers from Kaspersky Lab discovered Flame malware that state-sponsored threat actors were leveraging to exploit the Windows update process using sophisticated MITM attacks. They were able to successfully hijack the Windows update process and redirect update requests from infected computers to their own servers. They were then able to deliver malicious updates and use this access to maintain persistence on the affected machines. 

We began to wonder if it would be possible to similarly hijack the Windows Defender update process and potentially breach the Windows Defender product to control it to further malicious goals. We also wanted to accomplish this without running complex MITM attacks, without a forged certificate, and as an unprivileged user.

The Research Process 

Understanding the Windows Defender Update Process

To determine our best course of action, our first step was to comprehensively understand the Windows Defender update process. We found that Windows Defender periodically pings the Microsoft Update Center and checks for any new signature definition updates. If an update is available, it is typically returned as a single executable file called Microsoft Protection Antimalware Front End (MPAM-FE[.]exe). 

Upon downloading and analyzing the MPAM file, we discovered that it included a cabinet (CAB) file that contained two executables – mpengine[.]dll and MpSigStub[.]exe, and four files with VDM extensions. Upon executing the MPAM file, we discovered that it also executed the MpSigStub file as a child process to download the updates. 

We initially did not know much about the VDM files but soon discovered their importance in our research. The VDM files are portable executable files. However, they cannot be executed as they include no code logic. We originally assumed that they were special data files that contained detection signatures. We observed that there were two types of VDM files: Base and Delta, with the primary difference being their size. After studying each file in further detail, we were able to understand how the Base and Delta VDM files are used to push new signature database updates to Windows Defender. We also discovered that Microsoft has digitally signed every file in the CAB file to prevent tampering with the update process.

Choosing the Right File for Compromise

We first decided to replace the mpengine[.]dll with our fake mpengine[.]dll file in the hopes that Defender would relinquish control of it to us. When we tried to run the update process, it failed because Defender determined that mpengine[.]dll was NOT signed by Microsoft and that it could not run the update.

Next, we decided to turn our attention to the VDM files. We initially achieved some success when we were able to update an older VDM file (without modifying any of the data) and make Defender believe that it was a new version of that file. This gave us our first clue that we were headed in the right direction. 

We then attempted to modify a random byte in the VDM Delta file and push that as an update, but this approach did not succeed. Clearly, we were missing something in our thought process. We were also left wondering how we were going to be able to achieve all of this as a mere unprivileged user. The answer lay in the analysis of the Malware Protection Signature Update Stub (MpSigStub) file, which revealed that the VDM file’s true purpose was to deliver malware signature updates to Windows Defender. 

Understanding VDM Files

VDM files are Windows Portable Executable files that include a resource section with compressed data that comprises Defender signatures. Signatures in both Base and Delta VDM files are compressed but, surprisingly, not encrypted. After decompressing the signatures in the Base file, we could easily identify where the signatures started and ended and the actual malware string, with malware names clearly included in the string. We were able to ascertain that this was the main file Defender checked for malware signatures. The Delta file was significantly more complex and would require a deeper analysis. 

Understanding the Signature Structure

We assumed that the Base file contained the majority of the signature logic laid out in an easy-to-understand format. By analyzing the Base file signatures further, we were able to determine that each threat started with signature type 5C. A threat is a collection of signatures. These signatures are unique strings or byte sequences that belong to the malware family. The collection of the signatures always ends with Threat_End Signature (a 5D type). 

The Base file is actually a sequence of threats—when one threat ends, the next threat starts, and so on. Using the signature format, we were able to extract more than two and a half million signatures from the Base file. With this information in hand, we attempted to modify a threat name associated with a particular signature and recompressed the VDM file in the hopes that Defender would accept this update. We tried to further tinker with the Base file and even tried to manipulate the cyclic redundancy check (CRC) value in the hopes that Defender would finally accept the change. But this attempt failed as well.

It was then that we realized we could not ignore the Delta file. We had previously misunderstood the relationship between the Base and Delta VDM files. There are two pairs of VDMs: the first pair contains the anti-virus definitions of Defender, and the second pair contains the spyware definitions. Each of these pairs is identical in terms of the format of the signatures and the file. During an update, both the Base and the Delta files are involved. The merge takes the Base file, and the Delta simply defines the changes to be made to this Base file. The resulting output file will represent the updated version from Delta. We realized that to modify base signatures, we needed to supply a Delta file that precisely patches the Base with the intended changes.

Understanding the Overall Merge and Validation Process

The Delta file is a signature-based file. It always contains two signatures, with the second type being a binary large object (BLOB) signature type. The first validation simply checks if the Delta file’s ZlibCompressedData isn’t changed by comparing the expected CRC value within the ZlibDataHeader to the calculated CRC on the ZlibCompressedData.

Further analysis also revealed the exact point at which Defender parses the various actions. We identified two action types: CopyFromDelta and CopyFromBase. CopyFromDelta is used to copy <size>  bytes from the Delta into the merge. CopyFromBase is used to copy <size> bytes from an <offset> within the Base into the merge. We wrote a script to merge data between the Base file and the Delta file. We were also able to identify the two numbers that Defender uses for validation purposes: MergeSize and MergeCRC32. 

After understanding the entire merge, signature, and validation process, we wanted to put our knowledge to the test and verify whether we would be successful in pushing a fake update to Windows Defender. It was successful, and we were able to update Defender with a fake, unsigned database using an unprivileged user.

Taking Advantage of Windows Defender

After thoroughly understanding the Defender update process and determining the best way to fake an update and take control of Defender, we decided to validate the capability of our vulnerability in separate ways. In order to validate and support all of our attack vectors, we developed a fully automatic tool called wd-pretender (short for Windows Defender Pretender). 

Attack Vector 1 – Deleting LaZagne Threats

As we noted above, Windows Defender signatures are the result of combining data from the Base and Delta files. This combined data identifies each threat by its name, which lets researchers identify its purpose. We wanted to see if it was possible to delete a threat from the Windows Defender signature database. For that purpose, we attempted to delete all threats that contained the word LaZagne in their names. 

LaZagne is an open-source application used to retrieve lots of passwords stored on a local computer. When we first tried to download and run the LaZagne tool as an unprivileged user, Defender immediately detected it by name and stopped its execution. Using our wd-pretender tool, we pushed a fake update that did not have the term LaZagne in its signature database. After the update was completed, we tried to download and run the LaZagne tool again. This time it was a success. Windows Defender did not detect the malicious tool (LaZagne), as its signature did not match anything in its database. 

Attack Vector 2 – FriendlyFiles

We next turned our attention to a feature called FriendlyFiles,” which essentially is an allow list in Windows Defender. FriendlyFiles lets Windows Defender know which executables should be allowed to complete actions based on their secure hash algorithm (SHA) value. Parsing the FriendlyFile signature type revealed a very long, sorted list of hashes. Among these we identified a hash belonging to Oracle’s virtual box runtime library. We wanted to know what would happen if we replaced this file’s hash with that of a known hash value of Mimikatz. 

When we first tried to download Mimikatz, Windows Defender immediately stopped us. Then we leveraged our wd-pretender tool to replace the FriendlyFile hash with the Mimikatz hash and push this via a fake update to Windows Defender. Upon updating, we tried to download Mimikatz and run it again. Not only were we successful in installing Mimikatz, but we were also able to extract all stored credentials from that machine. 

Attack Vector 3 – Denial of Service

The third and final attack vector we validated was denial of service (DOS). We decided to attempt to have Windows Defender delete all portable executable (PE) files by modifying an existing Emotet signature to include the “Dos Mode Stub string,” which would appear in any PE file as a new malicious signature. If Defender came across the string “!This program cannot be run in dos mode” in the various operating system (OS) files, it would automatically delete them. 

We used wd-pretender to allow the “Dos Mode Stub string” to be modified and updated with our string with a malicious Emotet signature. As soon as Defender detected this, it immediately alerted us about it. We also had Defender scan the entire PC’s driver folder, and it identified several critical Windows files as having the same malicious signature and immediately deleted them. We attempted to restart the PC but were unable to, resulting in a permanent denial of service. 

Potential Future Attack Vector – Possibility to Achieve Local Privilege Escalation

We have identified a potential future attack vector that could lead to local privilege escalation. During the course of our research, we also discovered that the signature file also contained 30K scripts in the LUA programming language. Microsoft uses a modified LUA header, but we were able to decompile it and extract the source code for all 30K LUA scripts. With access to the entire source code, we could potentially replace the run code with our modified code and perhaps achieve local privilege escalation (LPE).

Vendor Response

As soon as we notified Microsoft about the discovery of our vulnerability, CVE-2023-24934, they confirmed it, took immediate action, and released a patch that validates the digital signature of all VDM files. The fixed version is Microsoft Malware Protection Platform version 4.18.2303.8. 

Key Takeaways

Based on the findings associated with this research, we believe it is important to understand that: 

• Even the most reliable security controls might be susceptible to bypass if the adversaries are motivated enough. The security of these controls must be periodically tested and fixed before an attacker can exploit them. 
• The use of digitally signed files does not always mean increased security. The onus is on the security vendor to ensure that an attacker cannot exploit built-in processes and subvert them for their own advantage. 
• Based on the potential for the process of malware signature updates to be exploited as a new attack vector, more research is needed to ensure the security of this process. 

Conclusion

The implications of our research are significant, as Windows Defender is a very well-known and trusted tool that many organizations use as a first line of defense. To help mitigate the potential impact of these vulnerabilities, we have: 

• Responsibly disclosed our research findings to Microsoft, and they have issued a fix for our discovered vulnerability (CVE-2023-24934).
• Included tools that enable the verification of this vulnerability and serve as a basis for further research and development of new attack vectors. 
• Shared our research openly with the broader security community here and at our recent Black Hat presentation in the hopes that users stay vigilant and understand that even the most trusted security tools can be compromised by a motivated attacker.

For more in-depth information about this research, please: 

• Contact your customer success representative if you are a current SafeBreach customer
• Schedule a one-on-one discussion with a SafeBreach expert
• Contact Kesselring PR for media inquiries 

About Our Researchers

Tomer Bar heads the SafeBreach Labs team. Tomer is a hands-on security researcher with over 20 years of unique cybersecurity experience. His main interests are vulnerability research, reverse engineering, and advanced persistent threat (APT) research. Among his recent discoveries are the PrintDemon vulnerabilities in the Windows Spooler mechanism, which were candidates in the best privilege escalation category of the Pwnie awards and several research studies on Iranian APT campaigns. He has presented his research at events around the world, including DEF CON (28-30), Black Hat USA, ReCon, Sector, Confidence, Security Fest, HackCon, and Troopers conferences.

Omer Attias is a security researcher with over six years of experience in cybersecurity. He started his professional career in the Ministry of Defense and then at the Israel Defense Force (IDF). Most of his work is focused on network research, including Windows Internals and Linux kernel components.