Evil Access Point with Auto-Backdooring Part 2!

This post are some next steps and notes I took after my original post about using Kali NetHunter to set up an evil access point that automatically backdoors executables downloaded over HTTP. For context please see the first post.

How BDF Proxy Does What it Does

In BDFProxy's config file /etc/bdfproxy/bdfproxy.cfg you can see the different sections containing the PATCH_TYPE and PATCH_METHOD settings for the supported executable architectures:

# PATCH_METHOD overwrites PATCH_TYPE with jump
PATCH_METHOD = automatic

I had some troubles with getting certain backdoored PEs to execute after being auto-patched. To anyone running into the same problem I would suggest apt-get updating and fiddling with the different PATCH_TYPE and PATCH_METHOD options.

Before exploring those options it is important to understand how BDFProxy adds our shellcode to binaries. In order to do that we'll need to understand what code caves are in binaries. The most succinct explanation I've been able to find is from the SecureIdeas blog post on patching binaries with BDF here:

Code caves are products of code compilers. There are certain times where a code compiler will have to pad certain areas of the binary and it does so by padding with a whole series of 0x00 bytes. Those are known as code caves and BDF overwrites those code caves with malicious code. Because you are utilizing null space already present in a binary, you will not see a change in file size when using BDF.

Patch Types / Patch Methods

Keeping that in mind, here is what I've been able to find out about the different PATCH
_TYPEs and PATCH_\METHODs available in BDFProxy:

        JUMP - patch by code cave jumping
        SINGLE - put all shellcode into a single code cave
        APPEND - create our own code cave and put shellcode into it

    PATCH_METHODs - comment out to use different PATCH_TYPEs
        automatic - default, auto-backdoor by code cave jumping
        replace - replace downloaded executables with user supplied executable. Use with additional SUPPLIED_BINARY config setting 
        onionduke - onionduke implementation. Replaces downloaded exe with malware

OnionDuke, What?

I have not used the onionduke attack method. I have no reason/desire to poison Tor exit nodes. That said, the onionduke implementation can be used for more than just that attack vector. If your engagement requires that you infect users that might be wary of their downloads and could check them for backdoors, it might not be a bad idea to explore this option.

From the BlackHat 2015 paper by the BDF/BDFProxy tool author, here is a brief explanation of the onionduke attack as discovered in the wild:

Step one and two; the user downloads a PE binary over HTTP through a Malicious Tor exit node, or any node on the Internet. As the binary moves through the malicious exit node (step three), it is wrapped/patched with the unpacking stub and malware. Next the user executes (step four) the binary. Upon execution, the OnionDuke unpacking stub drops a batch file, original binary (originalname.exe.org), and malware (file.exe) in the user’s %temp% directory and executes the batch file (step 5). Next the malware is executed (step 6). After the malware has infected the machine, the batch file overwrites the packed file with the original binary (step 7). Then the batch file executes the original binary (step 8) and deletes the original file and itself in the %temp% directory. This approach is advantageous if the user believes that something is incorrect with the downloaded file and chooses to look for an expected signature or hash of the file after the initial execution – as the downloaded file will be restored to the expected original binary.

I would highly suggest reading the paper. I am not caught up on all the BlackHat 2015 talks yet, and this slipped under my radar. It is packed with interesting info on the OnionDuke attack and related attacks, and for a whitepaper it is brief (only 4 pages, 1 of those is almost all acknowledgements and references).