Press "Enter" to skip to content

Post Explotation Backdooring II

Last updated on September 18, 2020

This is the second part of the set of posts about Post Explotation Backdooring. If you haven’t read the previous post, I recommend you do so to understand this post. Again I want to thank OscarAkaElvis, who taught me these PE Backdooring techniques.

In the previous post we saw how to introduce the code of a reverse shell in a program, creating a Trojan. However, in real life this technique is more than known by antivirus, and it will not work.

First of all, because it is very rare for a program to have a JMP as its first instruction.

On the other hand, it is easy to verify that the size of the executable is larger than the original, since we had to create a cave of code to introduce the shell.

In this second post I’ll explain how to avoid these two problems, making the trojan undetectable for almost any antivirus.

Natural Code Cave

We’ll avoid having to create a new piece of code and add it to the program, since doing so increases its size and creates a new section, something very detectable.

To do this, let’s look for a natural code cave. That is, a section of the program that is already empty. It is usual to find in the executable code segments that are not used in the program and are set to null. You only have to find one big enough to fit the shell code.

There are several programs that can allow you to easily find a natural code cave. The one I use is a linux program called cave_miner. Since the shell occupies 324 bytes, we selected a cave of about 500 bytes, to go comfortable:

The tool has detected two code caves of that size in the program. Choose any one, in this case the one below, and point to the start address (the vaddress): 0047972e.

Now let’s solve the second problem of the previous post: the initial JMP.

Hidden jump

Instead of making the jump to the code cave at the beginning of the program, let’s debug the code and select a point from the more advanced code, so that when the natural flow of the program passes through there, it jumps to the code cave. The usual thing is to do it in a point in which the program has to pass without the need for user interaction, so the malware is executed transparently to the user. However to make this PoC clearer I’m going to use as a jump point the instruction that is executed when the user presses the button that you can press in 7-zip (that takes you to the official page) and that is in Help -> About 7-Zip:


To find this functionality in the code, using Immunity Debugger, first press the play button to take you to the first line that runs, then right click, Search for, All referenced text strings, and go up until you find the string “”:

Go to the memory address 0044A8E5 and there you execute the jmp to the natural code cave, remembering to save the following instructions to restore them later:

0044A8E5   . 68 0C084600    PUSH 7zFM_met.0046080C                   ; |FileName = “”

0044A8EA   . 50             PUSH EAX                                 ; |Operation => NULL

0044A8EB   . 50             PUSH EAX                                 ; |hWnd => NULL

In this case it has not corrupted any of the instructions below, so then you only have to restore the instruction that we have overwritten with the jmp. Now let’s go to the code cave and do the same as in the previous method: we save the state of the registers (PUSHAD, PUSHFD), we paste the shell, we correct with the 3 NOPs, we put the breakpoints at the beginning and at the end, we calculate the difference of the ESP register (remember that to get to the second breakpoint you have to listen to the attacking machine and you have to click on Help -> About 7-Zip), we correct the instructions that we overwrite with the JMP and we make a JMP to the next instruction that would have to be executed. If you have any doubt about this process, consult the previous post. This is the whole lower part of the cave code, as it would be in the end:

And you would already have your program with backdoor, and with very few antivirus that detect it. Without going any further, nowadays Kaspersky is unable to detect malware if you scan the executable.

However, there are still some antivirus programs that detect it. This is because the instructions of the payloads that create a reverse shell are known to some antivirus. They are few, but the idea is to make an undetectable malware, not a little detectable one. I’ll fix this in the next post.



  1. […] first part I showed you how to create a basic code cave in an executable to introduce a shell. In the second part I improved its detection rate using natural code caves and hiding the jump to the cave between the […]

Leave a Reply

Your email address will not be published. Required fields are marked *

Mission News Theme by Compete Themes.