The Trust That Broke: DigiCert CA Compromised via Social Engineering, 27 Malware-Signed Certificates Issued

TL;DR

DigiCert's internal support portal was breached on April 2 via social engineering and a malicious screensaver file, allowing attackers to issue 27 fraudulent EV Code Signing certificates that were used to sign the Zhong Stealer malware family. The incident exposes how support portal access—even with limited capabilities—can become the key to the kingdom when combined with credential theft and internal tool access.

What Happened

On April 2, 2026, a threat actor targeted DigiCert's support team by impersonating a customer in the support chat. The attacker delivered a malicious ZIP file disguised as a customer screenshot containing a .scr file (Windows screensaver format)—a trusted file extension that bypassed initial defenses.

The malicious payload infected two DigiCert endpoints:

• ENDPOINT1: Identified and contained within 24 hours on April 3 (CrowdStrike prevention setting was below organizational standard, allowing execution)
• ENDPOINT2: Remained undetected for nearly two weeks until April 14 (CrowdStrike sensor was absent or non-reporting)

From the compromised systems, the attacker pivoted to DigiCert's internal customer support portal. Using a limited proxy function designed to allow support analysts to troubleshoot customer accounts, the attacker accessed initialization codes for pending EV Code Signing certificate orders.

The Critical Chain: An initialization code + an approved certificate order = a valid EV Code Signing certificate. The attacker exploited this dependency to generate legitimate certificates across multiple customer accounts.

DigiCert revoked 60 code signing certificates by April 17, including:

• 27 certificates explicitly linked to the attacker's activity
• 11 confirmed used to sign Zhong Stealer malware (reported by security researchers)
• 16 identified during internal investigation
• 13 revoked as precaution due to unconfirmed customer control

Technical Details

Attack Chain

1. Social engineering via support chat → Phishing with malicious .scr file attachment

2. File execution on unpatched endpoints → Two infections with inconsistent EDR coverage

3. Lateral movement to support portal → Access to customer account proxy function

4. Initialization code exfiltration → Paired with pre-approved orders

5. Certificate issuance and signing → Zhong Stealer malware signed with legitimate trust anchor

Why This Worked

• The support proxy function has legitimate operational need but no MFA on initialization-code retrieval
• EDR coverage gaps allowed malware to run undetected for days
• EV certificate orders approved but not yet delivered provided the attack surface
• No automated detection of anomalous certificate requests from internal systems

Secondary Chaos: Microsoft Defender False Positive

Microsoft Defender mistakenly flagged legitimate DigiCert root certificates as Trojan:Win32/Cerdigent.A!dha, triggering widespread false positives. Florian Roth and others flagged the issue publicly, and Microsoft resolved it in definition version 1.449.430.0. This created brief additional chaos while defenders verified their certificate chains.

Lyrie Assessment

This incident hits at the core of what autonomous defense systems must solve: compromise of identity and trust infrastructure by human-speed attackers using social engineering.

Why CISOs reading Lyrie should care:

1. Code-signing certificates are force-multipliers. Once obtained, they sign arbitrary malware with the trust of a major CA. No exploit chain needed—just signature verification passing on every Windows box globally.

2. Support portals are identity choke points. DigiCert's support function was designed to help customers, but became the attack vector. Every SaaS platform has similar proxy/impersonation functions for legitimate support—and most have the same security gaps.

3. Social engineering + EDR gaps = credential compromise. The attacker didn't need zero-days. A phishing screensaver + inconsistent EDR coverage was sufficient to own systems with access to trust infrastructure.

4. The revocation response was reactive, not predictive. DigiCert found 27 fraudulent certificates weeks after issuance. A security researcher reported the Zhong Stealer malware family linkage. An automated system watching for anomalous certificate issuance patterns from internal tools might have caught this in hours, not days.

The Lyrie Angle: Autonomous defense systems protecting critical supply-chain infrastructure (CAs, package registries, CI/CD systems) need to detect three things:

• Compromised internal tooling access patterns (certificate requests from unusual accounts/times)
• Anomalous certificate issuance chains (especially for code-signing)
• Identity-layer pivots (support portal → internal tools → certificate issuance)

This incident is a case study in why certificate transparency, supply-chain monitoring, and anomaly detection on trust infrastructure are becoming mandatory.

Recommended Actions

Immediate (24-48 hours):

• Revoke and re-issue any code-signing certificates obtained from third-party CAs in the past 90 days
• Check Windows binary provenance using SigCheck or equivalent for all software signed with DigiCert certificates (especially security tools, EDR agents, system utilities)
• Patch or upgrade EDR/prevention tools to ensure consistent endpoint coverage—especially on systems with access to internal infrastructure

Short-term (1-2 weeks):

• Audit support portal access logs for all SaaS and infrastructure providers (especially identity, certificate, and API-key management services)
• Implement MFA on all support portal functions that retrieve credentials, codes, or keys
• Monitor for Zhong Stealer IOCs in your network (Chinese e-crime malware family associated with cryptocurrency theft)

Strategic (1-3 months):

• Deploy certificate transparency monitoring on your own code-signing certificate chains
• Implement real-time anomaly detection on certificate issuance and code-signing activities
• Review support portal authorization models—segment proxy/impersonation functions behind additional authentication barriers

Sources

1. https://www.helpnetsecurity.com/2026/05/04/digicert-breach-code-signing-certificates-malware/

2. https://www.securityweek.com/digicert-revokes-certificates-after-support-portal-hack/

3. https://bugzilla.mozilla.org/show_bug.cgi?id=2033170 (DigiCert official incident report)

Lyrie.ai Cyber Research Division