Microsoft certification authority signing certificates added to the Untrusted Certificate Store

Today, we released Security Advisory 2718704, notifying customers that unauthorized digital certificates have been found that chain up to a Microsoft sub-certification authority issued under the Microsoft Root Authority. With this blog post, we’d like to dig into more technical aspects of this situation, potential risks to your enterprise, and actions you can take to protect yourself against any potential attacks that would leverage unauthorized certificates signed by Microsoft.  

We’d also like to share how this issue relates to a complex piece of targeted malware known as “Flame”.  As many reports assert, Flame has been used in highly sophisticated and targeted attacks and, as a result, the vast majority of customers are not at risk.  Additionally, most antivirus products will detect and remove this malware.  That said, our investigation has discovered some techniques used by this malware that could also be leveraged by less sophisticated attackers to launch more widespread attacks.  Therefore, to help protect both targeted customers and those that may be at risk in the future, we are sharing our discoveries and taking steps to mitigate the risk to customers.

  • How did this happen?
  • What Microsoft is doing to protect customers
  • Thumbprints of affected certificates
  • Connection to Flame malware

How did this happen?

When we initially identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft, we immediately began investigating Microsoft’s signing infrastructure to understand how this might be possible. What we found is that certificates issued by our Terminal Services licensing certification authority, which are intended to only be used for license server verification, could also be used to sign code as Microsoft. Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing without accessing Microsoft’s internal PKI infrastructure.

What Microsoft is doing to protect customers

As soon as we discovered the root cause of this issue, we immediately began building a update to revoke the trust placed in the “Microsoft Enforced Licensing Intermediate PCA” and “Microsoft Enforced Licensing Registration Authority CA” signing certificates. That update is available today through Windows Update and Automatic Updates. This update places three certificates into the Windows Untrusted Certificate Store.

We have also discontinued issuing certificates usable for code signing via the Terminal Services activation and licensing process.

Thumbprints of affected certificates

While we encourage all customers to apply the officially tested update to add the proper certificates to the Untrusted Certificate Store, as an alternative you can instead place the certificates there in another way. For example, it might be more convenient to use the certutil command or the Certificates MMC snap-in. Or you might instead choose to manage trusted and untrusted certificates in your enterprise via group policy. Here are the thumbprints of the certificates to be placed in the Untrusted Certificates Store.

Certificate Issued by Thumbprint
Microsoft Enforced Licensing Intermediate PCA Microsoft Root Authority 2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70
Microsoft Enforced Licensing Intermediate PCA Microsoft Root Authority 3a 85 00 44 d8 a1 95 cd 40 1a 68 0c 01 2c b0 a3 b5 f8 dc 08
Microsoft Enforced Licensing Registration Authority CA (SHA1) Microsoft Root Certificate Authority fa 66 60 a9 4a b4 5f 6a 88 c0 d7 87 4d 89 a8 63 d7 4d ee 97

Connection to Flame malware

Components of the Flame malware were signed with a certificate that chained up to the Microsoft Enforced Licensing Intermediate PCA certificate authority, and ultimately, to the Microsoft Root Authority. This code-signing certificate came by way of the Terminal Server Licensing Service that we operate to issue certificates to customers for ancillary PKI-based functions in their enterprise. Such a certificate could (without this update being applied) also allow attackers to sign code that validates as having been produced by Microsoft.


We recommend that all customers apply this update.

– Jonathan Ness, MSRC Engineering