![\"Microsoft\"](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2026\/05\/microsoft-red-header.jpg\")
<\/p>\n<\/p>\n
Microsoft Defender is detecting legitimate DigiCert root certificates as Trojan:Win32\/Cerdigent.A!dha, resulting in widespread false-positive alerts, and in some cases,\u00a0removing\u00a0certificates from Windows.<\/p>\n
According to cybersecurity expert Florian Roth<\/a>, the issue first appeared after Microsoft added the detections<\/a> to a Defender signature update on April 30th.<\/p>\n Today, administrators worldwide began reporting<\/a> that DigiCert root certificate entries were flagged as malware and, on affected systems, removed from the Windows trust store.<\/p>\n According to a Reddit post<\/a> about the false positives, the detected certificates are:<\/p>\n 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43
On impacted systems, these certificates were removed from the AuthRoot store under this Registry key:<\/p>\n
These false positives have led to concern among Windows users, with some thinking their devices were infected and reinstalling the operating system to be safe.<\/p>\n Microsoft has reportedly fixed the detections in Security Intelligence update version 1.449.430.0, and the most recent update is now 1.449.431.0.<\/p>\n Other reports on Reddit<\/a> indicate that the fix also restores previously removed certificates on affected systems.<\/p>\n The new Microsoft Defender updates will automatically install, and Windows users can manually\u00a0force an update by going into Windows Security > Virus and threat protection > Protection updates and clicking on Check for Updates.<\/p>\n Possibly linked to a recent DigiCert breach<\/p>\n The false positives occur shortly after a disclosed DigiCert security incident<\/a> that enabled threat actors to obtain valid code-signing certificates used to sign malware.<\/p>\n “A malware incident targeted a customer support team member. Upon detection, the threat vector was contained,” explains the DigiCert incident report.<\/p>\n “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.”<\/p>\n “The identified certificates were revoked within 24 hours of discovery and the revocation date set to their date of issuance. As a precautionary measure, pending orders within the window of interest were cancelled. Additional details will be provided in our full incident report.”<\/p>\n According to DigiCert’s incident report, attackers targeted the company’s support staff in early April by creating support messages containing a malicious ZIP file disguised as a screenshot.<\/p>\n After multiple blocked attempts, one support analyst’s device was eventually compromised, followed by a second system that went undetected for a time due to an endpoint protection “sensor gap.”<\/p>\n Using access to the breached support environment, the hacker used a feature in DigiCert’s internal support portal that allowed support staff to\u00a0view customer accounts from the customer’s perspective.<\/p>\n While limited in scope, this access exposed “initialization codes”\u00a0to previously approved, but undelivered, EV code-signing certificate orders.<\/p>\n “Possession of an initialization code, combined with an approved order, is sufficient to obtain the resulting certificate (see Contributing Factors discussion below),” explained DigiCert.<\/p>\n “Since the threat actor was able to obtain these two pieces of information for a finite set of approved orders, they were able to obtain EV Code Signing certificates across a set of customer accounts and CAs.”<\/p>\n DigiCert says it revoked 60 code-signing certificates, including 27 linked to a “Zhong Stealer” malware campaign.<\/p>\n “11 were identified in certificate problem reports provided to DigiCert by community members linking the certificates to malware, and 16 were identified during our own investigation,” explained DigiCert.<\/p>\n Zhong Stealer malware campaign<\/p>\n This aligns with earlier reports from security researchers who had observed newly issued DigiCert EV certificates used in malware campaigns and reported them to DigiCert.<\/p>\n Researchers, including Squiblydoo<\/a>, MalwareHunterTeam<\/a>, and g0njxa<\/a>, reported that certificates issued to well-known companies such as Lenovo, Kingston, Shuttle Inc, and Palit Microsystems were being used to sign malware.<\/p>\n “What do Lenovo, Kingston, Shuttle Inc, and Palit Microsystems have in common?,” posted\u00a0Squiblydoo on X<\/a>.<\/p>\n “EV Certificates from these companies were issued and used by a Chinese crime group, #GoldenEyeDog (#APT-Q-27)!”<\/p>\n The malware in this campaign is named “Zhong Stealer,”\u00a0though analysis indicates it may be more like a remote access trojan (RAT) than an infostealer.<\/p>\n The researcher says the malware was distributed through the following attacks:<\/p>\n Phishing emails deliver a fake image or screenshot
After DigiCert disclosed the incident, the researchers said the incident report explains how the certificates used in these malware campaigns were obtained.<\/p>\n While Microsoft has not confirmed that the Defender detections are a result of the DigiCert incident, the timing and focus on DigiCert-related certificates suggest a possible connection.<\/p>\n However, it should be noted that 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 malware.<\/p>\n BleepingComputer contacted Microsoft with questions about the campaign, including whether it was tied to DigiCert’s breach.<\/p>\n
\n\tDDFB16CD4931C973A2037D3FC83A4D7D775D05E4
<\/p>\n
\nHKLM\\SOFTWARE\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\<\/p>\n![\"Microsoft](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2026\/05\/cerdigent-false-positive.jpg\")
Microsoft Defender “Trojan:Win32\/Cerdigent.A!dha” False Positive
Source: Reddit<\/a><\/p>\n
\n\tA first-stage executable that displays a decoy image
\n\tRetrieval of a second-stage payload from cloud storage such as AWS
\n\tUse of signed binaries and loaders, including components tied to legitimate vendors
<\/p>\n
![\"article](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2026\/05\/autonomous-validation2.jpg\")
<\/a><\/p>\n