October 23, 2021

I am a big fan of Nir Sofer. He creates great utilities for Windows and his software is both free and portable. Recently, he released a new DNS logging program DNSLookupView.

He already had a DNS logging program called DNSQuerySniffer but the new program gets its raw data from a different source. So, I have been running both of them side by side to see the pros/cons of each.

And, while logging DNS requests on a Windows 10 machine, I came across some interesting stuff. The computer in question was running Windows 10 Home Edition, service pack 20H2, build 19042.1083, which means it has bug fixes as of July 6, 2021. It was logged on with a local account, not a Microsoft account. It was also locked down as much as possible. Every customization I could find in the Systems Settings was disabled. Many of the scheduled telemetry tasks were disabled.

With the DNS logging programs running, I happened to look at the System Settings.

I didn't change anything, just looked at a couple settings.

DNSLookupView showed that this generated two DNS queries, one for www.bing.com and another for cxcs.microsoft.net. If you are thinking WTF? So was I. You can see the DNS log below.

 DNSLookupView output 

The queries were made by program C:\Windows\ImmersiveControlPanel\SystemSettings.exe and the query type was AAAA. The sub-domain www.bing.com resolved to ::ffff:13.107.21.200 and ::ffff:204.79.197.200. The sub-domain cxcs.microsoft.net resolved to ::ffff:96.17.141.116.

Of course a DNS query is not data transmission. Typically, however, it immediately precedes a data transmission.

After seeing this the first time, I ran a second test that looked for data transmission. For this, I used another Nir Sofer program called TcpLogView that logs every outbound TCP request. If Windows is phoning home via UDP, I would not see it.

Below is the output from TCPLogView for the exact same second (2:30 and 51 seconds) as the DNS queries for www.bing.com and cxcs.microsoft.net.

 TCPLogView showing outbound requests 

We see that program C:\Windows\ImmersiveControlPanel\SystemSettings.exe made two outbound requests. The first was to port 443 (HTTPS) at IP address 13.107.21.200 which is www.bing.com. The second was to port 443 at IP address 96.17.141.116 which is cxcs.microsoft.net. Twenty seconds after opening a socket to these two computers, SystemSettings.exe closed the socket.

Clearly Windows 10 spies on you any time you use the System Settings.

What else are they spying on?

What I did is quite repeatable, feel free to try it yourself.

NOTE: I did not log the actual data being transmitted between my computer and Microsoft. Since it went to the HTTPS port (443) it was surely encrypted.

I wondered what cxcs.microsoft.net is. When I viewed the site in a browser, it returned 2021.1019.1.0, whatever that means. It was not even HTML, just plain text. A search for the sub-domain turned up a guess that it might be the Microsoft customer experience center. There is/was a Microsoft Customer Experience Center that went by CXC. I also found it on a list of domains to be blocked by AdGuard or PiHole.

As for www.bing.com, it clearly is doing double duty. More than just a search engine, it seems to be used for telemetry too.

BLOCKING CXCS.MICROSOFT.NET

The first thing I did was block access to cxcs.microsoft.net (more on this below). Then, I ran the above test again to make sure that I could still use the System Settings app. And, another interesting thing turned up.

The System Settings worked without access to cxcs.microsoft.net, but in testing, I saw another DNS request, this time to ctldl.windowsupdate.com. I tested it twice and each time program SystemSettings.exe made DNS requests for www.bing.com and ctldl.windowsupdate.com. I had already blocked the Windows Update website so the only outbound request it could make was to Bing.

The next day, I tested again and the result is shown below.

 More DNS Queries the next day 

This time, program SystemSettings.exe tried to resolve all three servers. Two of them resolved to IP address zero thanks to my router. It made the one outbound TCP request that it could, to www.bing.com at 13.107.21.200 (port 443). My testing of the Settings app was very quick. I have to wonder if I looked at many different settings and actually changed a setting or two what other servers Windows would try to phone home to.

Clearly Bing is more than a search engine. It seems to be spying on us.

DONT SPY ON ME

What are some Defensive Computing responses to this?

Personally, I modify my router (the Pepwave Surf SOHO) to resolve queries to domains that I want to block to zero, which is an invalid IP address. I can do this because the router includes a customizable DNS server. This, however, is not something people with a consumer router or a router provided by their ISP can do. Pepwave/Peplink routers are for professional use and thus have advanced features such as internal DNS server.

Another option for techies is Pi Hole, a DNS server that is typically installed on a Raspberry Pi computer that is connected to a router. It too, can force a domain or sub-domain to resolve to an invalid IP address and it should work with any router.

Note however, that when you are using a VPN or Tor (and probably Cloudflare WARP too) any DNS or firewall rules in the router are bypassed. DNS rules are also bypassed when using a web browser configured for Secure DNS. A number of VPNs offer tracker blocking, so maybe some of them block cxcs.microsoft.net. Maybe.

Focusing one computer, rather than an entire network, YogaDNS should let you use NextDNS system-wide. One big upside to NextDNS is that you can create customized Black/Block lists. If you don't want a computer to ever visit cxcs.microsoft.net, you can block it with NextDNS. I have not tried YogaDNS.

Another approach for a single computer is to install a firewall that offers outbound control, something akin to Little Snitch on macOS. For inspiration see this August 2021 article by Michael Bazzell: Minimizing macOS Telemetry.

