Bypassing DEP with Shellcodeless ROP: A New Approach to Process Injection

TLDR: Researchers have demonstrated a "shellcodeless" process injection technique that uses ROP chains to invoke Windows APIs directly, effectively bypassing Data Execution Prevention (DEP) without needing traditional shellcode. By chaining over two dozen ROP gadgets, the technique performs complex tasks like process enumeration and memory manipulation in a target process. This research highlights the need for more granular monitoring of API call sequences and memory protection changes rather than just relying on signature-based detection of injected code.

Security researchers often treat Data Execution Prevention (DEP) as a hard wall. Once you have a primitive for arbitrary code execution, the standard playbook involves finding a way to mark a memory region as executable, dumping your shellcode, and jumping to it. But what happens when the environment is so locked down that even that simple flow triggers an alert? The answer lies in moving away from traditional shellcode entirely.

At DEF CON 2024, Dr. Bramwell Brizendine and Shiva Shashank Kusuma presented a compelling methodology for "shellcodeless" process injection. Instead of injecting a blob of machine code, they use Return-Oriented Programming (ROP) to chain together existing Windows API calls. By treating the Windows API as a library of available functions that can be invoked via ROP, they can achieve full process injection and manipulation without ever writing a single byte of shellcode to the target process.

The Mechanics of Shellcodeless Injection

The core of this technique is the realization that you do not need to execute your own code if you can force the target process to execute the code that is already there. The researchers utilize a series of ROP gadgets to set up the stack with the necessary parameters for Windows APIs, such as VirtualAlloc, WriteProcessMemory, and CreateRemoteThread.

The process starts by identifying a target process and obtaining a handle to it. This is where the research gets particularly interesting. Rather than using standard tools, the authors built a custom "enumerate processes" function in memory. They use CreateToolhelp32Snapshot to get a list of active processes and then iterate through them to find the target PID. This is all done by chaining ROP gadgets to perform string comparisons and pointer arithmetic, effectively building a custom function in the target's memory space.

Once the target is identified and a handle is obtained, the next step is to map a DLL into the target process. The authors use NtCreateSection and NtMapViewOfSection to map a file into the target's address space. Because these are low-level APIs from ntdll.dll, they are often less scrutinized by standard security products than their higher-level counterparts.

Technical Implementation and Tooling

The complexity of chaining 29 different gadgets to perform these operations is significant. To manage this, the researchers released ROP-ROCKET, a tool designed to automate the generation of these ROP chains. It allows a researcher to define the desired API sequence and automatically generates the necessary gadgets to set up the stack.

One of the most impressive aspects of the research is the use of "mov dereference" gadgets to handle complex data structures. When an API requires a pointer to a structure, such as PROCESSENTRY32 for process enumeration, the ROP chain must build that structure in memory. The authors demonstrate how to use mov instructions to write the structure byte-by-byte into a writable memory region, then pass the address of that region as a parameter to the API.

; Example of building a structure in memory via ROP
; Writing the dwSize field of PROCESSENTRY32
pop edi ; Load address of writable memory
mov dword ptr [edi], 0x128 ; Set dwSize
inc edi ; Move to next field

This approach is far more resilient than traditional shellcode, which is often detected by memory scanners looking for suspicious executable regions or common shellcode patterns. By using legitimate API calls, the "malicious" activity looks like standard process behavior to many EDR solutions.

Real-World Applicability for Pentesters

For a pentester or a bug bounty hunter, this technique changes the game for post-exploitation. If you are operating in an environment with strict DEP and potentially even Control Flow Guard (CFG) enabled, traditional injection might be blocked or heavily monitored. Shellcodeless injection provides a way to maintain persistence or move laterally while staying under the radar.

During an engagement, you would first identify a target process that has the necessary permissions. You then use the ROP-ROCKET tool to generate a chain that performs your desired action, such as injecting a DLL or executing a specific command. Because the entire payload is just a sequence of addresses on the stack, it is much harder to detect via static analysis.

However, this technique is not a silver bullet. It requires a deep understanding of the target binary and the specific ROP gadgets available. You need to find a way to pivot the stack to your controlled memory, which usually requires an initial vulnerability like a buffer overflow or a use-after-free. Once you have that initial control, the ROP chain takes over.

Defensive Considerations

Defending against this type of attack requires moving beyond simple signature-based detection. If you are only looking for known shellcode patterns, you will miss this entirely. Blue teams should focus on monitoring for suspicious sequences of API calls, especially those involving ntdll.dll functions like NtMapViewOfSection or NtCreateSection.

Furthermore, monitoring for unusual memory protection changes—such as a process suddenly marking a region as PAGE_EXECUTE_READWRITE—is critical. While this is a common technique for many exploits, the "shellcodeless" nature of this attack makes it even more important to have visibility into the memory management operations of sensitive processes.

This research is a reminder that as we harden our systems, attackers will find ways to use the system's own functionality against itself. The Windows API is a powerful tool, and in the right hands, it is all the "shellcode" an attacker needs. If you are interested in exploring this further, I highly recommend reviewing the official documentation for the Windows API to understand the parameters and requirements for the functions mentioned. The future of exploitation is not about writing new code, but about orchestrating the code that is already there.