Hacking with MagicDots: Exploiting Dots & Spaces in Filenames/Pathnames for Permanent Admin Rights

In a recent study conducted by SafeBreach Labs, a security research team has uncovered a trio of vulnerabilities stemming from a longstanding issue within the DOS-to-NT path conversion process used by Windows operating systems. This study, led by Or Yair, Security Research Team Lead, has revealed not only vulnerabilities but also various rootkit-like techniques that were exploitable without administrative privileges.

Or Yair and his team found that the MagicDot paths—an area seemingly harmless and known but overlooked—posed significant security risks. The vulnerabilities included allowing malicious actors to hide files and processes, manipulate file restoration processes, and make malware appear as verified software on task managers and process explorers. The most concerning part was that these actions could be executed without the need for administrative rights, essentially offering rootkit capabilities to any unprivileged user.

The DOS-to-NT path conversion process in Windows is a fundamental aspect of how the operating system handles file paths. This process can be complex due to the legacy support for DOS-style paths and the current NT (New Technology) file system paths used by modern Windows. Understanding this conversion process is crucial for grasping how vulnerabilities might arise.

DOS Paths

DOS paths are traditionally shorter and have limitations compared to NT paths:

  • Length: DOS paths typically support a maximum of 260 characters.
  • Format: They use a simple structure, generally starting with a drive letter followed by a colon and a backslash, then the directory names, separated by backslashes (e.g., C:\Program Files\Example).
  • Character Set: DOS paths are limited to upper-case letters with no spaces or special characters beyond underscores.

NT Paths

NT paths are used in modern Windows operating systems and support more complex features:

  • Length: They can exceed the classic 260-character limit of DOS paths.
  • Format: NT paths can include networking setups and subsystem links. They often start with \\?\ for local paths or \\?\UNC\ for network paths to bypass the character limit (e.g., \\?\C:\Program Files\Example).
  • Character Set: NT paths allow for a wider range of characters in file and directory names, including spaces and mixed case.

Conversion Process

The conversion from a DOS path to an NT path involves several steps that accommodate these differences. Here’s a simple example to illustrate:

Example of Conversion

DOS Path: C:\PROGRA~1\Example

  • This is a shortened DOS path where PROGRA~1 might be the shortened version of Program Files.

Converted NT Path: \\?\C:\Program Files\Example

  • The DOS path is expanded to its full NT format, including the special prefix \\?\ that tells Windows to handle this as an extended-length path.


The conversion process is prone to vulnerabilities, especially if malicious actors manipulate path names by inserting special characters or irregular spacing. For example:

  • Manipulated DOS Path: C:\PROGRA~1\Example\.. \.. \badfile.exe
  • In this manipulated path, the use of dots (..) and irregular spacing can trick the system into navigating up the directory tree unexpectedly, potentially accessing or executing a file (badfile.exe) from an unintended location.

The vulnerabilities uncovered by the “MagicDot” research, particularly focusing on the Windows DOS-to-NT path conversion, highlight significant security risks including Remote Code Execution (RCE) and Elevation of Privilege (EoP). These vulnerabilities stem from the system’s mishandling of file paths, where the inclusion of special characters like trailing dots and spaces can lead to unexpected and potentially harmful behavior. Here’s a breakdown of how these specific vulnerabilities manifest:

Remote Code Execution (RCE)

Overview: Remote Code Execution occurs when an attacker is able to execute arbitrary code on another machine over a network, typically bypassing security mechanisms to gain control of the targeted system.

MagicDot Exploitation Path:

  • File Name Manipulation: An attacker can craft file names with trailing dots and spaces that are misinterpreted by some parts of the Windows OS but are treated as valid executable paths by others.
  • Misleading Application and Services: For example, a script or application might download a file named safe_script.ps1. intending to run a PowerShell script. The system, however, executes a malicious script named safe_script.ps1 (without the dot) that the attacker previously placed on the system.
  • Triggering Execution: This can happen through web downloads, email attachments, or other means where the user or an automated system executes what appears to be a benign file, leading to the execution of malicious code.

Elevation of Privilege (EoP)

Overview: Elevation of Privilege occurs when an attacker gains higher access rights than intended, typically moving from a lower privilege level to a higher one, such as obtaining administrative rights from a normal user account.

MagicDot Exploitation Path:

  • Directory and File Confusion: By creating directories or files with trailing spaces or dots, an attacker might confuse system processes about the identity and attributes of a file or directory. For instance, manipulating file paths could trick the system into executing a file from an unprivileged context as if it has administrative privileges.
  • Bypassing Security Controls: These path manipulations can allow malware to be placed in sensitive directories or execute operations that normally require higher privileges. For example, an executable might be placed in a system directory disguised with a trailing dot, misleading system defenses that check the integrity of filenames without considering such anomalies.
  • Exploiting System Processes: If a system process automatically processes files from a directory (like a temp directory) and executes files supposed to be logs or non-executable data, the misinterpreted paths can lead to unauthorized administrative actions being performed.

The most critical of these vulnerabilities was logged under CVE-2023-42757, which, as confirmed by MITRE and Microsoft, pertains to an exploitable flaw that will be documented in a forthcoming CVE entry.

The Exploit Technique

The MagicDot exploit takes advantage of the way Windows trims trailing dots and spaces from file names during its DOS-to-NT path conversion. By carefully crafting file names that include these characters, attackers can create files that appear benign to certain processes while being malicious in nature. Here’s a detailed step-by-step example of how such an exploit might be executed:

