Earlier this month, I came back around to seriously considering an attempt at bitsquatting. While the prior link goes into great depth on the topic, I will attempt to give a very high level overview here:

If this sort of thing interests you: I tend to do stuff like this weekly. Give me a follow @_mattata

When you try to access a site by it’s domain, that domain is stored in the memory of your computer, device, whatever… in a structure that looks something like this.

Now let’s say that the computer is running too hot, a solar flare is happening, or a cosmic ray (very real thing) flips a bit on the computer.

Oh no! Now the value stored in memory is whndows.com instead of windows.com! When the time comes to make a connection to that domain, what happens?

nslookup whndows.com

*** can’t find whndows.com: Non-existent domain

The domain doesn’t resolve to an IP!

In fact, out of the 32 valid domain names that are 1-bitflip away from windows.com 14 were available for purchase! This is a rather odd occurance as usually these are bought up by a company like Microsoft to prevent their use for phishing attempts. So I bought them. All of them. For ~$126.

(If you’re a verifiably responsible party, I’m more than happy to transfer ownership of the domains. Otherwise, I’ll just hold on to them and continue to sinkhole.)

windnws.com windo7s.com windkws.com windmws.com winlows.com windgws.com wildows.com wintows.com wijdows.com wiodows.com wifdows.com whndows.com wkndows.com wmndows.com

Now we need to point these domains somewhere. So I rent a VPS and configure IPv4/IPv6, and create wildcard DNS entries to point to them.

Wildcard DNS works so that if I create a record saying that whndows.com points to 123.123.123.123 and someone requests abs.xyz.whndows.com, they will still get the same 123.123.123.123 DNS record as a reply. Due to the nature of this research dealing with bits being flipped, this allows me to capture any DNS lookup for a subdomain of windows.com where multiple bits have flipped.

Once we have DNS configured, we use tshark to perform a packet capture on the public interface of our VPS and wait for something interesting to happen.

Below is a short snippet of some interesting things that can be shared without uniquely indentifying any users.

Usage of GreyNoise.io was key in helping to differentiate between opportunistic scanning and actual bitflip scenarios. Great product!

NTP UDP port 123 time.windows.com

UDP packets destined for port 123 attempting to set their computer clock using the Network Time Protocol (NTP). time.windows.com is the default NTP server configured for all Windows machines and they check for the time regularly. If they don’t succeed in getting the time, they try again, and again, and again.

In total, over the course of 14 days, my server recieved 199,180 NTP Client connections from 626 unique IP addresses.

The NTP client for windows OS has no inherent verification of authenticity, so there is nothing stopping a malicious person from telling all these computers that it’s after 03:14:07 on Tuesday, 19 January 2038 and wreaking unknown havoc as the memory storing the signed 32-bit integer for time overflows.

As it turns out though, for ~30% of these computers doing that would make little to no difference at all to those users because their clock is already broken.

Using the tshark filter “ntp.xmt” we can extract the Transmit Timestamp, which is the time that the computer thinks it is when it asks to update the time.

tshark -r capture.pcap -T fields -e ntp.xmt -2 -R ntp.xmt | sort -u

Sep 28, 1984 19:41:12.638290998 EDT
Sep 28, 2012 11:59:42.976403314 EDT
Sep 28, 2029 21:50:47.552079831 EDT
Sep 28, 2100 18:13:09.180229791 EST
Sep 29, 1975 08:36:52.200231052 EDT
Sep 29, 1980 23:44:14.142299217 EDT
Sep 29, 2036 11:54:11.410350275 EDT
Sep 29, 2038 06:18:34.082394858 EDT
Sep 29, 2046 16:00:00.102963544 EST
Sep 29, 2050 06:39:18.880921186 EST
Sep 29, 2074 07:31:58.701524704 EST
Sep 30, 1999 00:29:32.120677896 EDT
Sep 30, 2009 02:54:33.318870579 EDT
Sep 30, 2049 00:14:59.396552253 EST
Sep 30, 2075 13:56:14.492526678 EST
Sep 30, 2081 01:56:58.477295064 EST

HTTP TCP port 80 sg2p.w.s.windows.com

No active DNS record exists for the correct domain sg2p.w.s.windows.com

However, the User-Agent and timing of requests suggest that this activity is directly linked to the same application that generated the traffic shown below for client.wns.windows.com and skydrive.wns.windows.com

GET / HTTP/1.1
Host: sg2p.w.s.windo7s.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 client.wns.windows.com

These appear to be directly related to Windows Push Notification Services (WNS) enable third-party developers to send toast, tile, badge, and raw updates from their own cloud service. DNS record is a CNAME to wns.notify.trafficmanager.net

DNS Records:

client.wns.windows.com.        IN    CNAME   wns.notify.trafficmanager.net.
wns.notify.trafficmanager.net. IN    A       52.177.166.224

