Process Ghosting: Executing Malicious Code via Memory File Manipulation

To appreciate the necessity and ingenuity of Process Ghosting, one must understand how modern Windows operating systems attempt to secure the process creation cycle. When a user or a program attempts to execute a file (e.g., clicking on malware.exe), the Windows OS does not simply blindly execute the code. It initiates a complex sequence of events managed by the Windows Loader.

A critical component of this sequence involves security callbacks, specifically the PspSetCreateProcessNotifyRoutine. This feature allows legitimate security software (like an EDR or Antivirus) to register a callback function with the Windows kernel. When the operating system is about to create a new process or load an executable image into memory, the kernel pauses the execution and notifies the registered security software. This provides the antivirus engine with the crucial opportunity to scan the file on the disk, analyze its contents, and determine if it is malicious. If the scanner detects malware, it blocks the process creation, and the file is quarantined.

Advanced evasion techniques are entirely focused on subverting this specific notification mechanism. Process Doppelganging bypasses it by hiding the malicious file within an uncommitted NTFS transaction. Process Ghosting takes a different approach. It accepts that the security callback will happen, but it manipulates the timing and the state of the file on the disk so that when the antivirus engine attempts to scan the file, the file has effectively ceased to exist—it has become a ghost.

The core mechanism of Process Ghosting relies on the exploitation of a specific file state within the Windows operating system: the "delete pending" state. In Windows, file deletion is not always an instantaneous event. When an application requests the deletion of a file, the OS checks if other applications currently have that file open. If the file is open, the OS cannot immediately delete it without causing system instability.

Instead, the OS marks the file with a FILE_DELETE_ON_CLOSE flag. This places the file in a "delete pending" state. The file remains on the disk, and the application that currently holds it open can continue to read from and write to it. However, the crucial aspect of this state is that no new applications can open the file. Any subsequent attempt to open the file (even for a simple read operation) will be denied by the operating system with an "Access Denied" error. The file will only be physically removed from the hard drive once the original application closes its handle to the file. This specific architectural quirk—allowing an application to utilize a file while simultaneously blocking all other applications from accessing it—is the exact vulnerability that Process Ghosting exploits.

Executing a Process Ghosting attack requires a highly precise sequence of low-level Native API calls, manipulating the file state faster than the operating system's security mechanisms can respond. The attack unfolds in four distinct phases: Create, Mark, Map, and Execute.

Phase 1: Create. The attacker begins by creating a new file on the disk using the NtCreateFile API. Crucially, they request delete access (DELETE) and specify that the file should be shared for deletion (FILE_SHARE_DELETE). The attacker then writes their malicious payload (the compiled malware executable) into this newly created file. At this point, the malicious file physically exists on the hard drive.

Phase 2: Mark. This is the pivotal step. While still holding the handle (the connection) to the malicious file open, the attacker utilizes the NtSetInformationFile API to set the FileDispositionInformation class, explicitly marking the file for deletion. The file now enters the critical "delete pending" state.

Phase 3: Map. The attacker must now prepare the file for execution. They utilize the NtCreateSection API, pointing it at the file handle they still hold open. The Windows Memory Manager reads the malicious payload from the disk and maps it into a new executable memory section (RAM). Because the attacker already holds an open handle, this operation succeeds perfectly. However, because the file is in a "delete pending" state, if an antivirus scanner suddenly attempts to open the file on disk to inspect it, the OS will block the scanner with an "Access Denied" error.

Phase 4: Execute. With the malicious payload safely mapped into memory, the attacker closes the original file handle. The moment the handle is closed, the operating system honors the "delete pending" request and instantly, physically deletes the file from the hard drive. The attacker then uses the previously created memory section to spawn a new process using APIs like NtCreateProcessEx and NtCreateThreadEx.

When the Windows kernel inevitably triggers the process creation security callback to notify the antivirus, the antivirus engine attempts to find the file on the disk to scan it. However, the file is already gone—it is a ghost. The antivirus scanner finds nothing, returns a clean result, and the malicious process is allowed to execute unimpeded from RAM.

