Windows 10: Suspicious connection after adding a root CA certificate

problem: unexpected unauthorised outbound traffic from Windows 10

I was adding a root CA certificate to the windows "Trusted Root Certificate Authorities" store and as the wizard finished the import... my firewall (WFC) notified me of an unauthorised outbound connection attempt. See screenshot:

Figure 1

impact: unauthorised traffic - privacy leak? / tracking?

This is a really curious connection attempt, some observations:

1. What is the request/payload windows is trying to send?
2. What the f**k is bound to 10.2.0.2 on the node? The DHCP subnet on this network card was 192.168.x.x.

I'm really curious about what windows component(s) bound a 10.2.0.0/24 ip to the interface to make that call. I've not seen that before. What and why? Maybe the certificate store has some interaction here?

I could kind of understand an explanation that perhaps Microsoft is trying to collect statistics about what CA certificates were being added to windows "Trusted Root Certificate Authorities" store, for "security reasons"... BUT its still a murky and questionable practice to not inform the user about this. Its probably covered by a "you agreed to this by using windows" T&C?!

1. There is a potential DNS leak for whatever the domain was behind 72.21.81.240.
2. There is a potential data leak to 72.21.81.240.

solution: debugging and tracing

 

I went down a bit of a rabbit hole on this one... but I did learn some stuff and got to practice some skills and techniques I don't use everyday. 

Using the 72.21.81.240 ip as a search term:

A post here on spiceworks suggested that it might be related to checking certificate revocation/validation.

A database entry on otx.alienvault.com here provided some good insights to cross reference.

I removed the newly added "Trusted Root Certificate Authorities" CA cert and tried to reproduce the steps.

The payload explained: Charles debug proxy (link) helped to determine what call was being made... I configured Charles as the default windows proxy and re-ran the import cert process to see what traffic was captured.

Note I have a licence for Charles and enjoy using the tool (since many years) but I also enjoy the excellent free and open source mitmproxy (link) - a great alternative to Charles which I use from time to time too.

Here is a snippet from the elevated prompt that runs after choosing to install the certificate for the "Local Machine":

Here is the analysis of Windows 10 DLL - cryptext.dll by nirsoft. I couldn't find any docs on CryptExtAddCERMachineOnlyAndHwndW.

The rundll32.exe process launches a wizard to install the cert (it looks like its passing the base64 cert as a parameter?) Once the wizard is completed the following request is made to Microsoft:

Charles screenshot:

The URI being called was:

http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab?577ba12e4d04eecf

This evidence defuses any major concerns about privacy/tracking/telemetry, because its clear to see that it was a valid security request to validate the CA cert vs. known disallowed cert.

This corroborates the spiceworks thread suggestion about the traffic being certificate validation/revocation checks, and the Microsoft support article titled: An automatic updater of untrusted certificates is available for Windows.

There is a related Q&A over on StackExchange InfoSec site about Understanding Microsoft list of disallowed certificates. Which breaksdown the encoding and format of disallowedcert.stl contained in the .cab at the disallowedcertstl URI:

"these are MD5 hashes (thumbprints) of explicitly untrusted certificates"

10.2.0.0/24 explained: The otx.alienvault.com data helped me to remember that I was connected to ProtonVPN US servers at the time of Figure 1. I did this write up a few hours later and had totally forgotten about being on the VPN at the time of Figure 1.

This explained why I couldn't find the DNS query and answer in my pi.hole logs! As DNS queries were going through the VPN.

When using my non-VPN default setup which utilises a local pi.hole DNS, the suspected domain was resolving 93.184.221.240 and not 72.21.81.240 which puzzled me a first - after seeing the osx data it *clicked* that the DNS servers were providing answers based on on source ip geo-location. I was able to confirm this - see screenshot of DNS resolution on and off the VPN:

Bingo! Now everything finally made sense!

Here we can see the otx.alienvault.com data corroborates the hostname and ip:

So for this case... the unexpected unauthorised outbound traffic attempt has been explained. 

Some observations:

1. The 72.21.81.240 ip has a large number of hostnames "relatively speaking" and some of those hosts are known telemetry endpoints. See here. i.e. have a certain probability of being blocked.
   
   
2. It seems kinda janky that windows isn't using the Cryptographic Services (CryptSvc) to perform the related cert blacklist/revocation check operations. CryptSvc has a higher likelihood of being allowed through the firewall vs. rundll32.exe which has a bad reputation for exploitation (see here).
   
   
3. It makes me wish windows had a default (togglable) option to prompt the user when its going outbound, so users can learn about windows behaviours, each case could have an unique id and link to a knowledge base which explains what the behaviour is and the pros and cons. Furthermore details on the sensitivity/privacy of the data being sent. I could imagine this would help people trust the vendor more and also understand the system better. For network admins and the like - it would provide useful insights especially when running corp/enterprise end user networks.