Attackers Compromise DigiCert Using Malicious Screensaver to Steal EV Code Signing Certificates

0
8

Key Takeaways

  • A threat actor used a disguised .scr screensaver inside a ZIP file to trick DigiCert support analysts, gaining initial foothold on two internal endpoints.
  • A malfunctioning CrowdStrike sensor created a ten‑day blind spot, allowing the attacker unrestricted access before detection.
  • Compromised support accounts were leveraged to view customer‑side initialization codes for approved EV Code Signing orders, enabling the theft of legitimate certificates.
  • Sixty EV Code Signing certificates were revoked; 27 were directly linked to the attacker, the rest revoked as a precaution.
  • The stolen certificates signed Zhong Stealer malware, which has been associated (though not confirmed) with the Chinese e‑crime group GoldenEyeDog (APT‑Q‑27).
  • DigiCert revoked all certificates within 24 hours of discovery, tightened MFA, disabled Okta FastPass, blocked proxy‑based viewing of initialization codes, and suspended affected analyst accounts.
  • Organizations must verify that the revoked certificates are no longer trusted in CRL/OCSP streams, internal allowlists, or pinned configurations.

Initial Compromise via Malicious Screensaver
On April 2, 2026, an unknown threat actor initiated contact with DigiCert’s customer‑support team through a Salesforce‑based chat channel. The actor repeatedly sent a ZIP file that appeared to be a customer‑provided screenshot. Inside the archive lay a .scr executable—a screensaver file that Windows treats as a native program, making it a reliable social‑engineering lure. Four of the five delivery attempts were blocked by CrowdStrike and other endpoint defenses, but the fifth attempt succeeded, compromising a support analyst’s workstation labeled ENDPOINT1. DigiCert’s Trust Operations team identified and isolated the infected machine by April 3, 2026, believing the incident contained.


Detection Gaps and Delayed Discovery
Despite the swift isolation of ENDPOINT1, a critical blind spot persisted. On April 4, 2026, a second machine, ENDPOINT2, was compromised using the identical malicious ZIP‑and‑.scr technique. However, the CrowdStrike sensor on ENDPOINT2 was malfunctioning, creating a detection gap that allowed the breach to go completely unnoticed during the April 3 investigation. Consequently, the attacker maintained unrestricted access to ENDPOINT2 for ten full days. DigiCert only discovered the second compromise on April 14, 2026, after reviewing logs and noticing anomalous activity that had evaded real‑time alerts.


Exploitation of Support Portal Features
With access to the compromised analyst accounts, the threat actor logged into DigiCert’s internal customer‑support portal. The portal includes a feature that lets authenticated support staff view customer accounts from the customer’s perspective—a read‑only mode intended for troubleshooting. While this function does not permit account management, API‑key creation, or order submission, it does expose initialization codes for EV Code Signing certificates that have been approved but not yet delivered. Possession of an initialization code combined with an already‑approved order is sufficient to request and activate a valid, CA‑signed certificate, giving the attacker a direct path to legitimate credentials without needing to forge or compromise the CA’s signing infrastructure.


Acquisition of EV Code Signing Certificates
Between April 14 and April 17, 2026, DigiCert revoked sixty EV Code Signing certificates issued from four distinct Certificate Authorities: DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1, DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, GetSSL G4 CS RSA4096 SHA256 2022 CA‑1, and Verokey High Assurance Secure Code EV. Of these, twenty‑seven certificates were explicitly tied to the attacker through community‑submitted certificate problem reports, and sixteen were uncovered during DigiCert’s own forensic investigation. The remaining thirty‑three certificates were revoked as a precautionary measure because customer control could not be unequivocally confirmed. All revocations were completed within twenty‑four hours of discovery, limiting the window during which the stolen certificates could be abused.


