Windows Defender Quarantine Folder Metadata Recovered for Forensic Investigations

Windows Defender is a built-in antivirus and anti-malware software developed by Microsoft for Windows operating systems. 

It provides real-time protection against various threats, including:-

• Viruses
• Spyware
• Ransomware

Cybersecurity researchers at Fox-IT recently discovered that revived Windows Defender Quarantine folder metadata helps in boosting forensic investigations.

Windows Defender Quarantine Folder Metadata

In incident response, researchers often confront triggered antivirus apps like Windows Defender. Threat actors either disable it or try to evade detection. Windows Defender’s quarantine folder is crucial for digital forensics, revealing:-

• Timestamps
• Locations
• File signatures

The intact quarantine folder offers valuable forensic insights even if threat actors erase Windows Event logs. Recovering files from quarantine helps reverse engineering. 

While scripts exist for recovery, but security analysts’ research unveils previously unknown metadata, reducing uncertainties in forensic investigations.

Researchers delved into Windows Defender internals, consulting Florian Bauchs’ whitepaper and other GitHub scripts. Existing tools left significant data unparsed, hinting at undiscovered forensic artifacts. 

Windows Defender encrypts files with a hardcoded RC4 key from mpengine.dll. Using public scripts and Bauch’s whitepaper, researchers loaded mpengine.dll into IDA, leveraging Microsoft’s symbol server for a head start on functions and structures.

Researchers started with the QuarantineEntry file to recover its structure for valuable metadata. Unlike one RC4 cipherstream, this file has three individually encrypted chunks, referred to as:-

• QuarantineEntryFileHeader
• QuarantineEntrySection1
• QuarantineEntrySection2

Analyzing mpengine.dll in IDA, the QexQuarantine::CQexQuaEntry::Commit function determines QuarantineEntrySection1 and QuarantineEntrySection2 contents. The PDB lacks details on the CQexQuaEntry class, but field derivation is possible from associated function names. 

Key fields like Id, ScanId, ThreatId, ThreatName, and Time are crucial. Section1 size, set in the function, includes ThreatName length plus 53 bytes, labeled as ‘One’ for now due to uncertainty. Likely a boolean value, its purpose within QexQuarantine::CQexQuaEntry::Commit remains unknown.

QuarantineEntrySection2 includes the count of QuarantineEntryResource objects and their offsets within the QuarantineEntry structure. 

While typically, one threat corresponds to one QuarantineEntryResource, scenarios like unpacking a ZIP with multiple threats can have multiple resources within a single QuarantineEntry.

To parse QuarantineEntryResource instances, experts examine the CQexQuaResource::ToBinary function. This function, handling binary output for forensic recovery, features loops similar to ThreatName serialization. 

The loops reserve space in the output buffer for UTF-16 encoded DetectionPath and DetectionType, which are crucial components observed in decrypted QuarantineEntry files.

File recovery steps

File recovery includes the following three steps:-

• Step one: eyeball hexdumps
• Step two: open IDA
• Step three: RTFM

Besides this, reverse engineering mpengine.dll revealed valuable insights into Windows Defender’s quarantine process, leading to the discovery of undocumented metadata. This uncovered the following additional details that enhance the digital forensics capabilities:-

• Timestamps
• NTFS data streams

The research also illustrates Defender’s use of BackupRead functionality to preserve NTFS file data streams. Implementing findings in a Dissect framework plugin enhances code readability and verifiability.