Not everything our honeypots detect is an attack. Sometimes it is just "odd traffic", and this is one example: Our "First Seen" list currently includes "http://detectportal.firefox.co
m/success.txt" as one of the new URLs detected by our honeypots. The hostname "detectportal" kind of gives away what is happening here. 

If you have ever tried to connect to a public WiFi network, you probably ran into some type of "captive portal". A splash screen that will ask you to acknowledge some kind of user agreement or require you to log in. Of course, each implementation looks a bit different, and browsers and operating systems attempt to detect these captive portals. Typically, the operating system will automatically direct you to the correct portal page.

It used to be easier to deal with captive portals. Back in the "old days" (not necessarily "good old days"), users often had a non-TLS page configured as their homepage. The captive portal was able to intercept this connection and direct the user to the captive portal's login page. These days, however, most websites use TLS, and browsers default to TLS for many sites and refuse to switch to a non-TLS site. This made using WiFi networks a lot safer, but it gets in the way of directing users to a captive portal.

In response, operating systems and browsers implemented features to detect captive portals. The system will attempt to pull up a specific http URL to detect if it receives a redirect response. If so, it will open the redirect URL in a browser. You will see these URLs as systems join your network, or if the browser is started. The URL does provide some intelligence as to what operating system or browser is being used. Here is a quick summary of what URLs different operating systems use:

Windows: http://www.msftconnecttest.com/connecttest.txt . This is part of the Windows Network Connectivity Status Indicator, which was introduced in Windows 8. Windows 10 and later will attempt to access the URL and check for a valid response. The response should be "Microsoft Connect Test". In addition, it will do a DNS lookup for dns.msftncsi.com. [1]

Apple: Recent versions of MacOS and iOS use http://captive.apple.com/hotspot-detect.html as a test. The expected response is "Success". If the system can not connect, Apple's Captive Network Assistant starts to assist the user in logging in.

Android: http://connectivitycheck.android.com/generate_204. The result page is empty, and uses a status code of 204 (No Content).

Chrome: http://www.gstatic.com/generate_204. Slightly different URL than Chrome, but works the same way expecting a "204 No Content" response. Chromium implements the same system with http://clients3.google.com/generate_204 [3]

Firefox: http://detectportal.firefox.com/canonical.html. This page returns a 200 status code. The body of the page includes a META tag to redirect users to a page explaining how Firefox deals with captive portals (I like this.. as an analyst, it is neat to have the page explain what it does) [4]

All these URLs use HTTP so the captive portal can redirect the request. This is necessary for the client to discover the captive portals' "splash screen". If you are ever "stuck" and can't find the captive portal for a network, opening any of the URLs above in your browser may redirect you to the sign-in page.

[1] https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/internet-explorer-edge-open-connect-corporate-public-network#ncsi-active-probes-and-the-network-status-alert

[2] https://grpugh.wordpress.com/2014/10/29/an-undocumented-change-to-captive-network-assistant-settings-in-os-x-10-10-yosemite/

[3] https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection/

[4] https://support.mozilla.org/en-US/kb/captive-portal

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|