Security & Threat Intelligence · 25.07.2026, 15:30 UTC
Captive Portal Detection, (Tue, Jul 21st)
| Schweregrad | info |
|---|---|
| Kategorie | Security & Threat Intelligence |
| Quelle | SANS Internet Storm Center ↗ |
| Veröffentlicht | 25.07.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
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 …