When Certificate Trust Fails: The DigiCert Code-Signing Incident and Microsoft Defender False Positive

 A recent Microsoft Defender signature update removed legitimate DigiCert root certificates from Windows systems, triggering disruption and raising questions about why these certificates were identified as malicious. At first glance, it looked like a false positive — and Microsoft later confirmed and corrected the detection — but the timing pointed to a potentially related broader issue: a recent DigiCert compromise. In this blog post we will explore these two items in context together and pull some threads on related attacker activity.

What happened?

On May 3rd, Microsoft Defender released signature updates (1.449.424–425) that incorrectly flagged legitimate DigiCert root CA certificates as malicious (Trojan:Win32/Cerdigent.A!dha). As a result, these certificates were removed from the Windows certificate store, causing disruption across affected systems.

The impacted certificates included:

DigiCert Assured ID Root CA (Thumbprint:  0563b8630d62d75abbc8ab1e4bdfb5a899b24d43) 
DigiCert Trusted Root G4  (Thumbprint: ddfb16cd4931c973a2037d3fc83a4d7d775d05e4) 

Microsoft later acknowledged the issue in DZ1299600 and resolved it in signature version 1.449.430.

Microsoft has committed to publishing both a preliminary and final post-incident report to provide further detail this week.

Related Context: The DigiCert Code-Signing Incident 

The Defender issue should be treated as a false positive based on the information currently available. The important distinction is that Defender flagged legitimate DigiCert root certificates, while DigiCert’s separate incident involved compromised or misused code-signing certificates.

That said, the DigiCert incident provides important context. It demonstrates the type of certificate-abuse activity that defenders and security vendors were actively responding to at the time and helps explain why certificate trust became a focus.

According to DigiCert’s incident disclosure, attackers:

• Socially engineered support staff via web chat
  
  

• Delivered a malicious .scr file (executable) disguised in a ZIP archive
  

• Gained access to internal systems and the DigiCert portal to operate from the perspective of legitimate customers

• Obtained activation codes from approved orders, which are needed to initialize EV hardware tokens used for code-signing.

A total of 60 certificates were affected, spanning multiple regions and industries. A sampling of affected vendors companies is listed below:

To determine whether the compromised certificates were being actively abused, we created a script to search VirusTotal for samples signed with certificates matching the compromised thumbprints. The search returned 39 samples, 10 of which are shown below.

 A full list of certificate checksums and associated file hashes can be found here.   

Initial analysis of the VirusTotal samples identified overlaps with the activity described in DigiCert's incident report, which states that exploited certificates were used to sign the "Zhong Stealer" malware family. Some of the observed infrastructure, including uu[.]goldeyeuu[.]io, has also been associated with APT-Q-27 reporting.

While this does not by itself establish attribution, it provided useful pivot points for identifying additional related samples and revoked code-signing certificates, including a sample signed by "Xiamen Lede Song Information Technology Co., Ltd." and chaining to a Sectigo AAA root certificate.

 Why compromised EV code-signing workflows can be high impact

With standard code signing, the Certificate Authority does not hold the customer’s private key material. If an attacker gains access to a CA portal, they cannot simply retrieve an existing private key and use it to sign malware. They would generally need to cause a new certificate to be issued or reissued, generate or control the corresponding key material, and satisfy whatever account, order, and approval controls are in place.

EV code signing is designed to provide stronger assurance, not weaker assurance. It adds stricter identity validation and requires hardware-backed key protection. However, the DigiCert incident highlights a different risk: the surrounding provisioning and activation workflow can become an attack path.

In this case, DigiCert reported that the threat actor accessed activation codes for already-approved EV code-signing certificate orders.

Those activation codes, when combined with the approved orders, were functionally sufficient to generate and retrieve the corresponding certificates. This allowed the attacker to obtain certificates representing legitimate organizations without compromising the organizations’ existing private keys or creating a separate fraudulent identity.

The impact is significant because malicious binaries signed with a valid certificate may appear more trustworthy than unsigned malware. This can affect controls that rely on publisher or certificate trust, including enterprise allow rules, reputation-based decisions, and user trust prompts.

For defenders, the key lesson is not that EV certificates are inherently unsafe. Rather, it is that even high-assurance certificate models still depend on the integrity of the issuance and activation process. Where application control policies trust publishers or certificates broadly, a compromised or misused certificate can become a path to execution. A default-deny model reduces this exposure by requiring explicit local policy approval before signed code is allowed to run. 

What This Means for Application Control Defenders?

For organizations using application control (allowlisting), the impact of this incident depends on how trust is defined within your policies — particularly if you allow execution based on publisher trust.

If your environment trusts software by publisher, you should:

• Review the list of affected vendors

• Confirm that none of these publishers are present in your trusted allow rules

If a compromised publisher is trusted, there is a risk that malicious binaries signed with those certificates could be allowed to execute under existing policy.

This is where a default-deny posture provides a clear advantage. Unless the affected publisher has been explicitly trusted, binaries signed with those certificates will not be allowed to execute simply because they carry a valid signature. 

This limits exposure to third-party trust failures, including incidents involving legitimate certificate misuse.

What about explicitly blocking files signed by compromised certificates?

For organizations that want to take a more defensive approach, additional controls can be applied at the certificate level.

Specifically, you can:

• Implement explicit block rules for the compromised certificate thumbprints
  
• Prevent execution of any binaries signed with those certificates, regardless of publisher trust

This approach is particularly useful in environments where publisher-based allow rules are already in place, as it provides a targeted way to block known compromised certificates without broadly impacting legitimate software.

An Airlock Digital walkthrough video is included below demonstrating how to:

• • Identify affected certificate thumbprints
  • Create and deploy blocklisting rules
  • Validate that the policy is correctly enforced

Conclusion

DigiCert’s compromise shows how attackers can abuse legitimate certificate workflows to produce signed malware that appears more trustworthy than an unsigned binary. Microsoft Defender’s false positive shows the other side of the same trust problem: defensive controls can also make incorrect trust decisions, in this case by flagging legitimate DigiCert root certificates.

Both outcomes matter for defenders because it demonstrates how many trust decisions are made before an organization gets to make its own. Certificate Authorities decide who can sign code. Operating systems decide which roots are trusted. Reputation services and endpoint security tools decide what appears safe or suspicious. These decisions are important, but they are not the same as an organization deciding what should be allowed to execute in its own environment.

Application control gives organizations a way to bring the final execution decision back under local policy. In a default-deny model, a valid signature is not enough; trust must be explicitly granted. This reduces exposure when legitimate certificates are misused and limits the impact of broader certificate-trust failures.

Security is ultimately about constraint: when defenders define what is trusted within their environments, attackers are forced to operate within those same boundaries. A compromised certificate may make malware appear legitimate to operating systems, security tools, and users, but as supply chain attacks become more common, “looks good” should not be the same as “allowed to run.”