DigiCert Hacked With a Screensaver File and Defender Flagged Root Certificates as Malware

Microsoft Defender deleted DigiCert root certificates from Windows machines worldwide and flagged them as Trojan:Win32/Cerdigent.A!dha. Those certificates tell your browser which websites to trust, and tell Windows which software is safe to run. DigiCert was hacked through a screensaver file in a customer support chat, Microsoft tried to respond, and Defender ended up deleting the very thing it was trying to protect.

DigiCert is a certificate authority. A certificate is what tells your browser that a website is real, and what tells Windows that software was actually built by the company whose name is on it. When you see a padlock in your browser, a certificate made that happen. When Windows decides whether to run a program without warning you, it checked a certificate. DigiCert issues more of those certificates than almost anyone else. When you log into your bank, check your email, or install software from a trusted vendor, there is a reasonable chance a DigiCert certificate was involved somewhere in that process.

On April 2, 2026, an attacker contacted DigiCert’s support team through a normal customer chat and sent a ZIP file disguised as a screenshot. Inside was a .scr file. Windows screensavers, the fish-swimming-across-your-monitor format from the 1990s. Windows runs them exactly like any other program.

The customer support chat made it even easier. According to DigiCert’s own incident report, the chat allowed anyone from outside to send files directly to staff members who had access to certificate systems. No restrictions on file type, no sandboxing, no content inspection. The .scr file did not need to be clever. The system just let it through.

This attack has a name: social engineering. The attacker did not write an exploit or find a vulnerability. They posed as a customer, sent a file, and waited for someone to open it. Social engineering has been around longer than most of the security tools built to stop it, and it still works just as well. The most sophisticated security stack in the world ends at the person sitting behind the keyboard.

CrowdStrike and other security software blocked four attempts before the fifth one got through on April 2 and compromised the first machine. DigiCert detected that themselves and contained it by April 3. What they missed was a second machine. On April 4, the attacker used the same delivery method on a second support analyst. Nobody found that second machine until April 14, because the CrowdStrike EDR agent on that machine was malfunctioning. EDR software, which stands for Endpoint Detection and Response, watches a machine for suspicious activity and sends those alerts to a central dashboard where a security team can act on them. This one was running. It just was not sending its alerts anywhere. In between, on April 5, an external researcher reported that DigiCert certificates were being used to sign malware in active campaigns. That report is what triggered the deeper investigation that uncovered the second machine.

The attacker left with initialization codes for code-signing certificates.

A code-signing certificate is the digital signature a developer puts on software to prove it came from them and has not been changed since. Windows uses that signature to decide whether to warn you before running something. If the signature checks out, SmartScreen, the part of Windows that screens unfamiliar software, stays quiet and lets it run. Extended Validation certificates, EV certificates, are the top level of that system. You jump through more hoops to get one, and the certificate lists a verified company name. Since March 2024 Microsoft changed how SmartScreen handles EV certificates, so they no longer bypass warnings automatically. But an EV certificate in the name of Lenovo or Kingston still looks very different to a user than an unknown publisher. That is the advantage the attacker was after.

The attacker used the stolen codes to generate EV certificates in the names of real companies: Lenovo, Kingston, Shuttle Inc, and Palit Microsystems. Those certificates were then used to sign Zhong Stealer.

Zhong Stealer has been around since December 2024, when it first showed up targeting people at crypto exchanges and fintech companies. The delivery method back then looked almost identical to how DigiCert got hit: attackers posed as customers, opened support tickets on platforms like Zendesk, and pushed the malware to whoever was handling the ticket. Once on a machine, the malware connects to its Alibaba Cloud server in Hong Kong and downloads a second payload called down.exe. That file disguises itself as a BitDefender Security updater, signed with a stolen certificate so it looks like a legitimate software update. From there Zhong Stealer installs itself and goes to work.

Despite the name, it works more like a remote access tool than a stealer. When it runs, it first checks which languages the system uses, so it skips machines in countries the attackers want to leave alone. It connects to a server in Hong Kong on Alibaba Cloud over port 1311, a non-standard port that most network monitoring tools ignore. It adds itself to the Windows Task Scheduler so it runs again after every reboot. It runs a keylogger alongside a clipboard monitor that records everything copied. For anyone handling crypto wallets or financial accounts, that clipboard monitor is where the real damage happens because wallet addresses and passwords move through the clipboard constantly.

