Threat assesment for a captive portal
We were discussing a technique in another thread that would likely accomplish this. NSTX and ICMPTX both take advantage of common protocol holes that organizations have. NSTX is the most likely candidate since it's not likely the organization with the captive portal prevents access to the DNS proxy/server you're using to resolve the captive portal name.
If you can issue a DNS query to resolve your nameserver then you're pretty much set. This requires you manage your own DNS machine externally, but with EC2 costing what it does figure you're out 20 bucks a month to accomplish this task.
NSTX essentially uses the DNS query mechanism as a data channel. Pentesters have been using this technique for a while, and the idea is not new (botnets have even used DYNDNS C-Name resolution to create passive C&C structures.) It's a dirty world, but DNS administrators have done a great job of creating a shadow network to pass your traffic around.
A quick reference: http://think-security.com/ip-over-dns/
Good ol' Howto: http://thomer.com/howtos/nstx.html
There are two different ways captive portals / hotspots are bypassed:
Either using tunneling of some kind, usually using the DNS protocol because clients have the outgoing port 53 open, or through http/https, or using icmp to tunnel or other similar wats. @Ori has provided examples of this.
Another way is by directly bypassing the authentication mechanism: Ultimately all hotspots have to authenticate a client, and this is (usually) done through the MAC or IP address or cookies. On certain occasions these can be spoofed or sniffed to get an already authenticated session by impersonation. There may even be configured certain devices in the network, with hardcoded mac or ip address that are pre-authenticated, eg. printers, and you can take their address.
From the captive portal implementations that i have seen, after association to the AP and agreeing to/authenticating via the captive portal, the MAC address is the denominator is an allows list of sorts.
The best scenario is if there is a white list for specific users to not have to go through the captive portal. If you notice that someone is not sand-boxed by the portal, spoof their mac address and it's very likely that you will be automagically be tossed in an active VLan or removed from whatever sand-boxed group that would otherwise be forced to.
Aside from the above, which is a remote possibility, the NSTX and ICMPTX perspective presented by @Ori is an excellent idea.