Zhong Stealer Malware Deployment
The stolen certificates were used to digitally sign payloads delivering the Zhong Stealer malware family—a hybrid Remote Access Trojan/information‑stealer previously observed in campaigns targeting cryptocurrency wallets and exchanges. Zhong Stealer’s typical attack chain begins with phishing lures containing fake screenshots, followed by a first‑stage decoy payload that retrieves additional modules from cloud services such as AWS. The digitally signed binaries help the malware bypass endpoint detection solutions that trust signed code, thereby increasing its success rate. Researchers have noted overlaps between Zhong Stealer activity and the known Chinese e‑crime group GoldenEyeDog (APT‑Q‑27), although definitive attribution of the DigiCert breach to that group remains unconfirmed.


Attribution to GoldenEyeDog
Security analysts have linked the Zhong Stealer campaign observed after the certificate theft to GoldenEyeDog, also tracked as APT‑Q‑27, a group historically involved in financially motivated cybercrime, including crypto‑theft and credential harvesting. The timing, malware signatures, and infrastructure used (certain IP addresses and cloud storage buckets) align with prior GoldenEyeDog operations. Nevertheless, the threat actor’s exact identity and any direct affiliation with GoldenEyeDog remain uncertain; the group could have leveraged the stolen certificates independently, or a separate actor may have repurposed the certificates for their own malware distribution. Attribution in such supply‑chain compromises is inherently challenging, and DigiCert has not publicly asserted a definitive link.


Response and Mitigation Measures
Upon confirming the breach, DigiCert enacted a multi‑layered response. All sixty compromised EV Code Signing certificates were revoked within 24 hours. The company deployed code changes that blocked proxied support users from viewing Code Signing initialization codes at both the UI and API layers, effectively closing the exploitation vector. Okta FastPass was disabled for support‑portal access, and multi‑factor authentication requirements were tightened across all privileged accounts. The analyst accounts involved in the incident were suspended pending further review, and any pending Code Signing orders were canceled to eliminate residual risk. Additionally, DigiCert identified seven IP addresses used by the attacker during certificate installation and shared them as indicators of compromise.


Indicators of Compromise
Key IOCs associated with the incident include the malicious file type (.scr inside a ZIP archive), the Zhong Stealer malware family (classified as a RAT/Stealer hybrid), and the following attacker IP addresses (defanged for safety): 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. Organizations should verify that the sixty revoked certificates are no longer trusted in their CRL/OCSP streams, internal allowlists, or pinned certificate configurations. Additionally, monitoring for execution of unsigned or unusually signed binaries that attempt to contact the listed IPs or download payloads from AWS S3 buckets can aid in early detection of similar abuse.


Recommendations for Organizations
To defend against analogous supply‑chain attacks, organizations should:

  1. Enforce strict email and web‑gateway controls that block executable file types (including .scr) within archives, regardless of sender reputation.
  2. Deploy endpoint detection and response (EDR) solutions with sensor health monitoring to quickly identify disabled or malfunctioning agents.
  3. Implement least‑privilege access models for support portals, ensuring that read‑only views cannot expose sensitive data such as initialization codes.
  4. Strengthen MFA and consider phishing‑resistant authenticators for all privileged accounts.
  5. Regularly audit and rotate code‑signing keys and certificates, maintaining an up‑to‑date inventory and automated revocation checks.
  6. Share threat intelligence via trusted platforms (MISP, VirusTotal, SIEMs) to rapidly propagate IOCs like the identified IP addresses.
  7. Conduct periodic tabletop exercises focused on social‑engineering and supply‑chain scenarios to improve detection and response timelines.

Conclusion and Lessons Learned
The DigiCert incident illustrates how a seemingly innocuous social‑engineering tactic—a disguised screensaver—can cascade into a large‑scale compromise of code‑signing infrastructure when detection gaps and excessive privilege coexist. The ten‑day window during which ENDPOINT2 remained undetected underscores the necessity of continuous sensor health validation and proactive threat hunting. By swiftly revoking certificates, tightening access controls, and sharing IOCs, DigiCert limited the damage, but the episode serves as a reminder for all entities that rely on code signing: vigilance, defense‑in‑depth, and rapid incident response are essential to protect the trust that signed software conveys to end users.

SignUpSignUp form

LEAVE A REPLY

Please enter your comment!
Please enter your name here