Recently, China Mobile broadband users in southwestern China, Jiangsu, and other regions have encountered similar problems:
- The computer can actually access the Internet;
- Windows nevertheless displays “Action needed, no Internet”;
- The default browser then automatically opens:
- Some users are ultimately redirected to unfamiliar gambling websites.
Together, these symptoms point to a chain reaction between Windows network connectivity status detection and abnormal DNS resolution. Attackers do not need to modify the Windows registry or directly control the browser. By interfering with the resolution of the domain names used by Windows for Internet connectivity detection, they may exploit the active probing feature enabled by default to trigger a malicious webpage.
This article analyzes user-observed symptoms and the publicly documented operating mechanism of Windows NCSI. As of publication, if the carrier or relevant authorities have not yet released a complete investigation report, the specific scope of impact, hijacking location, and responsible party should remain subject to the findings of the official investigation.
Conclusion First
When encountering this problem, take the following steps in order:
- Do not enter account credentials, passwords, bank card details, or verification codes on unfamiliar pages that open automatically, and do not download any so-called “network repair tools”;
- Check and change both IPv4 DNS and IPv6 DNS. Do not change only IPv4 addresses such as
114.114.114.114or8.8.8.8; - Enable Windows system-level or router-level DNS over HTTPS (DoH) wherever possible to prevent plaintext DNS from being transparently intercepted;
- Clear the DNS cache, reconnect to the network, and verify the resolution and HTTP response content of Microsoft probe domains;
- Check the router, optical network terminal, proxy, and Hosts file;
- Consider disabling
EnableActiveProbingto stop automatic probing and pop-ups only when the underlying problem cannot be addressed temporarily.
Changing EnableActiveProbing only disables the feature that automatically opens the webpage. It does not fix the DNS hijacking itself.
Why Windows Displays “Action Needed, No Internet”
Windows 10 and Windows 11 use NCSI (Network Connectivity Status Indicator) to determine whether the current network truly has Internet access.
When a network adapter connects or disconnects, or when network configuration, proxy, or routing status changes, NCSI performs active probing. On newer versions of Windows, the process mainly includes:
- Resolving
www.msftconnecttest.com; - Accessing the following URL through a plaintext HTTP request:
- Checking the HTTP status and response body. The expected normal response is:
- NCSI also queries
dns.msftncsi.comand checks whether its DNS response matches the expected result; - Windows combines active probing with passive network status to determine whether the current connection has “Internet” access, is “local network only,” or “may require authentication.”
Microsoft documentation states that Windows performs IPv4 and IPv6 active probes separately. If a probe does not complete, times out, returns an error status, or receives a response body other than the expected Microsoft Connect Test, Windows may display “No Internet” or “Action needed.”
This does not necessarily mean that all network traffic has been interrupted. It only means that the specific probe Windows uses to determine connectivity did not pass. This is why webpages can sometimes load even though the system still reports that there is no Internet connection.
Why Windows Automatically Opens /redirect
Hotels, airports, and campus networks frequently use authentication pages that require users to sign in, commonly known as Captive Portals. To help users complete authentication, Windows may open the following address when NCSI suspects that the current network requires additional action:
On a normal network, this address may subsequently redirect to Microsoft’s MSN portal, for example:
This is normal behavior designed into Windows and Microsoft services. Microsoft also uses whether the MSN page loads successfully as an additional signal for determining whether the computer can access the Internet.
It is therefore essential to distinguish between two situations:
| Final destination | Meaning |
|---|---|
Redirects to a Microsoft page such as msn.cn | Usually part of the normal NCSI follow-up process |
| Redirects to an unfamiliar gambling, fake login, or software download page | The redirect chain has been abnormally manipulated |
In other words, automatically opening /redirect is not itself evidence of an attack. Being ultimately redirected to a malicious non-Microsoft website is the critical abnormality.
How DNS Hijacking Exploits This Mechanism
The key issue is that both the NCSI Web probe and the /redirect entry point use plaintext HTTP.
If an attacker causes www.msftconnecttest.com or the IPv6 probe domain to resolve to an incorrect address, the attacker may be able to control the subsequent response:
The attacker does not need to “enable” EnableActiveProbing on the victim’s computer. This option is enabled by default on a normal Windows installation. The attacker is merely exploiting the Internet connectivity detection process that the system already performs.
Strictly speaking, the abnormality may occur at several points:
- The carrier’s recursive DNS server returns an incorrect result;
- The router or optical network terminal uses an abnormal upstream DNS server;
- Plaintext UDP/TCP port 53 queries are transparently intercepted;
- The router’s DNS cache is poisoned;
- The endpoint’s Hosts file, proxy, or malware alters the destination;
- DNS works normally, but the subsequent plaintext HTTP request is hijacked in transit.
To distinguish rigorously between “DNS hijacking” and “HTTP hijacking,” the DNS responses, HTTP response headers, or packet captures from the time of the incident must be preserved. A screenshot of the resulting webpage taken afterward is generally insufficient to determine at which hop the hijacking occurred.
Why Only Windows Displays the Warning While Other Devices Do Not
Different operating systems use different connectivity probe domains, expected response content, and interaction methods:
- Windows uses
msftconnecttest.comand NCSI; - Systems such as Android, iOS, and macOS use their own probe addresses;
- Some systems only display a Wi-Fi authentication prompt;
- Some systems do not automatically open a full browser;
- Devices on the same network may also use different IPv4/IPv6 DNS servers, caches, VPNs, or encrypted DNS.
Therefore, if an attacker interferes only with Microsoft’s probe domains, Windows will be the first to exhibit obvious symptoms while other devices may still appear normal. This does not mean that DNS is necessarily safe on the other devices. They simply have not triggered the same system behavior.
Why the Problem May Persist After Configuring 114 and 8.8.8.8
Many users only change the IPv4 DNS settings on the network adapter, for example:
However, Windows maintains separate IPv4 and IPv6 DNS configurations. Even if IPv4 DNS has been configured manually, IPv6 DNS may still be assigned automatically by the router.
Use the following command to inspect the configuration:
In the output:
AddressFamily 2represents IPv4;AddressFamily 23represents IPv6.
If you see something similar to:
then IPv6 DNS still points to the router. fe80::/10 is the link-local address range. The computer sends DNS queries to the router on the local network, which then forwards them to the optical network terminal or the carrier’s upstream servers.
Impact of IPv6 Bridge Mode
If the router has IPv6 bridging, passthrough, or Passthrough mode enabled, it may continue passing the IPv6 prefix, default route, and DNS information assigned by the optical network terminal or carrier to devices on the local network.
The path may then be:
Therefore, changing only IPv4 DNS does not override this IPv6 resolution path.
Also note that “IPv6 DNS” means a DNS server providing service through an IPv6 address. It can answer both AAAA records and A records used for IPv4. The problem is not limited to IPv6 websites.
Why Ordinary Public DNS Cannot Completely Prevent Hijacking
Manually configuring public DNS can bypass some carrier recursive DNS failures, but traditional DNS is generally still transmitted in plaintext over UDP/TCP port 53.
This means that an intermediary on the network could theoretically:
- Intercept requests sent to
8.8.8.8or another DNS server; - Forge a response that arrives more quickly;
- Block a specified DNS server and force the system to use another server;
- Return an incorrect address for a specific domain.
Therefore, “public DNS is configured” does not mean that “DNS queries are encrypted and the server’s identity has been verified.” To reduce the risk of transparent hijacking, use DoH or DoT as an additional measure.
Can DoH Prevent This Problem?
If the attack occurs only during DNS resolution, system-level DoH can generally prevent it effectively.
DoH transmits DNS queries over HTTPS, making it difficult for intermediary devices to directly inspect or alter the specific query content. The client also verifies the TLS certificate of the DoH server.
However, keep the following points in mind:
- Enabling DoH only in the browser does not necessarily cover Windows NCSI. NCSI uses the Windows system DNS client rather than the browser’s own resolver;
- Use Windows system-level DoH or deploy DoH on the router for the entire local network;
- If the configuration allows “prefer encryption, fall back to plaintext on failure,” the system may revert to ordinary DNS after DoH is blocked;
- DoH only protects DNS queries. It cannot fix a modified Hosts file, a malicious proxy, a compromised router, or subsequent HTTP hijacking;
- If the domain resolves correctly but plaintext HTTP traffic is still altered by an intermediary, DoH alone cannot solve the problem.
A more complete defense therefore consists of:
Solution 1: Configure Both IPv4 and IPv6 DNS
The following are common public DNS services:
| Service | Preferred IPv4 | Alternate IPv4 | Preferred IPv6 | Alternate IPv6 |
|---|---|---|---|---|
| Alibaba Public DNS | 223.5.5.5 | 223.6.6.6 | 2400:3200::1 | 2400:3200:baba::1 |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | 2001:4860:4860::8888 | 2001:4860:4860::8844 |
| 114DNS | 114.114.114.114 | 114.114.115.115 | — | — |
The reachability and latency of public DNS services may vary between regions of mainland China. Prioritize a service that provides a stable connection and supports encrypted DNS.
Windows 11 Graphical Interface
- Open “Settings”;
- Go to “Network & Internet”;
- Open the currently used “Ethernet” or “Wi-Fi” connection;
- Find “DNS server assignment” and click “Edit”;
- Change “Automatic (DHCP)” to “Manual”;
- Enable both IPv4 and IPv6;
- Enter the preferred and alternate DNS servers;
- If the system provides a “DNS over HTTPS” option, enable it;
- Save the changes and reconnect to the network.
If you use Alibaba Public DNS, its DoH address is:
Configuration Using Commands
Using the network adapter named “Ethernet” and Alibaba Public DNS as an example, open PowerShell as an administrator:
Then clear the DNS cache:
Check again:
If IPv6 DNS still shows the router’s fe80::... address, the setting was not applied to the current network adapter, or the router, Group Policy, VPN, or another component is taking control of DNS again.
Solution 2: Configure IPv6 DNS or DoH on the Router
If multiple devices in your home use the same broadband connection, configuring the router centrally is more convenient.
Open the router’s administration page and check:
- The IPv4 DNS used by WAN and LAN;
- Whether IPv6 DNS is set to “Obtain automatically”;
- Whether IPv6 is operating in bridge, passthrough, or Passthrough mode;
- Whether custom IPv6 DNS is supported;
- Whether DoH, DoT, or encrypted DNS is supported;
- Whether there are unfamiliar static DNS, port forwarding, or remote administration settings.
If bridge mode forces the router to inherit DNS from the optical network terminal or carrier, you can:
- Manually configure IPv6 DNS and system-level DoH on each endpoint;
- Where supported, have the router obtain the IPv6 prefix and specify DNS itself;
- Deploy encrypted DNS forwarding on the router.
Do not change the operating mode of the optical network terminal without understanding how dialing and prefix delegation are configured, as doing so may disconnect IPv4 or IPv6 connectivity.
Solution 3: Verify That DNS and NCSI Have Recovered
Check System DNS
Query the IPv4 and IPv6 Probe Domains Separately
Do not rely on a fixed msftconnecttest.com IP address to determine whether the result is normal. Microsoft’s probe service is hosted on a CDN, so legitimate addresses may vary by region and over time. More reliable methods include:
- Comparing the result with one returned by a trusted DoH service;
- Checking whether the CNAME points to a legitimate CDN used by Microsoft;
- Checking the HTTP response content and redirect destination;
- Preserving the original response when the abnormality occurs.
Check the Probe File
A normal result should include:
If the current network does not have public IPv6 connectivity, failure of the second command does not necessarily indicate hijacking.
Check /redirect Without Automatically Following It
Inspect the following response header:
If the destination is a Microsoft or MSN page, this is usually normal behavior. If it points to a gambling site, fake login page, or unfamiliar download site, immediately preserve the response headers and timestamp, and do not continue visiting it in a browser.
Why /redirect May Still Be Accessed After Changing DNS but Only Redirects to MSN
Changing DNS only restores correct resolution. It does not disable the Windows NCSI feature.
If Windows has already entered the “Action needed” state because of a previous failed probe, or if it reevaluates the connection after the network reconnects, it may still open:
The difference is:
- When DNS is hijacked, the request may reach the attacker’s server and redirect to a gambling website;
- After DNS is restored, the request reaches Microsoft’s server and redirects normally to MSN.
Therefore, seeing MSN after changing DNS usually indicates that the malicious redirect has stopped, not that the DNS change failed to take effect.
Should the Hosts File Be Checked?
Yes, but it is not the highest-priority suspect in a carrier-wide incident.
Windows checks the local Hosts file before querying a DNS server. If the file contains a relevant mapping, changing DNS will have no effect.
Hosts file path:
You can inspect it using PowerShell:
Normally, there should be no custom mappings for these domains.
If multiple devices on the same broadband connection experience the problem simultaneously and recover after switching to mobile data, the problem is more likely to be in the router, optical network terminal, or carrier network. If only one device is affected, prioritize checking its Hosts file, proxy, virtual network adapters, malware, and browser extensions.
You can also check the WinHTTP proxy:
Temporary Measure: Disable EnableActiveProbing
If the underlying DNS problem cannot be resolved immediately and you want to stop Windows from automatically triggering probes and webpages, you can disable NCSI active probing.
Registry path:
Set:
to:
You can also use an elevated PowerShell session:
To restore it, set the value to 1:
Back up the registry before making changes. Microsoft does not recommend disabling NCSI active probing as a long-term fix because Windows Update, Outlook, and other applications may rely on NCSI’s connectivity status assessment.
After disabling it, the effect is:
However, the underlying problem may still exist:
Therefore, this is a temporary loss-limitation measure, not a permanent solution.
What Evidence Should Be Preserved?
If the problem occurs again, record the following before closing the page:
- The time of occurrence and your region;
- The broadband carrier;
- The current IPv4 and IPv6 DNS servers;
- The complete output of
Resolve-DnsName; - The HTTP status and
Locationof/redirect; - The full address and a screenshot of the malicious page;
- Whether other devices on the same network are affected;
- Whether connectivity returns to normal after switching to mobile data.
If possible, use Wireshark to capture:
For IPv6 router advertisements, use:
Pay particular attention to the RDNSS information in the Router Advertisement. It can show where devices on the local network obtain their IPv6 DNS configuration.
This evidence is more useful than a single webpage screenshot taken afterward when determining whether the problem occurred on the endpoint, router, optical network terminal, or carrier network.
Summary
The core of this incident is not that “Windows opened a gambling website by itself,” but rather:
- Windows uses NCSI to actively detect Internet connectivity;
- NCSI accesses a plaintext HTTP probe address;
- DNS hijacking causes the probe request to reach the wrong server;
- The incorrect response causes Windows to determine that the network “requires action”;
- Windows then opens
/redirect; - The hijacked resolution once again directs the browser to a malicious website.
When resolving the problem, distinguish among three levels:
- Change both IPv4 and IPv6 DNS and enable system-level or router-level DoH. This is the core response to DNS hijacking;
- Check the router, optical network terminal, Hosts file, and proxy. These are necessary steps for ruling out local tampering;
- Disabling
EnableActiveProbingonly stops automatic system probing and pop-ups. It does not fix the underlying hijacking.
Finally, do not enter any information on an unfamiliar redirected page, and do not download software recommended by the page. When an abnormality is detected, prioritize closing the page, preserving evidence, changing DNS, and reporting the incident to your broadband carrier.
References
- Microsoft Learn: NCSI Active Probing, Automatic Sign-In Pages, and MSN Portal
- Microsoft Learn: Network Connectivity Status Indicator Overview
- Microsoft Learn: NCSI Troubleshooting Guide
- Microsoft Learn: Windows DNS over HTTPS Client Support
- Microsoft Learn: Windows DNS Query and Hosts Resolution Order
- Alibaba Public DNS
- Google Public DNS