Who is 2.16.4.xxx

So I got a question from a customer. Their firewall team detected that clients tried to connect to 2.16.4.xxx (I replaced the last octet with x’s to protect the innocent).
So who is 2.16.4.xxx, lets start with a simple reverse dns query

So now we know that we are talking about Akamai, well that doesn’t really help since it is the or one of the biggest CDN’s in the world.

  1. So I asked the firewall team for information what was sent and they couldn’t help me.
  2. So we need to figure out which name is pointing to the IP. And I didn’t have access to the clients to check either. If I had access to a client I could have run “ipconfig /displaydns” this would have given me the same kind of information as I got from the cache.
  3. But wait I do have access to the DNS servers. Lets check in the DNS Cache.

Exploring the Windows DNS Server cache

Lets dump the entire cache to a file so we can work with it.

Now we have a good file to look through. Lets start looking for A record is pointing to 2.16.4.xxx. I found another akamai name, so I needed to see what CNAME was pointing to that name and so it went a two times.. But in the end we found it. Below is the interesting parts of the dump I did.

So in the end the client tried to reach crl.microsoft.com. This is a standard case why locking down your firewalls by IPs can be a time consuming endeavour.

Check state of CRL checking.

Okey I had the need to check what values were set for the Software Publishing “State”. This is the registry value where Windows stores if it should do CRL revocation check or say all okey even if the CRL is unavailable. And some other stuff. I found all the values on the MSDN page WintrustGetRegPolicyFlags. So I wrote a small Powershell function to help decode it.

Example of running Get-WintrustGetRegPolicyFlags

And here is the function: [Read more…]