Process Ghosting is closely related to, and often compared with, another sophisticated evasion technique known as Process Herpaderping. Both techniques aim to confuse security products by manipulating the file on disk between the time the process is created and the time the security product attempts to scan it. However, their methodologies differ significantly.

In Process Herpaderping, the attacker writes the malicious payload to disk, maps it into memory, and creates the process. But before the security callback is triggered, the attacker quickly overwrites the malicious file on the disk with benign data (e.g., the contents of a legitimate application) or completely obfuscates the file's header. When the antivirus engine receives the callback and scans the file on disk, it sees the newly written benign data and allows the execution. The process in memory, however, was mapped from the original malicious data. Herpaderping relies on obscuring the file contents.

Process Ghosting, conversely, relies on entirely preventing access to the file. It does not overwrite the file; it utilizes the "delete pending" state to ensure the antivirus engine simply cannot open the file to read it. Furthermore, once the handle is closed, the file is physically deleted. Herpaderping leaves a modified file on the disk, which can potentially be investigated forensically. Ghosting leaves absolutely no trace of the malicious executable on the hard drive, making post-incident forensic analysis significantly more challenging. Both techniques effectively bypass the standard process creation callbacks, but Ghosting is generally considered stealthier due to its complete removal of physical evidence.

The emergence of techniques like Process Ghosting represents a significant challenge for the cybersecurity industry, profoundly impacting how Endpoint Detection and Response (EDR) solutions are architected. Traditional security monitoring heavily relies on analyzing the static properties of a file on disk—its hash, its digital signature, and its structural layout. Process Ghosting systematically dismantles this paradigm.

If an EDR solution relies solely on the PspSetCreateProcessNotifyRoutine callback to trigger its scanning engine, it is entirely blind to Process Ghosting. By the time the EDR is notified, the physical file is gone, and the EDR has no mechanism to scan the code that is already executing in memory. This forces security vendors to recognize that static file scanning, while necessary, is vastly insufficient for modern threat detection.

Furthermore, Process Ghosting highlights the limitations of relying on user-mode API hooking. Many legacy security tools inject themselves into user-mode processes to monitor API calls (like CreateProcess). Advanced attackers can easily bypass user-mode hooks by executing raw syscalls or "unhooking" the APIs dynamically in memory. To detect Process Ghosting, EDRs must operate at the deepest levels of the Windows kernel, monitoring the fundamental low-level Native APIs and correlating complex behavioral sequences across the operating system.

Detecting Process Ghosting requires advanced, behavioral-based EDR capabilities that look beyond the simple existence of a file on a disk. Defenders must focus on the anomalous sequence of API calls and the discrepancies between what is executing in memory and what exists on the hard drive.

A primary detection strategy involves kernel-level telemetry monitoring. EDRs must monitor the specific chain of Native API calls utilized in the attack. The sequence of NtCreateFile (with delete access), immediately followed by NtSetInformationFile (marking for deletion), NtCreateSection (mapping to memory), and the subsequent execution of that memory section (NtCreateProcessEx), is highly anomalous. While legitimate applications (like software updaters) might delete files, they rarely map them into executable memory sections while they are in a "delete pending" state. EDRs can utilize machine learning and behavioral heuristics to flag this specific sequence as a strong indicator of compromise.

Memory forensics is also essential. Advanced EDRs continuously scan the dynamic RAM of running processes. If the EDR identifies a running process, it can query the operating system for the path of the executable file from which that process was spawned. In a Process Ghosting scenario, the EDR will attempt to locate that file path on the physical hard drive. If the process is running, but the corresponding file no longer exists on the disk (because it was deleted upon handle closure), this massive discrepancy is a definitive sign of evasion. Additionally, organizations should enforce strict Application Control (whitelisting) policies. By ensuring only explicitly authorized, digitally signed binaries are permitted to execute, organizations can significantly reduce the effectiveness of fileless techniques, regardless of how stealthily they manipulate the file system.