Security researchers including Squiblydoo, MalwareHunterTeam, and g0njxa connected the stolen certificates to a group tracked under several names. Qi’anxin calls them APT-Q-27. Sophos calls them Dragon Breath. They also go by GoldenEyeDog. The group has been active since at least 2020, targeting online gambling platforms, gaming communities, and the overseas Chinese community. They distribute fake versions of real apps, Telegram, VPN clients, messaging software, all working normally while running malware underneath.

In cybersecurity, attribution is one of the hardest problems to get right. IP addresses can be faked. Tools get shared between groups. Code patterns overlap in ways that mislead researchers. The evidence shows certificates from this campaign signed Zhong Stealer and that the code patterns inside the malware match what researchers have seen from APT-Q-27 before. The IOCs that tie them together are specific enough to hunt for directly:

• → Mutex: Global\DHGGlobalMutex
• → Registry key (keylogger): HKCU\offlinekey\open
• → Registry key (clipboard monitor): HKCU\offlinekey\clipboard

Whether the same group attacked DigiCert’s support staff is a question nobody has answered yet.

DigiCert revoked 60 code-signing certificates between April 14 and 17. Twenty-seven were directly tied to the attacker. The other 33 were pulled as a precaution. The IP addresses the attacker used were traced and logged: 82.23.186.8, 154.12.185.32, 45.144.227.12, 203.160.68.2, 154.12.185.30, 62.197.153.45, and 45.144.227.29. DigiCert’s own incident report also notes that Zhong Stealer was signed with stolen certificates from other certificate authorities too, not just DigiCert. The campaign was broader than one breach.

Microsoft responded by adding a detection to Defender targeting the stolen certificates. Security Intelligence update 1.449.424.0 shipped April 30, 2026 with a signature called Trojan:Win32/Cerdigent.A!dha. The detection went looking for DigiCert-related entries in the Windows registry, the database Windows uses to store system settings, specifically in the section where trusted certificates live:

HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

It matched the wrong certificates.

A code-signing certificate belongs to one company and signs one piece of software. A root certificate belongs to the certificate authority itself and is the foundation the whole system builds on. When a browser checks whether a website certificate is real, it follows a chain all the way back to a root certificate. Root certificates come pre-installed on every operating system because everything else depends on them being there. The two certificates Defender flagged were DigiCert Assured ID Root CA and DigiCert Trusted Root G4, both sitting in the Windows trust store for years with thumbprints matching exactly what DigiCert publishes on their own website:

• → DigiCert Assured ID Root CA: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43
• → DigiCert Trusted Root G4: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4

Neither had anything to do with the stolen code-signing certificates or Zhong Stealer. Defender removed them anyway.

Without those root certificates, browsers throw errors on sites that use DigiCert-backed certificates, applications that verify software signatures stop working, and corporate systems that use certificate-based logins break. On May 3, 2026, reports started flooding in from admins across Windows 11 and Windows Server environments. Some people, looking at a high-severity Trojan alert marked as remediated, assumed they were infected and reinstalled Windows completely.

To check whether a machine was affected:

1

certutil -store AuthRoot | findstr -i "digicert"

If DigiCert Assured ID Root CA and DigiCert Trusted Root G4 show up in the output, the certificates are there. If they do not, the machine was hit.

The fix is updating Defender definitions to Security Intelligence version 1.449.430.0 or later. That version stops the false detection and automatically restores any certificates that were removed. For admins managing larger environments, this Advanced Hunting query checks whether certificates have been restored across managed devices:

1
2
3
4
5

DeviceRegistryEvents
| where ActionType == "RegistryKeyCreated"
| where Timestamp > datetime(2026-05-03T04:00:00)
| project Timestamp, DeviceName, ActionType, InitiatingProcessFileName
| order by Timestamp desc

What this whole chain shows is how far one misconfigured EDR agent and one unfiltered support chat can take an attacker. The entry point was a file people associate with fish swimming across a monitor. The stolen certificates signed malware that had already been running since late 2024. And when Microsoft moved to stop the damage, the fix deleted the very certificates it was trying to protect. Ask yourself what else is sitting undetected right now in places that should have caught it months ago.

Social engineering, credential theft with tools like Mimikatz, and persistence techniques like scheduled tasks and registry keys are all covered step by step in the ethical hacking course:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Sources: DigiCert Incident Report · Zhong Stealer Analysis · APT-Q-27 GoldenEyeDog