In Wireless Man-In-The-Middle Attacks, we configured our Linux operating system to act as a wireless router. This allowed us to bridge traffic between our rogue access point and an upstream network interface, which enabled us to manipulate traffic. In this section, we’re going to learn a no-upstream attack that can be used to pivot from one segregated VLAN to another, bypassing firewall and NAC mechanisms in the process. Before we learn how to do this, however, we’ll need to learn how to configure Linux as a captive portal.
There are multiple ways to configure Linux to act as a captive portal. The most straightforward method of doing this is by running our own DNS server that resolves all queries to the IP address of our rogue access point. Recall that in Wireless Man-In-The-Middle Attacks, we created a DHCP configuration file with the following options.
We can modify this configuration so that the IP of our external wireless interface is specified as the network’s primary DNS server using a DHCP Option, as shown below.
We then start dnsspoof as our nameserver, configuring it to resolve all DNS queries to our access point’s IP.
This is a reasonably effective approach, as it allows us to respond to DNS queries in any way that we want. However, it still has a number of weaknesses. For one thing, wireless devices that connect to our rogue access point may choose to ignore the DHCP Option, selecting a nameserver manually instead. To prevent this from occurring, we can simply redirect any DNS traffic to our DNS server using iptables.
iptables --table nat --append PREROUTING --protocol udp - -destination-port 53 --jump REDIRECT --to-port 53
Another problem with our current approach is that it does not account for the fact that most operating systems use a DNS cache to avoid having to make DNS lookups repeatedly. The domain names of the victim’s most frequently visited websites are likely to be in this cache. This means that our captive portal will fail in most situations until each of the entries in the cache expire. Additionally, our current approach will fail to capture HTTP requests that do not make use of DNS. To deal with these issues, we can simply redirect all HTTP traffic to our own HTTP server.
iptables --table nat --append PREROUTING --protocol tcp - -destination-port 80 --jump REDIRECT --to-port 80
We can incorporate these techniques into a bash script similar to the one we wrote in Wireless Man-In-The-Middle Attacks. Notice how we start Apache2 to serve content from /var/www/html.
Use your Kali VM to run the bash script that we wrote in this section to create a captive portal. Connect to the captive portal using your Windows AD Victim virtual machine. From your Kali VM, notice the terminal output from dnsspoof that shows DNS queries being resolved to 10.0.0.1. From your Windows AD Victim virtual machine, observe how all traffic is redirected to an html page served by your Kali VM. Additionally, follow the instructions found at the following URL to create a captive portal using EAPHammer:
Consider a scenario in which we have breached the perimeter of a wireless network that is used to provide access to sensitive internal resources. The sensitive resources are located on a restricted VLAN, which is not accessible from the sandboxed VLAN on which we are currently located. An authorized wireless device is currently connected to the wireless network as well, but is located on the restricted VLAN.
We can combine several of the attacks learned in this workshop to pivot into the restricted VLAN through the authorized device, even though we are located on a separate VLAN. To do this, we first force an authorized device to connect to us using an Evil Twin attack.
Once the workstation is connected to our rogue access point, we can redirect all HTTP and DNS traffic to our wireless interface as we did with the captive portal. However, instead of configuring our portal’s HTTP server to merely serve a static HTML page, we configure it to redirect all HTTP traffic to an SMB share located on our machine.
The result is that our victim is forced to authenticate with our SMB server using NTLM, allowing us to capture the victim’s Active Directory username and password hash. The hash can be cracked offline to obtain a set of Active Directory credentials, which can then be used to pivot back into the victim. This is called a Hostile Portal attack.
Although Hostile Portal Attacks are a fast way to steal Active Directory credentials, they aren’t the fastest solution to pivoting out of our sandbox. The reason for this is that password cracking is a time consuming process, even with powerful hardware. A more efficient approach is to ensnare multiple authorized devices using an Evil Twin attack, as shown in the diagram below.
Next, we use a Hostile Portal Attack as before to force Victim B (in the diagram above) to initiate NTLM authentication with the attacker. However, instead of merely capturing the NTLM hashes as before, we instead perform an SMB Relay attack from Victim B to Victim A. This gives us remote code execution on Victim A.
We use the SMB Relay attack to place a timed payload on Victim A, then kill our acccess point to allow both vitims to connect back to the target network. The timed payload could be a scheduled task that sends a reverse shell back to our machine, allowing us to pivot from one VLAN to the other. Since both victims are authorized endpoints, they are placed back on the restricted VLAN when they reassociate with the target network.
Once this happens, the attacker simply waits for the scheduled reverse shell from Victim A. Once the attacker receives the reverse shell, he or she pivots from the quarantine VLAN to the restricted VLAN.
This document offers a mere overview designed to introduce the concepts of Hostile Portal Attacks and Indirect Wireless Pivots of the reader. This is deliberate, since both of these topics are covered in detail in EAPHammer’s documentation. Your last “Lab Exercise”, if you will, is to read up on these using EAPHammer’s documentation. Make sure to read the section on Attacking WPA2-EAP Networks as well.
Once you’ve familiarized yourself with the attack, proceed to completing the lab exercise below.