Example of MagicDot Exploit

  1. Creating the Malicious File:
    • An attacker creates a file named important.txt... on a system. While the file name is displayed as important.txt in most legacy interfaces (due to DOS conventions trimming the trailing dots), the NT file system retains the full name including the dots.
  2. Exploitation:
    • The attacker convinces a system process or an application to interact with important.txt, intending to access the benign-looking file.
    • Due to the path conversion process, some applications that do not trim trailing spaces or dots may end up interacting with important.txt..., which is actually a different, malicious file controlled by the attacker.
  3. Bypassing Security Measures:
    • By using this naming discrepancy, the malicious file can bypass security measures that might not recognize it as a threat due to its seemingly innocuous name (as seen by most legacy applications).
  4. Impact:
    • This kind of path manipulation could allow the attacker to execute arbitrary code, replace system files, intercept data, or cause other unauthorized actions, all while avoiding detection by security tools that only scan for known dangerous paths or file names.

Rootkits are malicious software designed to gain unauthorized access to a computer system while remaining hidden from users and security programs. They often provide the attacker with administrator-level access, allowing them to alter system configurations, hide malicious activity, and maintain persistent access. Rootkit capabilities vary, but they typically include functionalities that manipulate core system processes and structures to conceal their presence.

Technical Details on Rootkit Capabilities

Rootkits interact deeply with the operating system, often at the kernel level, to avoid detection. They can intercept and alter system calls, hide specific files and directory entries, and mask network connections and processes. Here’s how rootkit capabilities can be understood through a conceptual example:

Example: File and Process Concealment Rootkit

  1. Kernel-Level Manipulation:
    • The rootkit injects itself into the kernel or operates as a kernel module, giving it high-level control over system functions.
  2. File Concealment:
    • Objective: Make certain files invisible to system tools and users.
    • Method: The rootkit intercepts system calls that list directory contents (e.g., readdir on Linux or NtQueryDirectoryFile on Windows). It modifies the results to exclude specific files or directories from being displayed.
  3. Process Concealment:
    • Objective: Hide certain processes to avoid detection by task managers or monitoring software.
    • Method: Similar to file concealment, the rootkit intercepts system calls related to process enumeration (e.g., NtQuerySystemInformation on Windows). It then filters out any information related to its own processes or other specified malicious processes.
  4. Example Scenario:
    • An attacker installs a rootkit on a system that hides a malicious process named badprocess.exe. The rootkit is programmed to intercept calls to NtQuerySystemInformation, used by Windows Task Manager to list running processes.
    • When Task Manager runs, it queries the system for a list of all processes. However, each time this query includes badprocess.exe, the rootkit removes this entry from the results.
    • As a result, badprocess.exe operates on the system without appearing in the task list, effectively invisible to both users and most antivirus software.

Unprivileged Rootkit-like Capabilities Through MagicDot Paths

Rootkits traditionally require privileged access to a system to manipulate core processes and remain undetected. However, the MagicDot findings illustrate that attackers can achieve similar outcomes—such as concealing malicious activities and manipulating system processes—without needing such elevated privileges. This is done through clever manipulation of file path anomalies allowed by the system.

Key Capabilities Demonstrated:

  1. File and Directory Masking:
    • By appending dots (.) and spaces to filenames, attackers can create files or directories that are not properly recognized or are misinterpreted by certain parts of the operating system. This allows malicious files to be hidden in plain sight, effectively invisible to standard file management tools and even some antivirus software.
  2. Misleading System and Applications:
    • The anomalies in handling trailing dots and spaces can mislead applications and system processes about the true nature or existence of files. For example, a file named example.txt... might be shown and treated as example.txt in some interfaces, while it is a separate and potentially harmful file in reality.
  3. Bypassing Security Mechanisms:
    • These path manipulations can be used to bypass security mechanisms that rely on file path integrity checks. By exploiting the discrepancies between how file paths are displayed and stored, attackers can smuggle in or execute malicious payloads unnoticed.
  4. Persistent Access and Control:
    • Similar to traditional rootkits, files created using MagicDot techniques can persist on the system and perform unauthorized activities without being detected. These files can continually interfere with system operations or monitor user actions covertly.

Example Scenario:

Suppose an attacker wants to execute a malicious script without detection. They might create a file named update.bat... on a system. Here’s how they could leverage the MagicDot vulnerability:

  • Creation: The attacker uploads update.bat... via a compromised email attachment or through a web download.
  • Execution Ambiguity: The file might be displayed as update.bat in some administrative tools, leading system administrators to believe it’s a legitimate batch file for updates.
  • System Manipulation: When executed (either by an auto-run setup or manual execution), the system runs the malicious update.bat..., believing it to be benign, allowing the attacker to execute a payload that could steal data, install further malware, or create backdoors.

Implications for Software Vendors

Upon discovering such vulnerabilities, researchers typically engage in a responsible disclosure process with the vendor, in this case likely Microsoft. This includes privately informing Microsoft of the vulnerabilities, allowing them time to verify and develop a fix before any public disclosure. Microsoft would then acknowledge the issue, investigate, and replicate the findings, followed by developing and releasing a patch. They would also issue a detailed advisory that includes mitigation guidance and a CVE number for tracking. The findings from SafeBreach Labs underscore a crucial reminder for software developers—known issues, even if longstanding and seemingly minor, can pose serious security risks if left unaddressed. This case study emphasizes the need for thorough assessments and updates to existing software infrastructures to prevent potential exploits.

The study not only exposes specific vulnerabilities but also proposes actionable insights for software vendors on maintaining and enhancing security protocols. As vulnerabilities like these are widespread and not limited to a single software product, the implications are broad and warrant a systemic review by all software vendors to safeguard against similar exploits.