Phantom Code: Evading Windows 11 25H2 Through POSIX-Based Self-Deletion and Stealth Injection

Phantom Code: Evading Windows 11 25H2 Through POSIX-Based Self-Deletion and Stealth Injection

Speakers: Jakkaraju Varshith (Rashtriya Raksha University); Vivek Joshi (Assistant Professor, Rashtriya Raksha University)

Conference: Nullcon

YouTube: https://www.youtube.com/watch?v=tzB6PdMl7Lw

Overview

This talk, presented by Jakkaraju Varshith and Assistant Professor Vivek Joshi from Rashtriya Raksha University, delved into the persistent challenge of achieving complete, untraceable file deletion on modern Windows operating systems. Specifically, the researchers aimed to address the limitations of prior stealth deletion techniques on Windows 11 25H2, a version that has patched older evasion methods. The core problem for attackers, and thus a critical area of research for defenders, is the ability to execute malicious code, perform actions, and then completely vanish from a compromised system, leaving no forensic traces.

The presentation highlighted a critical gap in current system security and forensic capabilities, demonstrating how operating system internals can be leveraged or bypassed to achieve a high degree of stealth. The speakers' work, titled "Phantom Code," implies the development of a novel methodology that combines POSIX-based self-deletion with stealth injection techniques. This approach seeks to overcome the sophisticated anti-forensic measures implemented in the latest Windows iterations, which previously thwarted less advanced methods by leaving behind detectable artifacts such as zero-byte files. The research is significant for both offensive security practitioners seeking to enhance evasion capabilities and defensive teams striving to understand and mitigate advanced persistent threats.

Background

▶ Watch: Speakers' introduction and ideal attacker scenario (0:00)

The pursuit of stealth and untraceability is a fundamental objective for any sophisticated attacker. The ideal scenario involves gaining initial access, operating undetected within a system, and then exfiltrating or cleaning up without leaving any forensic evidence. For decades, security researchers and malicious actors have explored various techniques to achieve this "ghost in the machine" effect, particularly concerning the deletion of files associated with malicious payloads or operational tools.

One notable technique, attributed to Lloyd Labs, provided a robust method for stealthy file deletion on Windows systems up to version 23H2 (approximately until 2019). This method exploited specific functionalities within the Windows file system and its API to ensure that a file, once executed, could be completely removed from the system without leaving any discernible traces, such as entries in the Master File Table (MFT) or other file system artifacts. The technique leveraged Alternate Data Streams (ADS), a feature of the NTFS file system that allows multiple streams of data to be associated with a single file. While often used for legitimate purposes (e.g., storing metadata), ADS has long been a favorite of malware authors for hiding data or even executables.

The Lloyd Labs technique involved a precise sequence of operations. First, a file would be opened with specific delete permissions. Next, using the properties of ADS, a new string or data stream would be attached to the file. This step, while not directly responsible for deletion, could be part of a broader strategy for data manipulation or hiding. The crucial part of the technique came after closing the initial file handle. The file would then be reopened, and a specific system call, likely SetFileInformationByHandle with the FileDispositionInfoEx information class, would be invoked. Within this structure, a boolean value, typically associated with FILE_DISPOSITION_DELETE or similar flags, would be set to true. The critical outcome was that upon the subsequent closure of this second handle, the operating system would automatically and completely delete the file. This process ensured that no residual data, no file system entries, and no other Windows artifacts were left behind, making forensic recovery or even detection extremely challenging.

However, as operating systems evolve, so do their security mechanisms. The speakers highlighted that this once-effective technique began to fail after Windows version 23H2, specifically becoming ineffective in 24H2 and subsequent versions, including the latest Windows 11 25H2. The core issue was that while the SetFileInformationByHandle call with FileDispositionInfoEx still attempted to delete the file, it no longer achieved complete untraceability. Instead, it would leave behind a zero-byte file. From a forensic perspective, a zero-byte file, despite containing no data, is a significant artifact. Its mere presence indicates that a file was created and then attempted to be deleted, providing a crucial clue for incident responders and forensic analysts. This shift represented a major setback for attackers seeking absolute stealth.

The failure of the established technique on newer Windows versions prompted the central research questions posed by Varshith and Joshi:

1. How can complete file deletion be achieved on Windows 11 25H2? This question drives the search for new vulnerabilities or undocumented behaviors.
2. What mechanisms still work? This implies a need to explore alternative system calls, obscure file system interactions, or newly introduced functionalities.
3. Can undocumented APIs and flags be found? The history of Windows security research is replete with examples of powerful capabilities unlocked by discovering undocumented features, which often lack the same level of scrutiny and security hardening as documented APIs.
4. How does WSL (Windows Subsystem for Linux) handle file deletion? This is a particularly intriguing question, as WSL introduces a POSIX-compliant environment on top of the Windows NT kernel. The interaction between Linux file system semantics (where an unlink operation can remove a file even while it's open) and the underlying NTFS file system could present novel avenues for evasion.
5. Is it possible to leverage Linux-like unlink behavior in Windows? The speakers noted that in Linux, enforcing an unlink command will remove a file even if it's currently open, a behavior generally not supported by default in Windows, where open files often cannot be deleted directly. Exploring whether this POSIX-like behavior can be mirrored or exploited within a Windows context, perhaps through WSL or other compatibility layers, forms a critical part of their investigation.

These questions underscore the ongoing cat-and-mouse game between offensive and defensive security, where each operating system update can render old techniques obsolete, necessitating constant innovation from those seeking to bypass security controls. The "Phantom Code" research aimed to provide answers to these critical questions, pushing the boundaries of stealth operations on the latest Windows platforms.

Key Findings

▶ Watch: Explaining the original Lloyd Labs self-deletion technique (2:00)

The provided transcript primarily focuses on establishing the problem statement and outlining the critical research questions that motivated the "Phantom Code" talk. While the specific technical details of the speakers' solution were not elaborated within the provided text, the talk's title itself — "Phantom Code: Evading Windows 11 25H2 Through POSIX-Based Self-Deletion and Stealth Injection" — clearly indicates the nature of their key findings.

The speakers aimed to present a novel methodology that successfully achieves complete, untraceable file deletion on Windows 11 25H2, overcoming the limitations of previous techniques that left behind forensic artifacts like zero-byte files. The core of their discovery lies in leveraging POSIX-based self-deletion and stealth injection.

"POSIX-based self-deletion" suggests that the researchers identified and exploited mechanisms within Windows that adhere to POSIX (Portable Operating System Interface) standards for file operations. This could involve interacting with the Windows Subsystem for Linux (WSL), which provides a full Linux compatibility layer, or potentially other less-known POSIX compatibility layers that might exist deeper within the NT kernel. The implication is that by performing file deletion operations through a POSIX-compliant interface, they found a way to bypass or circumvent the stricter, trace-leaving deletion mechanisms inherent to native Windows APIs on newer versions. This could involve leveraging the Linux unlink semantic, which allows for the deletion of open files, in a way that Windows' underlying file system drivers do not fully log or prevent in this specific context.

Furthermore, the term "stealth injection" indicates that the technique likely includes methods for injecting malicious code into processes or memory in a manner that also minimizes forensic traces. This could involve process hollowing, reflective DLL injection, or other advanced memory-based techniques that avoid writing artifacts to disk, further contributing to the "phantom" nature of the attack.

In essence, the key finding is the successful development of a multi-faceted evasion strategy that marries advanced code injection with a novel, POSIX-influenced file deletion approach. This combination allows for the execution of malicious payloads and their subsequent complete removal, making it significantly harder for defenders to detect and analyze post-compromise activity on Windows 11 25H2. The precise technical implementation details of how this POSIX-based self-deletion and stealth injection are achieved, including any specific undocumented APIs, flags, or WSL interactions, were the subject of the full presentation but are not detailed in the provided transcript.

Technical Deep Dive

▶ Watch: Demonstrating the successful old self-deletion method (2:50)

The technical exposition within the provided transcript focuses primarily on the pre-23H2 Lloyd Labs technique and the subsequent questions raised by its failure, rather than the intricate details of the "Phantom Code" solution itself. However, by understanding the mechanics of the old technique and the nature of the questions, we can infer the technical domains explored by the speakers.

The original Lloyd Labs method relied on a precise manipulation of Windows file system APIs. The process typically began with opening a target file using CreateFile with specific access rights, crucially including DELETE access. This initial handle would then be used to interact with the file. A key aspect of the technique, although not directly related to the untraceable deletion, involved attaching new data or strings using Alternate Data Streams (ADS). ADS allows for multiple data streams to be associated with a single file, conceptually similar to forks in older macOS file systems. While CreateFile can be used to open or create an ADS (e.g., file.txt:streamname), the transcript implies that the ADS was used to attach a new string to the file, potentially as a preliminary step or a means of data hiding.

The core of the untraceable deletion lay in the use of SetFileInformationByHandle. This Windows API function allows for the modification of various file information classes for a given file handle. The specific information class leveraged was FileDispositionInfoEx. This structure, when passed to SetFileInformationByHandle, contains a Flags member where FILE_DISPOSITION_DELETE can be set. When this flag is set to true and the handle is subsequently closed, Windows is instructed to delete the file. In older Windows versions (pre-23H2), this operation would often result in a complete removal of the file from the file system, including its entry in the MFT, leaving no forensic trace. The automatic deletion upon handle closure was a powerful feature for stealth.

The breakdown of this technique in Windows 24H2 and 25H2 is a critical point. When the same methodology is applied to these newer versions, instead of complete removal, a zero-byte file is left behind. This indicates a fundamental change in how the Windows kernel, specifically the file system driver (likely NTFS.sys), handles FileDispositionInfoEx with the FILE_DISPOSITION_DELETE flag. It suggests that while the file's data content is indeed removed, its metadata (such as the MFT entry) is not fully purged. The file record might be marked as deleted, but the entry itself remains, and the file size is updated to zero. This is a deliberate security enhancement, as even a zero-byte file is a strong indicator of an attempted stealth operation and a valuable forensic artifact.

The speakers' research then pivoted to address this new challenge, driven by the questions posed in the background section. The search for undocumented APIs and flags is a common strategy in security research. These are functions or flags not publicly documented by Microsoft, often used for internal OS operations or deprecated features. Discovering such an API that bypasses the new deletion restrictions could provide a direct path to untraceable deletion. This process typically involves extensive reverse engineering of Windows kernel binaries (like ntoskrnl.exe or ntdll.dll) and related drivers.

The inquiry into WSL's handling of file deletion is particularly compelling. WSL provides a compatibility layer that allows Linux binaries to run natively on Windows. When a Linux process running within WSL performs a file operation, it translates those POSIX system calls into corresponding Windows NT kernel calls. The critical question is whether the unlink system call in Linux, which can delete an open file, interacts with the underlying NTFS file system in a way that bypasses the native Windows safeguards leaving zero-byte files. If WSL's internal translation layer or the interaction with the Windows kernel's file system drivers has a different deletion semantic, it could be exploited. For example, a file created and opened by a native Windows process might not be deletable, but if a WSL process could gain a handle to it (or create its own file and delete it), the deletion might occur under POSIX rules, which could then cascade through the NT kernel without leaving the expected Windows traces. This would represent a novel cross-subsystem attack vector.

The concept of "POSIX-based self-deletion" implies that the solution likely involves leveraging these specific POSIX semantics, possibly through direct interaction with WSL components, or by finding other POSIX-like interfaces within Windows that have less stringent deletion rules. The "stealth injection" component would then ensure that the initial payload delivery and execution are also performed in a way that avoids detection and leaves minimal traces, complementing the untraceable file deletion.

Without the specific technical revelations from the talk, it's impossible to detail the exact API calls, data structures, or WSL interactions used. However, the problem statement and the implied solution point to a sophisticated understanding of Windows kernel internals, file system behavior, and the architectural nuances of hybrid environments like WSL. The technical deep dive of the full talk would have undoubtedly explored these areas, possibly revealing new Nt functions, specific IOCTL codes, or undocumented flags within existing API structures that facilitate the "phantom" disappearance of code.

Demo / Proof of Concept

▶ Watch: Old self-deletion technique fails in newer Windows (3:30)

The provided transcript concludes before any demonstration or proof of concept for the "Phantom Code" technique could be detailed. However, based on the talk's title and the problem it aims to solve, a live demonstration would have been a crucial component for validating the effectiveness of the proposed evasion method.

A typical demonstration for such a technique would likely involve executing a small, benign payload (e.g., a simple program that writes a message or creates a temporary file) on a fully patched Windows 11 25H2 system. The key aspect of the demonstration would be to show that after the payload executes, the executable file itself, along with any temporary files or artifacts generated by the "Phantom Code" technique, completely vanishes from the file system. This would be verified by attempting to locate the file using standard Windows commands (e.g., dir, Get-Item), forensic tools (e.g., examining the MFT, using file system analysis utilities), and potentially by checking event logs or EDR telemetry. The success criteria would be the complete absence of the executable and any associated traces, including the "zero-byte file" artifact that thwarted previous methods. Such a demo would visually confirm that the POSIX-based self-deletion and stealth injection techniques effectively bypass the latest Windows anti-forensic measures.

Defensive Implications

▶ Watch: Key research questions for Windows 11 25H2 deletion (4:30)

Given that the provided transcript focuses on the problem statement and the research questions rather than the specific technical implementation of the "Phantom Code" solution, the defensive implications must be discussed in a broader context, inferring from the type of evasion the speakers aimed to achieve. The ability to achieve complete, untraceable file deletion on Windows 11 25H2 represents a significant challenge for defenders across several domains.

Firstly, the primary impact is on digital forensics and incident response (DFIR). If an attacker can execute code and then completely remove all traces of their malicious binaries from the file system, traditional forensic artifacts become unreliable or non-existent. Incident responders often rely on file system metadata (e.g., MFT entries, timestamps, file hashes) to reconstruct attack timelines, identify compromised systems, and understand the scope of a breach. A "phantom code" technique would severely hamper this process, potentially leading to incomplete investigations or the failure to detect an intrusion altogether. The absence of a file, even a zero-byte one, removes a critical starting point for forensic analysis.

Secondly, Endpoint Detection and Response (EDR) solutions and traditional Antivirus (AV) products would face increased difficulty. Many EDRs rely on file system monitoring, integrity checks, and post-execution artifact analysis to detect malicious activity. If an executable is never written to disk in a persistent, traceable manner, or is deleted instantly and completely after execution, it bypasses detection mechanisms that look for file creation, modification, or deletion events. EDRs that focus on process behavior and memory forensics might still catch some aspects of the stealth injection or the code's execution, but the ability to remove the on-disk payload reduces the "smoking gun" evidence.

To counter such advanced evasion techniques, defenders must evolve their strategies:

1. Shift to Memory Forensics and Behavioral Analysis: Relying solely on disk-based artifacts is insufficient. Defenders need robust capabilities for memory forensics to analyze running processes, injected code, and heap/stack contents. Behavioral analysis that monitors API calls, process relationships, network connections, and system resource utilization becomes paramount. Detecting anomalous process behavior, even without an identifiable on-disk binary, is key.
2. Enhanced Kernel-Level Telemetry: Deeper visibility into kernel-level operations, including undocumented API calls or direct system calls, might be necessary. This requires sophisticated monitoring tools that can hook into the operating system at a low level to observe actions that might bypass higher-level EDR sensors.
3. Understanding Cross-Subsystem Interactions: The emphasis on POSIX-based self-deletion highlights the importance of understanding how different operating system layers (like WSL) interact with the core Windows kernel and file system. Defenders need to monitor file operations originating from WSL environments with the same scrutiny as native Windows processes, looking for unusual or suspicious behavior that might exploit these interfaces. This includes monitoring for unexpected unlink semantics on Windows-mounted file systems.
4. Proactive Threat Hunting: With the potential for untraceable attacks, proactive threat hunting becomes even more critical. Instead of waiting for alerts based on known indicators of compromise (IOCs), security teams must actively search for subtle anomalies, unusual process chains, or memory patterns that could indicate stealthy activity.
5. Supply Chain Security: If legitimate software can be compromised to utilize such "phantom code" techniques, it further complicates trust relationships within the supply chain. Robust application whitelisting and integrity checking mechanisms become more important to prevent unauthorized code execution.

In conclusion, the "Phantom Code" research underscores the persistent need for defenders to delve deep into operating system internals and to anticipate novel evasion techniques. The shift from leaving a "zero-byte file" to potentially leaving no trace at all signifies an escalation in the anti-forensic arms race, demanding a corresponding evolution in defensive capabilities and forensic methodologies.

Key Takeaways

• The ideal attacker scenario involves gaining access, operating undetected, and leaving no forensic traces.
• Prior stealth file deletion techniques (e.g., Lloyd Labs' method using ADS and FileDispositionInfoEx) are no longer effective on Windows 24H2 and 25H2, as they leave a detectable zero-byte file.
• The talk aimed to present a novel "Phantom Code" technique leveraging POSIX-based self-deletion and stealth injection to achieve complete, untraceable file deletion on Windows 11 25H2.
• The research highlights the potential for exploiting undocumented APIs, obscure system flags, or the interaction between Windows Subsystems (like WSL) and the native file system to bypass security controls.
• Defenders must move beyond traditional file system forensics and enhance capabilities in memory forensics, behavioral analysis, and kernel-level telemetry to detect advanced, fileless, or trace-less threats.
• Understanding the nuanced interactions between POSIX environments and the Windows kernel is crucial for identifying new attack surfaces and developing effective countermeasures.

About the Speaker(s)

Jakkaraju Varshith is currently pursuing his Masters in Cybersecurity and Digital Forensics at Rashtriya Raksha University (RRU). He is an active participant in security Capture The Flag (CTF) competitions, playing with the team name Forenseek. His research interests likely revolve around offensive security, forensics, and operating system vulnerabilities.

Vivek Joshi is an Assistant Professor at Rashtriya Raksha University (RRU). He is also pursuing his PhD in machine learning, demonstrating a broad academic background. His primary areas of expertise and work include OSINT (Open Source Intelligence), operating systems, and Windows internals, making him well-suited to guide research into advanced Windows evasion techniques.