Bing is an interesting case as the website is both involved in spying/telemetry and a search engine. Blocking it on the entire LAN means that it can not be used as a search engine, so I went old school and modified the "hosts" file in Windows to force www.bing.com to resolve to a zero IP address. Then, I flushed the Windows DNS cache and went back to the System Settings.

This time, however, I stayed in the Settings a bit and went to a few different sections. Previously, I had just gone in and out. The DNS query log is shown below. The spying Windows does is worse than it first appeared. It looks like Windows wants to record every section that you visit.

 Kicking more tires in System Settings 

All the DNS requests above resolved to the zero IP address, except for sub-domain ecn.dev.virtualearth.net. I don't know if this domain was triggered by the Settings app or if Windows did it for unrelated reasons. It came from svchost rather than from SystemSettings.exe. There was an outbound request made to port 443 at 23.78.209.31 which is the IP address of the virtualearth domain.

The requests to wpad are a bit off-topic. Not shown in these screen shots is that DNSLookupView also reports the process ID that made the DNS request. This can be used to determine the specific Windows service that is running under the control of svchost.exe. On this particular PC, it was the WinHTTP Web Proxy Auto-Discovery Service (WinHTTPAutoProxySvc). According to Microsoft, the service handles the automatic discovery of a proxy configuration via the WPAD (Web Proxy Auto-Discovery) protocol. The service is running, the startup type is Manual and, even logged on as an Administrator, I can not disable it. The service should not be running, the WPAD feature is disabled. You can check this in Windows 10 at Settings -> Network and Internet -> Proxy (in left side vertical column). Fortunately, all the DNS requests are failing. For more on this see Disable WPAD in Windows to Stay Safe on Public Wi-Fi Networks by Chris Hoffman (March 2017). Yet another Windows annoyance.

The most important point, however, about this trace data is the many requests to both cxcs.microsoft.net and www.bing.com by SystemSettings.exe. Microsoft really wants to know what we are doing.

HOSTS FILE

Of the many defensive steps, modifying the hosts file should probably be avoided. DNS on Windows 10 is more complicated that it used to be with earlier versions of Windows. I suggest blocking www.bing.com network-wide (router, Pi Hole). If you wanted to do a Bing search, the simple work-around is to use DuckDuckGo which gets its search results from Bing.

To test blocking sub-domains with the hosts file, I configured it to resolve www.bing.com to 1.2.3.44 and nh.craigslist.org to 1.2.3.55. I did this just in case Microsoft treated either the zero IP address or Bing as a special case. After modifying the hosts file, I re-started Windows. Then I tested using the nslookup command, the ping command and a couple web browsers. The results were not what I expected.

The nslookup command returned valid IP addresses for both sub-domains, rather than the dummy IP addresses I put into the hosts file. Beats me why. DNS logging showed that nslookup queried my router for the IP addresses.

A ping to each of the two sub-domains was just the opposite, the ping command tried to contact the dummy IP addresses in the hosts file.

Some DNS logging, while I was not using the computer, showed that program SearchApp.exe picked up the dummy IP addresses from the hosts file.

A number of different web browsers could not display either www.bing.com or nh.craigslist.org so they were clearly getting their IP addresses from the hosts file. I was surprised that even two browsers using Secure DNS failed to display these pages, which means the Secure DNS servers were not used. Might be a bug.

FINISHING UP

I don't think the spying that Microsoft does on Windows users gets the attention it deserves.

If you want to stop Microsoft/Windows from spying on you, the programs mentioned here are great at illuminating the servers that Windows communicates with. I block the sub-domains listed below and have not observed an obvious problem.

1. browser.events.data.msn.com
2. browser.events.data.microsoft.com
3. config.edge.skype.com
4. cxcs.microsoft.net
5. evoke-windowsservices-tas.msedge.net
6. self.events.data.microsoft.com
7. settings-win.data.microsoft.com
8. settings.data.microsoft.com
9. umwatson.events.data.microsoft.com
10. watson.telemetry.microsoft.com

Your mileage may vary :-) It is probably safest to block one or two of these at a time, just in case.

If you do not use any Microsoft services, you may be able to also block login.live.com and login.microsoftonline.com. The first one has appeared quite often in my DNS request logs.

As for me, I am going to try blocking www.bing.com on my LAN and see if it interferes with anything.

- - - - - - -

Update: A few things about that. DNS blocking in the router (or Pi Hole) is bypassed by browsers configured to use Secure DNS. It is also bypassed when using a VPN. Still, this is not all bad as we are mostly concerned with Windows using www.bing.com for telemetry when not using a web browser. On another note, I would have thought that other bing.com sub-domains such as news.bing.com or images.bing.com would not be affected by a DNS block of www.bing.com. Each sub-domain is a free agent. But, it turned out that Microsoft re-writes these to www.bing.com/news and www.bing.com/images/, so they get blocked too.

For what its worth, I have also seen DNS queries for www.bing.com from an instance of svchost that is running two services, the Base Filtering Engine and the Windows Defender Firewall. Finally, program SearchApp.exe has also tried to resolve it. The full path was
C:\Windows\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe

- - - - - - -

Much more comprehensive, but related, research was done by Helge Klein in March 2021. He found that Windows talks to 291 hosts/servers and 2,764 unique IP addresses. See Windows OS, Services & Apps: Network Connection Target Hosts.