How Trailing Dots and Spaces Bypass Windows Security Controls

TLDR: Windows path normalization creates a critical discrepancy between how Win32 APIs and NT functions handle file names, allowing attackers to hide files, directories, and processes from standard management tools. By appending trailing dots or spaces to file names, researchers can bypass security checks, achieve privilege escalation, and execute arbitrary code during archive extraction. This research highlights the danger of relying on high-level APIs for security enforcement when the underlying kernel handles paths differently.

Legacy code is the gift that keeps on giving for offensive researchers. Windows has spent decades maintaining backward compatibility, and that commitment often forces the OS to support file naming conventions that modern security tools simply do not expect. The MagicDot research presented at Black Hat 2024 exposes how a simple, decades-old quirk in how Windows handles trailing dots and spaces can be weaponized to bypass security controls, hide malicious artifacts, and achieve remote code execution.

The Mechanics of the Discrepancy

At the heart of this issue is the difference between how the Win32 subsystem and the underlying NT kernel interpret file paths. Win32 APIs generally normalize paths by stripping trailing dots and spaces, but the NT kernel is more permissive. When an application uses a Win32 API to interact with a file, the API might see a file named a.txt while the kernel sees a.txt..

This mismatch allows an attacker to create files or directories that standard tools like File Explorer or Task Manager cannot properly interact with or even see. If you create a directory named test... using an NT path, standard management tools often fail to list, delete, or modify the contents of that directory because they cannot resolve the path correctly. This effectively creates a "ghost" location on the disk where malicious payloads can reside, invisible to the very tools a system administrator uses to monitor for threats.

From Concealment to Code Execution

Hiding files is useful for persistence, but the real impact lies in how this technique interacts with archive extraction. When a user extracts a ZIP file, the extraction tool often relies on the same flawed path normalization logic. By crafting an archive that contains a file with a trailing dot or space, an attacker can trick the extraction process into writing files to locations that the user or security software does not intend.

The research demonstrates a particularly dangerous scenario involving the Windows Startup folder. By creating a malicious archive that uses these path manipulation techniques, an attacker can force the extraction tool to write an executable directly into the Startup folder, even if the user thinks they are extracting the archive to a benign, isolated directory. Upon the next system reboot, the malicious code executes with the privileges of the user who performed the extraction. This is a classic T1547.001 execution flow, but one that bypasses standard path validation checks.

Real-World Impact and CVEs

During the research, several vulnerabilities were identified and subsequently patched by Microsoft. These include:

• CVE-2023-36396: A remote code execution vulnerability triggered during archive extraction.
• CVE-2023-32054: An elevation of privilege vulnerability involving Shadow Copy restoration.
• CVE-2023-42757: A denial-of-service vulnerability in Process Explorer.

For a pentester, these findings are a reminder that path normalization is not just a developer convenience; it is a security boundary. If you are testing an application that handles file uploads or archive extractions, you should be fuzzing the file names for these exact characters. If the application does not explicitly sanitize these inputs before passing them to the underlying OS, you may be able to escape the intended directory or overwrite critical system files.

Defensive Considerations

Defending against these techniques requires moving away from reliance on high-level API path normalization. Developers should implement strict allow-lists for file names and ensure that any path manipulation is performed using secure, canonicalized paths. If you are a blue teamer, monitor for processes that attempt to access files with unusual naming patterns, particularly those involving trailing dots or spaces. Tools like Process Explorer are essential for identifying these hidden processes, but as the research shows, even these tools can be manipulated if the attacker understands the underlying path resolution logic.

What to Investigate Next

The most effective way to test for these vulnerabilities is to move away from DOS-style paths and start using NT-style paths in your own tooling. By interacting directly with the NT namespace, you can bypass the normalization layers that often mask these issues. The MagicDot GitHub repository provides the necessary proof-of-concept code to start experimenting with these techniques.

The next time you are on an engagement, look for applications that perform file operations on user-supplied input. If you can control the file name, you can control the path. And if you can control the path, you can often control the system. The era of assuming that a file name is just a file name is over. Start looking for the dots and spaces that developers forgot to account for.