Speaking of security mechanisms that even non-security folks will have some familiarity with, captive portals are a common network access control strategy. They're the walls you encounter when trying to get online in a hotel or an airplane; everything you try to access takes you to a specially configured login screen. You will receive credentials from an administrator, or you will submit a payment – either way, after you've authenticated, the captive portal will grant access via some means (a common one is SNMP management post-authentication).

I know what the hacker in you is saying: When the unauthenticated client tries to send an HTTP request, they get a 301 redirect to the captive portal authentication page, so it's really nothing more than a locally hosted web page. Therefore, it may be susceptible to ordinary web attacks.  Well done, I couldn't have said it better. But don't fire up sslstrip just yet; would it surprise you to learn that unencrypted authentication is actually fairly common? We're going to take a look at an example: the captive portal to grant internet access to guests in my house. This isn't your run-of-the-mill captive portal functionality built in to an off-the-shelf home router; this is a pfSense firewall running on a dedicated server.

This is used in some enterprises, so trust me, you will run into something like this in your adventures as a pen tester.

What we see here is the captive portal presented to a user immediately upon joining the network. I wanted to have a little fun with it, so I wrote up the HTML myself (the bad cat pun is courtesy of my wife). However, the functionality is exactly the same as you'll see in companies that utilize this NAC method. 

Let's get in the Kali driver's seat. We've already established a connection to this network, and we're immediately placed into the restricted zone. Fire up a Terminal and start Wireshark.

Not a lot is going on here, even with our card in promiscuous mode. This looks like we're dealing with a switched network, so traffic between our victim and the gateway is not broadcasted for us to see. But, take a closer look at the highlighted packet: it's coming from the gateway at 10.108.108.1 and going to 255.255.255.255, which is the broadcast address of the zero network (namely, the network we're on). We can see that it's a DHCP ACK packet – an acknowledgment of a DHCP request. So, our victim with an unknown IP address is joining the network, and will soon authenticate to the portal. Though the victim isn't the destination, we'll find the IP address assignment in the DHCP ACK packet:

Wireshark is kind enough to convert that hex into a human-friendly IP address:  10.108.108.36. We're on a switched LAN, so our victim's HTTP authentication is going directly to the gateway, right? Yes, it is, but the keyword here is LAN.