Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I'm trying to monitor the HTTP requests/responses made when performing a Windows Update.

I have a Windows 8 machine configured with a proxy in IE. I've also imported via netsh for winhttp:

netsh winhttp import proxy source=ie

The proxy is running on another machine on port 8080 and is configured to intercept SSL.

I have tried both with Burp proxy or with a normal Squid proxy (using ssl_bump). The root CA certificates are installed on the Windows 8 machine, in the Local Machine store, under Trusted Root CAs. If I browse from IE or Chrome I can access https sites without a warning (as the presented server certificate is signed by the proxy CA).

However, if I try to use Windows Update I get an error:

"There was a problem checking for updates"

This is a known issue, Bluecoat advise adding an exception for SSL interception for Windows Update:

Microsoft make the same recommendation for TMG:

So it seems like the Windows Update service doesn't just check the certificate in the usual way, it actually verifies against a different CA list, or specifically requires a certain server certificate from the Windows Update site.

The question is, how can I work around this, so that I can see the HTTP requests made by Windows Update?

share|improve this question
yes windows update has it's own pinned certificate list to stop such intercepts. However there is Windows Server Update Services which is run as a server inside a network so only one place needs to download the updates across the WAN to distribute to the whole LAN. How it gets over the SSL certificate issue I'm not sure. –  ewanm89 Mar 3 '13 at 13:39

2 Answers 2

Among possible updates are updates of the default contents of the trust store itself. If Windows was using the default trust store then any CA in that store could edit a forged update which would evict its competitors. It could also alter about any part of the OS. For an OS, the path for updates is very sensitive. It would be quite risky to give the power of updates to a hundred or so of CA, not all of which can be really trusted to do their job properly (mishaps have happened, not often, but yet...).

What you might try is to add your fake certificate for the Windows Update SSL server into the "trusted publishers" store (the one for the "local computer"). Include the fake server certificate itself, not the Burp-controlled CA which issues fake certificates on-the-fly (I don't know if Burp can use a specific non-dynamic fake certificate for a given server). This store is normally for validating signatures on drivers, not for SSL servers, but given the way Microsoft handles certificates, this may work and do what you want (I don't have a Windows machine handy to try that right now).

If the Windows code does not use an easy-to-access trust store, but instead hardcodes the list of acceptable certificates for the Windows Update server, then you will have to resort to DLL modifications, like malware writes do for a living. The OS will try to actively defend against that.

share|improve this answer
The fake certificate which is suppose to be included in the store, would it not trigger as FALSE or Fake by the Microsoft CA as its not signed by its CA. Don't you think Microsoft can inject the clients certificates on the fly for the update and then remove it. –  Saladin Mar 3 '13 at 16:14

This problem has challenged me for a while but did find a way through it. Typically it manifests as Windows Update Error 80245006 or 803D000A

I wrote a tool called SuperPhishers in March 2015 that will allow you to bypass the windows internal check that the certificates are really truly from Microsoft. The name is a play on the SuperFish Lenovo controversy at time.

The easy part is having your SSL proxy generate something modern: like RSA>=2048 and SHA256RSA, etc. I used sslsplit and modified it to generate SHA256 digests. Windows requires SHA256 on its update and store certificates or it fails with 0x803D000

The hard part is bypassing Windows checks that the CA Cert is Microsoft:

Basically there are two functions that implement a checks that the CA cert is legit. They are both called DetermineSubCAIdentity in wuaueng.dll and storewuauth.dll Using Nektra Deviare2, the function DetermineSubCAIdentity was hooked so that it always completed leaving EAX=3. This allows the Microsoft check to pass and the update or store function continues as normal.

If you patch this function in both dll's it allows interception of Windows Store traffic. Review your intercepted traffic or run through ICAP to rewrite fun.

I made a video here:

The code and technical write up is here:

Thomas Pornin is correct in that you need to modify dll's -- When I modified the dll's on disk, SFC did replace them with good ones. However doing it in memory with Deviare2 injected into a SYSTEM process, Windows 8.1 didn't seem to care.

Hope this helps and it was enjoyable to see that Windows Update traffic in the clear for the first time.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.