HTTP Request:

GET / HTTP/1.1
Host: client.wns.wkndows.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 skydrive.wns.windows.com

Skydrive is what OneDrive was called before it’s name change.

DNS Records:

skydrive.wns.windows.com.      IN      CNAME   client.wns.windows.com.
client.wns.windows.com.        IN      CNAME   wns.notify.trafficmanager.net.
wns.notify.trafficmanager.net. IN      A       52.179.224.121

HTTP Request:

GET / HTTP/1.1
Host: skydrive.wns.windo7s.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36
Accept: */*

HTTP TCP port 80 time.windows.com

I have no idea where the hell this request came from or why they were fetching HTTP on a server that should be an NTP server. WHOIS for the IP that made this request shown below:

inetnum:        123.112.0.0 - 123.127.255.255
netname:        UNICOM-BJ
descr:          China Unicom Beijing province network
descr:          China Unicom
country:        CN
admin-c:        CH1302-AP
tech-c:         SY21-AP
mnt-by:         APNIC-HM
mnt-lower:      MAINT-CNCGROUP-BJ
mnt-routes:     MAINT-CNCGROUP-RR
mnt-irt:        IRT-CU-CN

GET / HTTP/1.1
Host: time.wiodows.com
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Accept-Encoding: gzip
Accept-Language: zh-cn,zh-tw
Accept: */*

Even stranger, shortly after the above request occurred, this happened! Baidu is one of China’s largest search engines. Keep in mind that I configured my DNS servers to resolve in wildcard mode. There is only a small number of ways Baiduspider could know that time.wiodows.com existed. Especially considering that only a single request had ever been made for this domain previously (seen above).

GET / HTTP/1.1
Host: time.wiodows.com
Connection: close
User-Agent: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)
Accept-Encoding: gzip
Accept-Language: zh-cn,zh-tw
Accept: */*

HTTP tcp port 80 windows.com/stopcode

When you get a blue screen of death on Windows, you are prompted to visit https://www.windows.com/stopcode Naturally, as the computer has crashed, they can’t just open the link. Most people would probably just scan the QR code, but those who misspell things ended up here.

GET /stopcode HTTP/1.1
Host: wildows.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 5.0.1; ALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.111 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

The following request was particularly interesting. Due to the nature of the request, I’m going to be very general with some details or censor entirely because it’s not exactly clear what’s going on.

An IP from somewhere in the range 113.96.0.0 - 113.111.255.255 (CHINANET-GD) makes a request from an android phone.

GET /topode HTTP/1.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 7.1.2; M6 Note Build/N2G47H; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/77.0.3865.120 MQQBrowser/6.2 TBS/045223 Mobile Safari/537.36 MMWEBID/9551 MicroMessenger/7.0.14.1660(0x27000E37) Process/tools NetType/4G Language/zh_CN ABI/arm64 WeChat/arm64 wechatdevtools
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US
Host: wintows.com
Via: 1.1 TENCENT64.site (squid/3.5.20)
X-Forwarded-For: <Department of Defence IP>
Cache-Control: max-age=259200
Connection: keep-alive

It would appear the some user in China is using squid to inject HTTP headers in every request originating in their network, including their mobile phone. Their computer gets a BSOD, so they try to look up the stopcode at windows.com/stopcode on their phone. They mis-type the url and end up at my server where we can see that they’re injecting an HTTP header for X-Forwarded-For that attempts to make the request appear as if it originated from an IP belonging to the US Department of Defense.

When I looked up the source IP on GreyNoise it showed that “This IP address has been opportunistically scanning the Internet, and has completed a full TCP connection. Reported activity could not be spoofed. This IP address has been observed by GreyNoise scanning the Internet on the following ports: 443 / TCP”

Seeing as how my traffic was recieved on 80 / TCP, this seems like it may be something they did not intend to do.

HTTP TCP port 80 windows.com/?fbclid

As is expected, someone on Facebook is going to misspell windows.com which will create a link with a unique token ?fbclid=xyz. Facebook’s crawler will attempt to fetch it, and Bing will attempt to fetch it as well if it is in another language and translate it.

GET /?fbclid=IwAR28VIBcDUlzO4XQOk9R-EWYLsnjUf-SrrKKZyAdOvrV2Mtv5JoJVO3PSUQ HTTP/1.1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Host: wintows.com
Connection: keep-alive

Summary

It should come as no surprise the the NTP service that runs on all windows machines worldwide with a default configuration using time.windows.com generated the most bit-flipped traffic. I still got a lot of traffic for other items as well. I was most suprised by just how much traffic I got from domains that were misspelled by users when typing a URL.

Takeaways:

• Bitsquatting a largely trafficked domain is still very practical to pull off.
• Automated services that are integrated into an OS create a lot of bitsquatted traffic.
• Users still misspell domains, a lot.