Microsoft Defender wrongly flags DigiCert certs as Trojan:Win32/Cerdigent.A!dha

Source: Bleeping Computer

Background

• Discovery – Cybersecurity researcher Florian Roth noted that the issue appeared after Microsoft added the detection to a Defender signature update on 30 April 2024.
• Reports – Administrators worldwide began posting about the problem on Reddit:
  • r/cybersecurity – “MDE flagging DigiCert certificate as malicious”

Affected Certificates

The following DigiCert root certificates were identified as malicious:

• 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43
• DDFB16CD4931C973A2037D3FC83A4D7D775D05E4

These certificates were removed from the AuthRoot store under the registry key:

HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\

Impact

• Users saw alerts that their systems were infected.
• Some users chose to reinstall Windows to “clean” the infection.
• The false positives eroded trust in the Windows security ecosystem.

Fix

Microsoft released a fix in Security Intelligence update 1.449.430.0 (the latest version is 1.449.431.0). The update:

• Removes the erroneous detection.
• Restores any certificates that were previously deleted.

“The fix also restores previously removed certificates on affected systems.” – Reddit discussion: r/cybersecurity – Trojan:Win32/Cerdigent.A!dha

How to Apply the Update Manually

1. Open Windows Security.
2. Navigate to Virus & threat protection → Protection updates.
3. Click Check for updates.

The update will install automatically if the system is connected to the internet.

Visual Reference

Source: Reddit comment

If you continue to see alerts after applying the latest update, consider reporting the issue to Microsoft Support and verify that the affected certificates are present in the AuthRoot store.

Possible Link to a Recent DigiCert Breach

The false positives appear shortly after the disclosed DigiCert security incident, which allowed threat actors to obtain valid code‑signing certificates for signing malware.

Incident Summary

• Target: A customer‑support team member.
• Outcome: The threat vector was contained after detection.

“Our subsequent investigation found that the threat actor was able to procure initialization codes for a limited number of code‑signing certificates, few of which were then used to sign malware.” – DigiCert incident report

• Revocation: The identified certificates were revoked within 24 hours of discovery, with the revocation date set to the issuance date.
• Precautionary Measures: Pending orders within the affected window were cancelled. A full incident report will provide additional details.

Attack Timeline

1. Early April – Initial Compromise
   • Attackers sent support messages containing a malicious ZIP file disguised as a screenshot.
2. Multiple Blocked Attempts
   • After several blocked attempts, one support analyst’s device was compromised.
3. Secondary Compromise
   • A second system remained undetected for a period due to an endpoint‑protection “sensor gap.”

Exploited Feature

Using access to the breached support environment, the attacker leveraged a feature in DigiCert’s internal support portal that allowed staff to view customer accounts from the customer’s perspective. This exposure gave the attacker:

• Initialization codes for previously approved, but undelivered, EV code‑signing certificate orders.

“Possession of an initialization code, combined with an approved order, is sufficient to obtain the resulting certificate (see Contributing Factors discussion below).” – DigiCert

With both pieces of information, the threat actor obtained EV Code Signing certificates for a finite set of approved orders.

Impact

• Certificates Revoked: 60 code‑signing certificates.
• Malware Campaign: 27 certificates linked to a “Zhong Stealer” campaign.
• Detection Sources:
  • 11 certificates identified via community‑submitted certificate problem reports.
  • 16 certificates identified during DigiCert’s internal investigation.

For a complete technical analysis and the full incident report, refer to DigiCert’s official communications.

Zhong Stealer Malware Campaign

The campaign ties in with earlier reports from security researchers who observed newly‑issued DigiCert EV certificates being abused in malware operations and reported the abuse to DigiCert.

Affected Certificates

Researchers—including Squiblydoo, MalwareHunterTeam, and g0njxa—found that EV certificates issued to well‑known companies such as Lenovo, Kingston, Shuttle Inc., and Palit Microsystems were being used to sign malicious binaries.

“What do Lenovo, Kingston, Shuttle Inc., and Palit Microsystems have in common?” – Squiblydoo on X
“EV certificates from these companies were issued and used by a Chinese crime group, #GoldenEyeDog (#APT‑Q‑27)!”

Malware Overview

The malware used in the campaign is named Zhong Stealer. Although the name suggests an infostealer, analysis indicates it behaves more like a remote‑access trojan (RAT).

Distribution Chain

The researchers described the typical infection flow:

1. Phishing email – delivers a fake image or screenshot.
2. First‑stage executable – displays the decoy image to the victim.
3. Second‑stage payload – fetched from cloud storage (e.g., AWS).
4. Signed binaries & loaders – include components signed with the compromised EV certificates, often tied to legitimate vendors.

DigiCert Incident

After DigiCert disclosed the breach, the incident report detailed how the attackers obtained the certificates used in these campaigns.

• Microsoft has not officially confirmed that Defender detections stem from the DigiCert incident.
• The certificates flagged by Microsoft Defender are root certificates in the Windows trust store and do not match the revoked DigiCert code‑signing certificates used to sign the malware.

BleepingComputer reached out to Microsoft for clarification on whether the campaign is directly linked to the DigiCert breach.