2033170 - DigiCert: Misissued code signing certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[DigiCert]

Preliminary Incident Report

Summary

• Incident description: A malware incident targeted a customer support team member. Upon detection, the threat vector was contained. 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. 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.
• Relevant policies: Microsoft Trusted Root Program Policy Section 2.1.16, Mozilla Root Store Policy Section 2.4, Apple Root Certificate Program Section 3, Chrome Root Program Policy Section 15.1, CCADB Policy Section 1, CABF Code Signing Baseline Requirements Section 4.9.1.1, CABF Network and Certificate System Security Requirements (NetSec) Section 1 and 2.
• Source of incident disclosure: Third Party

Comment 1

[DigiCert]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000021

• Incident description: On 2026-04-02, a threat actor contacted DigiCert's support team via a customer chat channel and delivered a ZIP file disguised as a customer screenshot. The file contained a .scr executable with a malicious payload. CrowdStrike and other security measures successfully blocked four delivery attempts. A fifth attempt compromised ENDPOINT1, a machine used by a support analyst; this delivery attempt was detected and contained by our Trust Operations team on 2026-04-03. Following an immediate internal investigation based on the telemetry data at hand, it was assessed that the incident had been contained.

  DigiCert received the initial third party report related to this incident on 2026-04-05. Additional third party reports are identified in the timeline.

  DigiCert regularly receives certificate problem reports from community members and security researchers for Code Signing certificates, and proven key compromise cases are revoked pursuant to the Code Signing Baseline Requirements. Initial problem reports ultimately linked to this incident report fit within the normal pattern of such revocations.

  On 2026-04-14, further investigation identified that ENDPOINT2, a machine used by another analyst was compromised through the same delivery vector on 2026-04-04. A malfunctioning CrowdStrike implementation on that endpoint meant that the compromise was not detected during the earlier 2026-04-03 investigation.

  Our Trust Operations investigation found that the threat actor used the compromised analyst endpoint to access DigiCert's internal support portal. The threat actor used a limited function within the customer-support portal which allows authenticated DigiCert support analysts to access customer accounts from the customer's perspective to facilitate support tasks. This access is restricted and does not permit actions such as managing accounts, users, API-keys, or submitting or managing orders. However, the threat actor was able to use this function to access initialization codes for orders that were approved but pending delivery for EV Code Signing certificate orders across a finite set of customer accounts.

  Possession of an initialization code, combined with an approved order, is sufficient to obtain the resulting certificate (see Contributing Factors discussion below). 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.

  During our investigation between 2026-04-14 and 2026-04-17, as DigiCert identified certificates potentially affected by the threat actor's actions, we revoked them. DigiCert revoked 60 certificates issued from the following CAs:

  • DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1
  • DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
  • GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1
  • Verokey High Assurance Secure Code EV

  27 of the revoked certificates were explicitly linked to the threat actor (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).

  Our investigation included review of the threat actor's activity in the support system as well as tracing delivery to IP addresses known to have been used by the threat actor. The IP addresses used by the bad actor to install the certificates included: 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.

  In addition to the 27 identified above, 33 of the 60 total certificates were revoked during our own investigation as a precautionary measure. For these certificates, we could not explicitly confirm customer control. In addition, pending orders were cancelled, closing access to the threat actor. All identified certificates were revoked within 24 hours of discovery, with the revocation date set to their date of issuance.

  The exploited certificates identified by the community member were found to have been used to sign the "Zhong Stealer" malware family.

  Our Trust Operations team conducted a detailed review of activity from the compromised endpoints and associated user accounts. This review did not identify related activity within other user accounts. The investigations did not find any misuse of validation information, improper validation actions or other steps that could lead to account settings changes, nor non-Code Signing certificate mis-issuance. In our investigation, we did not find evidence that the threat actor misused other internal systems other than the Code Signing initialization codes within specific accounts.

  As a result of this incident, additional network and application security changes and reviews, described in the action items, have been undertaken or are underway.

• Timeline summary:

  • Non-compliance start date: 2026-04-04, ENDPOINT2
  • Non-compliance identified date: 2026-04-14
  • Non-compliance end date: 2026-04-17, last revocation date

• Relevant policies: Microsoft Trusted Root Program Policy v1.1, Section 2.1.16; Mozilla Root Store Policy v3, Section 2.4; Apple Root Certificate Program Section 3; Chrome Root Program Policy v1.8, Section 15.1; CCADB Policy v2, Section 1; CABF Code Signing Baseline Requirements v.3.10.0, Section 4.9.1.1, CABF Network and Certificate System Security Requirements (NetSec) v2.0.5, Sections 1, 2, and 3. Also relevant: Mozilla CA/Vulnerability Disclosure wiki.

• Source of incident disclosure: Third Party Reported

Impact

• Total number of certificates: 60 revoked Code Signing certificates of which 27 were explicitly linked to the threat actor
• Total number of "remaining valid" certificates: None
• Affected certificate types: 2.23.140.1.3
• Incident heuristic: Because the incident involves features of DigiCert's internal support portal rather than a systematic encoding or validation error, the affected corpus cannot be identified by inspecting certificate content alone. The full list of affected certificates is disclosed in the Appendix.
• Was issuance stopped in response to this incident, and why or why not?: No, because the actions of the threat actor could be traced and the exposed population of certificate orders was known. As a precaution, pending Code Signing orders were cancelled, and initialization codes were masked from all proxied support sessions both via the portal and API.
• Analysis: All impacted certificates were revoked within 24 hours of identification.
• Additional considerations: There is also observed use of compromised certificates from different CAs to sign the "Zhong Stealer" malware family.

Timeline

All times are UTC unless otherwise noted. Times marked '~' are approximate based on available log data.

Date / Time (UTC)	Event
2026-02-14	Migrated Salesforce legacy chat to Salesforce enhanced chat.
2026-04-02 ~20:15-21:54	Threat actor engages user on ENDPOINT1 via support chat, repeatedly sending malicious ZIP file attachments presented as customer screenshots.
2026-04-02 ~23:45	ENDPOINT1 opens malicious file. Initial execution of k3.exe and related binaries from AppData and Public directories.
2026-04-03 ~00:00-03:47	Additional binaries execute on ENDPOINT1 (updat.exe, uuu.exe, VideoManager.exe). CrowdStrike high-severity detections fire. Trust Operations team investigation initiated.
2026-04-03 ~03:00-06:00	ENDPOINT1 isolated. Malicious processes terminated, registry Run keys removed, artifacts deleted. No remaining IOCs confirmed on that host. Investigation is considered complete at this stage; ENDPOINT2 is not considered compromised.
2026-04-03	Partial forensic triage completed on ENDPOINT1. Host goes offline. Service Desk request submitted for full wipe and reimage.
2026-04-04	CrowdStrike Windows prevention setting hardened for eradicate-on-detection configuration. Delivery vector for ENDPOINT1 confirmed: malicious ZIP auto-converted to Salesforce case attachment. Additional similar ZIPs identified across other cases and removed before opening.
2026-04-04 16:58	Determined during subsequent investigation: earliest confirmed compromise-related activity observed for ENDPOINT2; exact host execution time unknown.
2026-04-04 16:59	Determined during subsequent investigation: unauthorized access associated with ENDPOINT2 confirmed.
2026-04-05 through 2026-04-14	As a pattern emerges of certificate revocations, Support intensifies an internal review.
2026-04-05 19:56	Third party certificate problem report received for 03A4E330B16DED8C61AD0FB23ECB2E1A. Certificate revoked within 24 hours.
2026-04-7 8:22	Third party certificate problem report received for 02ED93FDB6CFB33A477E218531F32922. Certificate revoked within 24 hours.
2026-04-8 20:27	Third party certificate problem report received for 01AF6469365C81AD7222E60FB1317062. Certificate revoked within 24 hours.
2026-04-9 12:48	Third party certificate problem report received for 0CAE428F1BDCBEBAF284EEE9A643B1D8. Certificate revoked within 24 hours.
2026-04-10 10:36	Third party certificate problem report received for 0AE04FFA7B23CC3F7395B25F41255157. Certificate revoked within 24 hours.
2026-04-11 9:57	Third party certificate problem report received for 049209454DB22190C7697285C3D5AD9B. Certificate revoked within 24 hours.
2026-04-12 18:44	Third party certificate problem report received for 0AF316CB4E5D9BAF35B35E85677B17EE. Certificate revoked within 24 hours.
2026-04-14 10:30	Scope of incident changes: Support leadership engages Trust Operations team.
2026-04-14 10:40	Third party certificate problem report received for 09186DCA3667374ADBD63A2F4FD96365. Certificate revoked within 24 hours.
2026-04-14 14:19	Code change preventing proxied support users from seeing Code Signing initialization codes deployed in US: (UI layer).
2026-04-14 17:25	Users for ENDPOINT2 and ENDPOINT1 placed on administrative leave pending investigation; accounts suspended/deactivated.
2026-04-14 17:25	Compromised machine ENDPOINT2 is collected by Service Desk; hard drive is found to be encrypted. Machine is being returned to Trust Operations for analysis.
2026-04-14 ~20:35	CrowdStrike support confirms ENDPOINT2 sensor gap.
2026-04-14 21:32	Okta FastPass disabled for support portal and related applications. MFA requirements tightened for affected administrative workflows.
2026-04-15 12:16	Third party certificate problem report received for 0B416CA38FFA8579C017C0311CCD8D8A. Certificate revoked within 24 hours.
2026-04-15 14:50	Code change preventing proxied support users from seeing Code Signing initialization codes deployed in US: (API layer).
2026-04-15 16:38	Code change deployed to EU: (UI layer and API layer).
2026-04-16 10:04	Third party certificate problem report received for 0654CDA3DEFAF29DC152EF189C11E337. Certificate revoked within 24 hours.
2026-04-17 00:00	Last identified certificate revoked.

Related Incidents

Bug	Date	Description
No Bugzilla	2022-06-18	Compromised internal systems via ransomware; the incident contributed to Mozilla updating its policy requirement for breach reporting.
1801345	2022-11-18	Unauthorized access to e-Tugra admin systems.

In addition, the older 2011 "comodohacker" incidents at Comodo (now Sectigo) and GlobalSign dealt with similar circumstances.

Root Cause Analysis

Root Cause Analysis methodology used: Five Whys

Technical Background: Understanding this incident requires understanding how EV Code Signing certificates are issued on hardware tokens:

• The customer requests a Code Signing certificate from DigiCert.
• Following validation, DigiCert securely provides an initialization code to the customer.
• The customer installs DigiCert's Hardware Certificate Installer software locally.
• The customer inputs the initialization code into the installer, which generates key pairs on the hardware token and submits them to the CA.
• The CA generates the certificate against the approved order.
• The installer retrieves the resulting certificate and installs it on the token.

The process is described in a public knowledgebase at https://knowledge.digicert.com/solution/set-up-your-digicert-provided-etoken. Possession of the initialization code, combined with an approved order, is functionally sufficient to generate and retrieve the corresponding certificate. The initialization code operates as a bearer credential for the approved order and is single use. This feature made it apparent which initialization codes had been used.

Contributing Factor #1: Inconsistent or incomplete endpoint detection coverage

• Description: Security tooling (CrowdStrike) was not uniformly configured or operational across the user population exposed to the attack. The CrowdStrike prevention setting on ENDPOINT1 was below the intended organizational standard at the time of the initial compromise, allowing the malicious payload to execute before blocking engaged. The CrowdStrike sensor on ENDPOINT2 was absent, degraded, or non-reporting. As a result, no detection fired on the compromised machine.
• Timeline: The CrowdStrike sensor gap on ENDPOINT2 existed before the incident. The origin of this gap is still under investigation. The sensor gap and its consequences continued until 2026-04-14, when the expanded investigation identified it.
• Detection: The sensor gap was identified on 2026-04-14 during the expanded investigation triggered by the third-party report. There was no automated process to reconcile active user accounts, so no alert was generated when the sensor became absent or degraded. The original investigation on 2026-04-04 did not include a check of EDR enrollment status for all exposed users.
• Interaction with other factors: Without the EDR gap, the connection on ENDPOINT2 would likely have been detected and contained in the same timeframe as the other targeted machine (ENDPOINT1). This created the window during which the threat actor was able to access the portal function (CF #2) and harvest initialization codes (CF #3).

Contributing Factor #2: Insufficient privilege minimization in the support portal function

• Description: DigiCert's internal support portal includes a function that allows authenticated support analysts to proxy into specific customer accounts, to facilitate customer support. In this mode, certain functions are masked from the analyst. However, access to initialization codes for pending Code Signing certificate orders was not among the masked data elements, leaving those codes accessible to support analyst operating in a proxied session.

  The portal function had not been formally classified within DigiCert's privileged access management (PAM) framework. The definition of 'privileged access' was primarily scoped to direct access to CA and did not encompass this indirect account management function that had a path to certificate issuance. As a result, the portal function was not subject to the PAM controls applicable to privileged users under the CABF NetSec, including formal threat modeling against misuse scenarios, least-privilege design review, and access recertification.

• Timeline: The portal function is a longstanding feature. On 2026-04-14 and 2026-04-15, following discovery of the incident, we deployed a code change to mask initialization codes from proxied users on both our US and EU platforms using either the UI or API.

• Detection: The absence of initialization code masking was identified during the investigation triggered by the third-party report on 2026-04-14.

• Interaction with other factors: This factor defines the scope of the damage enabled by CF #1. Without the EDR gap, the dwell time would have been minimal and the number of initialization codes accessible would have been limited. This factor also interacts with CF #3 as the absence of masking is a direct consequence of the codes not being recognized as requiring credential-tier protection.

Contributing Factor #3: Initialization codes not protected as bearer credentials

• Description: The EV Code Signing certificate pickup workflow was designed with a threat model that assumed initialization codes would only be accessible to the validated subscriber, delivered via a secure channel, and entered by the subscriber into their local Hardware Certificate Installer. The threat model did not account for the scenario in which initialization codes stored within DigiCert's internal support portal could be viewed by a compromised DigiCert analyst account operating through the portal function. Therefore, initialization codes were classified as intermediate workflow data rather than bearer credentials.
• Timeline: The initialization code workflow was designed at the time the EV Code Signing token issuance process was developed.
• Detection: The issue was identified during the investigation triggered by the third-party report on 2026-04-14. It was not identified through any previous design review prior to this incident.
• Interaction with other factors: This factor made CF #2 possible.

Contributing Factor #4: Overly permissive file transfer capability in customer-facing support channels

• Description: DigiCert's customer support chat channel and Salesforce case attachment workflow permitted delivery of inbound file attachments from external parties, including the general public, to CA support staff with insufficient restrictions on file type, automated sandboxing, or content inspection. This created a direct delivery path for malicious executable content to personnel with privileged access. The support chat channel had not been adequately evaluated as a potential attack surface for malware delivery against CA staff.
• Timeline: The support chat channel and Salesforce case attachment integration were operational prior to this incident. The delivery vector was confirmed on 2026-04-04/05, at which point additional malicious ZIPs were identified across other Salesforce cases and removed. Corrective controls (file type restrictions, sandboxing evaluation) are in progress as described in the Action Items.
• Detection: The number of channels by which customers can reach support staff has grown. The file controls on the chat channel were believed to be sufficient prior to this incident.
• Interaction with other factors: This factor is the initial attack vector that enabled all subsequent factors to come into play.

Lessons Learned

• What went well:

  • Rapid initial containment of endpoint machines where EDR was working as intended. For these machines, DigiCert's Trust Operations team completed containment, process termination, registry cleanup, and artifact deletion within hours of detection (2026-04-03).
  • Proactive identification of the full delivery chain. The investigation identified the Salesforce case attachment auto-conversion mechanism as the delivery path and located additional malicious ZIP files across other cases before they could be opened, preventing further compromises from the same campaign.
  • Same-day remediation of contributing vulnerabilities during incident response. Critical fixes were implemented without deferral: CrowdStrike prevention settings corrected on 2026-04-04; Okta FastPass disabled and MFA tightened on 2026-04-14; initialization code masking deployed across US and EU environments on 2026-04-14/15.
  • Confident attribution of the second compromise through forensic analysis. Linking the compromised machines' activity logs to the same threat actor required analysis across identity events, endpoint telemetry, and support workflow artifacts.
  • Revocations were completed within required timelines.

• What didn't go well:

  • File-type controls were insufficient on customer-facing support channels.
  • Inconsistent and incomplete EDR coverage enabled a blind spot that was unknown prior to the incident and that directly enabled the attacker's dwell time.
  • Initialization codes were not protected as bearer credentials. The portal function exposed initialization codes that are functionally equivalent to the certificates they enable, because they were classified as intermediate workflow data rather than credential material requiring masking and credential-tier protections.
  • Device-bound authentication (Okta FastPass) was used as an MFA bypass. FastPass allowed a threat actor operating on a compromised device to inherit the device's authenticated session and satisfy MFA requirements without a genuine second factor, enabling access to the portal initialization codes after the initial endpoint compromise.
  • Following containment of ENDPOINT1 on 2026-04-03, the investigation concluded that compromise attempts had been neutralized without validating all endpoints exposed through the same delivery vector.

• Where we got lucky:

  • A community member involved in security research reported the evolving pattern of misused certificates and engaged in dialogue with our support team. Without that report, the undetected compromise of ENDPOINT2 and the associated mis-issuance might have remained undiscovered for a longer period.
  • Our investigation indicates that the threat actor's activity was focused on gaining access to Code Signing certificates. A differently-motivated threat actor might have attempted to use the compromised account for broader actions. Several of our action items are designed to address this risk.

• Additional:

  • This incident demonstrates that internal support tooling with indirect paths to certificate issuance must be subject to the same security scrutiny as CA infrastructure. Tools that were designed for legitimate operational purposes can become high-value attack targets.
  • The incident also illustrates the importance of defining 'privileged access' broadly enough to encompass any system or function with a path to certificate issuance, not just those with direct access to HSMs or signing infrastructure.
  • The dwell time underscores the importance of comprehensive post-incident investigation scope and continuous EDR coverage monitoring. A single missed endpoint can negate the value of rapid containment elsewhere.

Action Items

The following action items address the contributing factors and lessons learned identified above. Each item is mapped to the corresponding root cause/s.

Action Item	Kind	Root Cause(s)	Evaluation Criteria	Due Date	Status
Complete wipe and reimage of ENDPOINT1; replacement laptop issued	Mitigate	CF #1	Endpoint re-enrolled in EDR with correct policy configuration	2026-04-03	Complete
Remove malicious files from Salesforce cases and associated chat records	Mitigate	CF #4	All identified malicious attachments removed; confirmed via case audit	2026-04-03	Complete
Correct Windows CrowdStrike prevention setting to eradicate-on-detection configuration	Prevent	CF #1	CrowdStrike policy confirms eradicate-on-detection applied to all Windows endpoints	2026-04-04	Complete
Disable Okta FastPass for support portal; enforce proper second-factor MFA for administrative workflows	Prevent	CF #1	FastPass disabled; phishing-resistant MFA enforced; confirmed via identity policy audit	2026-04-14	Complete
Mask initialization codes from proxied support users (UI)	Prevent	CF #2 / CF #3	Initialization codes inaccessible in proxied sessions via UI; verified by QA and production validation	2026-04-14	Complete
Mask initialization codes from proxied support users (API)	Prevent	CF #2 / CF #3	Initialization codes inaccessible in proxied sessions via API; verified by QA and production validation	2026-04-15	Complete
Detailed evaluation of capabilities of proxied support users.	Prevent	CF #2 / CF #3	Ensure that privileged access is enforced and "action items" and sensitive data are masked	2026-05-15	Ongoing
Engage CrowdStrike support on ENDPOINT2 sensor gap and differential detection outcomes	Detect	CF #1	Root cause of sensor gap documented; findings incorporated into remediation plan	2026-04-14	Complete
Collect ENDPOINT2 for hands-on sensor inspection	Detect	CF #1	Collected; being returned to US Service Desk for further investigation	2026-04-14	Complete
Review and restrict file types permitted through support chat and Salesforce case attachments	Prevent	CF #4	High-risk file types (.exe, .scr, .zip) blocked at ingestion; confirmed via attachment policy audit	2026-04-17	Complete
Evaluate and implement sandboxing or detonation controls for files delivered through support channels	Prevent	CF #4	Sandboxing/detonation deployed for inbound support attachments; integration tested	2026-08-01	Ongoing
Expand metadata logging and monitoring for support chat file delivery	Detect	CF #4	Enhanced metadata logging deployed; minimum log fields defined; confirmed via log coverage audit	2026-08-01	Ongoing
Targeted coaching for users involved; additional social engineering awareness training for staff	Prevent	CF #4	Training completed; completion rate tracked; refreshed annually	2026-04-17	Complete and Ongoing
Evaluate all CrowdStrike and zScaler policies; enforce EDR eradication globally; implement application allowlisting for high-risk roles	Prevent	CF #1	Policy review completed; eradication enforced globally; allowlisting deployed for validation and support roles	2026-05-01	Ongoing
Eliminate device-bound MFA (Okta FastPass) as a sole factor for sensitive applications; require phishing-resistant MFA	Prevent	CF #1	No device-bound MFA as sole factor for any CA-system-access application; confirmed via identity policy audit	2026-04-14	Complete
Analyze portal function access; implement JIT privileged access and dual authorization for certificate-impacting proxied operations; introduce anomaly detection on issuance workflows	Prevent	CF #2 / CF #3	JIT access and dual-auth deployed for defined certificate-impacting proxy operations; anomaly detection rule live with defined threshold	2026-10-01	Ongoing
Tune impossible travel detection and risk scoring to DigiCert's operational context; employ high-severity session hijacking alerts	Detect	CF #1	Updated risk scoring deployed; impossible travel on high-privilege accounts generates minimum High severity alert	2026-04-16	Complete
Enforce always-on zScaler Internet Access including when VPN is active; block direct internet egress; require TLS inspection for high-risk categories	Prevent	CF #4	ZIA always-on enforced with no direct egress exceptions for unapproved methods; confirmed via network policy audit	2026-04-17	Complete
Evaluate all Code Signing certificate delivery workflows to tokens	Prevent	CF #3	Improved association of certificate delivery to the account holder	2026-06-01	Ongoing
Implement automated continuous EDR/SASE coverage monitoring; enforce 100% enrollment	Detect	CF #1	Automated reconciliation in place; SOC alerted on coverage gaps	2026-06-01	Ongoing
Define device EDR posture hard-failure conditions blocking access to corporate systems	Detect	CF #1	Non-compliant devices denied access	2026-08-01	Delayed

Appendix

A CSV file with full certificate details is attached.

Comment 2

[DigiCert]

Attachment: Bugzilla_2033170_Appendix.csv

A CSV file with full certificate details is attached.

Comment 3

[DigiCert]

Full Incident Report

This is an updated version of our Full Incident Report, which completes the investigation of the incident and of ENDPOINT2. In addition, another action item has been completed.

Summary

• CA Owner CCADB unique ID: A000021

• Incident description: On 2026-04-02, a threat actor contacted DigiCert's support team via a customer chat channel and delivered a ZIP file disguised as a customer screenshot. The file contained a .scr executable with a malicious payload. CrowdStrike and other security measures successfully blocked four delivery attempts. A fifth attempt compromised ENDPOINT1, a machine used by a support analyst; this delivery attempt was detected and contained by our Trust Operations team on 2026-04-03. Following an immediate internal investigation based on the telemetry data at hand, it was assessed that the incident had been contained.

  DigiCert received the initial third party report related to this incident on 2026-04-05. Additional third party reports are identified in the timeline.

  DigiCert regularly receives certificate problem reports from community members and security researchers for Code Signing certificates, and proven key compromise cases are revoked pursuant to the Code Signing Baseline Requirements. Initial problem reports ultimately linked to this incident report fit within the normal pattern of such revocations.

  On 2026-04-14, further investigation identified that ENDPOINT2, a machine used by another analyst was compromised through the same delivery vector on 2026-04-04. CrowdStrike was not installed or configured on that endpoint, meaning the compromise was not detected during the earlier 2026-04-03 investigation. The machine was established more than 3 years ago. Because our end-user machine logs are retained for three years, we cannot determine why CrowdStrike was not installed or configured on this particular endpoint.

  Our Trust Operations investigation found that the threat actor used the compromised analyst endpoint to access DigiCert's internal support portal. The threat actor used a limited function within the customer-support portal which allows authenticated DigiCert support analysts to access customer accounts from the customer's perspective to facilitate support tasks. This access is restricted and does not permit actions such as managing accounts, users, API-keys, or submitting or managing orders. However, the threat actor was able to use this function to access initialization codes for orders that were approved but pending delivery for EV Code Signing certificate orders across a finite set of customer accounts.

  Possession of an initialization code, combined with an approved order, is sufficient to obtain the resulting certificate (see Contributing Factors discussion below). 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.

  During our investigation between 2026-04-14 and 2026-04-17, as DigiCert identified certificates potentially affected by the threat actor's actions, we revoked them. DigiCert revoked 60 certificates issued from the following CAs:

  • DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1
  • DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
  • GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1
  • Verokey High Assurance Secure Code EV

  27 of the revoked certificates were explicitly linked to the threat actor (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).

  Our investigation included review of the threat actor's activity in the support system as well as tracing delivery to IP addresses known to have been used by the threat actor. The IP addresses used by the bad actor to install the certificates included: 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.

  In addition to the 27 identified above, 33 of the 60 total certificates were revoked during our own investigation as a precautionary measure. For these certificates, we could not explicitly confirm customer control. In addition, pending orders were cancelled, closing access to the threat actor. All identified certificates were revoked within 24 hours of discovery, with the revocation date set to their date of issuance.

  The exploited certificates identified by the community member were found to have been used to sign the "Zhong Stealer" malware family.

  Our Trust Operations team conducted a detailed review of activity from the compromised endpoints and associated user accounts. This review did not identify related activity within other user accounts. The investigations did not find any misuse of validation information, improper validation actions or other steps that could lead to account settings changes, nor non-Code Signing certificate mis-issuance. In our investigation, we did not find evidence that the threat actor misused other internal systems other than the Code Signing initialization codes within specific accounts.

  As a result of this incident, additional network and application security changes and reviews, described in the action items, have been undertaken or are underway.

• Timeline summary:

  • Non-compliance start date: 2026-04-04, ENDPOINT2
  • Non-compliance identified date: 2026-04-14
  • Non-compliance end date: 2026-04-17, last revocation date

• Relevant policies: Microsoft Trusted Root Program Policy v1.1, Section 2.1.16; Mozilla Root Store Policy v3, Section 2.4; Apple Root Certificate Program Section 3; Chrome Root Program Policy v1.8, Section 15.1; CCADB Policy v2, Section 1; CABF Code Signing Baseline Requirements v.3.10.0, Section 4.9.1.1, CABF Network and Certificate System Security Requirements (NetSec) v2.0.5, Sections 1, 2, and 3. Also relevant: Mozilla CA/Vulnerability Disclosure wiki.

• Source of incident disclosure: Third Party Reported

Impact

• Total number of certificates: 60 revoked Code Signing certificates of which 27 were explicitly linked to the threat actor
• Total number of "remaining valid" certificates: None
• Affected certificate types: 2.23.140.1.3
• Incident heuristic: Because the incident involves features of DigiCert's internal support portal rather than a systematic encoding or validation error, the affected corpus cannot be identified by inspecting certificate content alone. The full list of affected certificates is disclosed in the Appendix.
• Was issuance stopped in response to this incident, and why or why not?: No, because the actions of the threat actor could be traced and the exposed population of certificate orders was known. As a precaution, pending Code Signing orders were cancelled, and initialization codes were masked from all proxied support sessions both via the portal and API.
• Analysis: All impacted certificates were revoked within 24 hours of identification.
• Additional considerations: There is also observed use of compromised certificates from different CAs to sign the "Zhong Stealer" malware family.

Timeline

All times are UTC unless otherwise noted. Times marked '~' are approximate based on available log data.

Date / Time (UTC)	Event
2026-02-14	Migrated Salesforce legacy chat to Salesforce enhanced chat.
2026-04-02 ~20:15-21:54	Threat actor engages user on ENDPOINT1 via support chat, repeatedly sending malicious ZIP file attachments presented as customer screenshots.
2026-04-02 ~23:45	ENDPOINT1 opens malicious file. Initial execution of k3.exe and related binaries from AppData and Public directories.
2026-04-03 ~00:00-03:47	Additional binaries execute on ENDPOINT1 (updat.exe, uuu.exe, VideoManager.exe). CrowdStrike high-severity detections fire. Trust Operations team investigation initiated.
2026-04-03 ~03:00-06:00	ENDPOINT1 isolated. Malicious processes terminated, registry Run keys removed, artifacts deleted. No remaining IOCs confirmed on that host. Investigation is considered complete at this stage; ENDPOINT2 is not considered compromised.
2026-04-03	Partial forensic triage completed on ENDPOINT1. Host goes offline. Service Desk request submitted for full wipe and reimage.
2026-04-04	CrowdStrike Windows prevention setting hardened for eradicate-on-detection configuration. Delivery vector for ENDPOINT1 confirmed: malicious ZIP auto-converted to Salesforce case attachment. Additional similar ZIPs identified across other cases and removed before opening.
2026-04-04 16:58	Determined during subsequent investigation: earliest confirmed compromise-related activity observed for ENDPOINT2; exact host execution time unknown.
2026-04-04 16:59	Determined during subsequent investigation: unauthorized access associated with ENDPOINT2 confirmed.
2026-04-05 through 2026-04-14	As a pattern emerges of certificate revocations, Support intensifies an internal review.
2026-04-05 19:56	Third party certificate problem report received for 03A4E330B16DED8C61AD0FB23ECB2E1A. Certificate revoked within 24 hours.
2026-04-7 8:22	Third party certificate problem report received for 02ED93FDB6CFB33A477E218531F32922. Certificate revoked within 24 hours.
2026-04-8 20:27	Third party certificate problem report received for 01AF6469365C81AD7222E60FB1317062. Certificate revoked within 24 hours.
2026-04-9 12:48	Third party certificate problem report received for 0CAE428F1BDCBEBAF284EEE9A643B1D8. Certificate revoked within 24 hours.
2026-04-10 10:36	Third party certificate problem report received for 0AE04FFA7B23CC3F7395B25F41255157. Certificate revoked within 24 hours.
2026-04-11 9:57	Third party certificate problem report received for 049209454DB22190C7697285C3D5AD9B. Certificate revoked within 24 hours.
2026-04-12 18:44	Third party certificate problem report received for 0AF316CB4E5D9BAF35B35E85677B17EE. Certificate revoked within 24 hours.
2026-04-14 10:30	Scope of incident changes: Support leadership engages Trust Operations team.
2026-04-14 10:40	Third party certificate problem report received for 09186DCA3667374ADBD63A2F4FD96365. Certificate revoked within 24 hours.
2026-04-14 14:19	Code change preventing proxied support users from seeing Code Signing initialization codes deployed in US: (UI layer).
2026-04-14 17:25	Users for ENDPOINT2 and ENDPOINT1 placed on administrative leave pending investigation; accounts suspended/deactivated.
2026-04-14 17:25	Compromised machine ENDPOINT2 is collected by Service Desk; hard drive is found to be encrypted. Machine is being returned to Trust Operations for analysis.
2026-04-14 ~20:35	CrowdStrike support confirms ENDPOINT2 sensor was not installed or not configured.
2026-04-14 21:32	Okta FastPass disabled for support portal and related applications. MFA requirements tightened for affected administrative workflows.
2026-04-15 12:16	Third party certificate problem report received for 0B416CA38FFA8579C017C0311CCD8D8A. Certificate revoked within 24 hours.
2026-04-15 14:50	Code change preventing proxied support users from seeing Code Signing initialization codes deployed in US: (API layer).
2026-04-15 16:38	Code change deployed to EU: (UI layer and API layer).
2026-04-16 10:04	Third party certificate problem report received for 0654CDA3DEFAF29DC152EF189C11E337. Certificate revoked within 24 hours.
2026-04-17 00:00	Last identified certificate revoked.

Related Incidents

Bug	Date	Description
No Bugzilla	2022-06-18	Compromised internal systems via ransomware; the incident contributed to Mozilla updating its policy requirement for breach reporting.
1801345	2022-11-18	Unauthorized access to e-Tugra admin systems.

In addition, the older 2011 "comodohacker" incidents at Comodo (now Sectigo) and GlobalSign dealt with similar circumstances.

Root Cause Analysis

Root Cause Analysis methodology used: Five Whys

Technical Background: Understanding this incident requires understanding how EV Code Signing certificates are issued on hardware tokens:

• The customer requests a Code Signing certificate from DigiCert.
• Following validation, DigiCert securely provides an initialization code to the customer.
• The customer installs DigiCert's Hardware Certificate Installer software locally.
• The customer inputs the initialization code into the installer, which generates key pairs on the hardware token and submits them to the CA.
• The CA generates the certificate against the approved order.
• The installer retrieves the resulting certificate and installs it on the token.

The process is described in a public knowledgebase at https://knowledge.digicert.com/solution/set-up-your-digicert-provided-etoken. Possession of the initialization code, combined with an approved order, is functionally sufficient to generate and retrieve the corresponding certificate. The initialization code operates as a bearer credential for the approved order and is single use. This feature made it apparent which initialization codes had been used.

Contributing Factor #1: Inconsistent or incomplete endpoint detection coverage

• Description: Security tooling (CrowdStrike) was not uniformly configured or installed by DigiCert across the user population exposed to the attack. The CrowdStrike prevention setting on ENDPOINT1 was below the intended organizational standard at the time of the initial compromise, allowing the malicious payload to execute before blocking engaged. The CrowdStrike sensor on ENDPOINT2 was not installed or configured. As a result, no detection fired on the compromised machine. Logs for end-entity machines are retained for three years. Since this machine was set up more than three years ago, our security team could not determine why this particular machine either did not have an installed or configured CrowdStrike sensor.
• Timeline: The CrowdStrike sensor was not installed or configured on ENDPOINT2 before the incident.
• Detection: The sensor not being installed or configured was identified on 2026-04-14 during the expanded investigation triggered by the third-party report. There was no automated process to reconcile active user accounts, so no alert was generated when the sensor was not installed or configured. The original investigation on 2026-04-04 did not include a check of EDR enrollment status for all exposed users.
• Interaction with other factors: Without the EDR gap, the connection on ENDPOINT2 would likely have been detected and contained in the same timeframe as the other targeted machine (ENDPOINT1). This created the window during which the threat actor was able to access the portal function (CF #2) and harvest initialization codes (CF #3).

Contributing Factor #2: Insufficient privilege minimization in the support portal function

• Description: DigiCert's internal support portal includes a function that allows authenticated support analysts to proxy into specific customer accounts, to facilitate customer support. In this mode, certain functions are masked from the analyst. However, access to initialization codes for pending Code Signing certificate orders was not among the masked data elements, leaving those codes accessible to support analyst operating in a proxied session.

  The portal function had not been formally classified within DigiCert's privileged access management (PAM) framework. The definition of 'privileged access' was primarily scoped to direct access to CA and did not encompass this indirect account management function that had a path to certificate issuance. As a result, the portal function was not subject to the PAM controls applicable to privileged users under the CABF NetSec, including formal threat modeling against misuse scenarios, least-privilege design review, and access recertification.

• Timeline: The portal function is a longstanding feature. On 2026-04-14 and 2026-04-15, following discovery of the incident, we deployed a code change to mask initialization codes from proxied users on both our US and EU platforms using either the UI or API.

• Detection: The absence of initialization code masking was identified during the investigation triggered by the third-party report on 2026-04-14.

• Interaction with other factors: This factor defines the scope of the damage enabled by CF #1. Without the EDR gap, the dwell time would have been minimal and the number of initialization codes accessible would have been limited. This factor also interacts with CF #3 as the absence of masking is a direct consequence of the codes not being recognized as requiring credential-tier protection.

Contributing Factor #3: Initialization codes not protected as bearer credentials

• Description: The EV Code Signing certificate pickup workflow was designed with a threat model that assumed initialization codes would only be accessible to the validated subscriber, delivered via a secure channel, and entered by the subscriber into their local Hardware Certificate Installer. The threat model did not account for the scenario in which initialization codes stored within DigiCert's internal support portal could be viewed by a compromised DigiCert analyst account operating through the portal function. Therefore, initialization codes were classified as intermediate workflow data rather than bearer credentials.
• Timeline: The initialization code workflow was designed at the time the EV Code Signing token issuance process was developed.
• Detection: The issue was identified during the investigation triggered by the third-party report on 2026-04-14. It was not identified through any previous design review prior to this incident.
• Interaction with other factors: This factor made CF #2 possible.

Contributing Factor #4: Overly permissive file transfer capability in customer-facing support channels

• Description: DigiCert's customer support chat channel and Salesforce case attachment workflow permitted delivery of inbound file attachments from external parties, including the general public, to CA support staff with insufficient restrictions on file type, automated sandboxing, or content inspection. This created a direct delivery path for malicious executable content to personnel with privileged access. The support chat channel had not been adequately evaluated as a potential attack surface for malware delivery against CA staff.
• Timeline: The support chat channel and Salesforce case attachment integration were operational prior to this incident. The delivery vector was confirmed on 2026-04-04/05, at which point additional malicious ZIPs were identified across other Salesforce cases and removed. Corrective controls (file type restrictions, sandboxing evaluation) are in progress as described in the Action Items.
• Detection: The number of channels by which customers can reach support staff has grown. The file controls on the chat channel were believed to be sufficient prior to this incident.
• Interaction with other factors: This factor is the initial attack vector that enabled all subsequent factors to come into play.

Lessons Learned

• What went well:

  • Rapid initial containment of endpoint machines where EDR was working as intended. For these machines, DigiCert's Trust Operations team completed containment, process termination, registry cleanup, and artifact deletion within hours of detection (2026-04-03).
  • Proactive identification of the full delivery chain. The investigation identified the Salesforce case attachment auto-conversion mechanism as the delivery path and located additional malicious ZIP files across other cases before they could be opened, preventing further compromises from the same campaign.
  • Same-day remediation of contributing vulnerabilities during incident response. Critical fixes were implemented without deferral: CrowdStrike prevention settings corrected on 2026-04-04; Okta FastPass disabled and MFA tightened on 2026-04-14; initialization code masking deployed across US and EU environments on 2026-04-14/15.
  • Confident attribution of the second compromise through forensic analysis. Linking the compromised machines' activity logs to the same threat actor required analysis across identity events, endpoint telemetry, and support workflow artifacts.
  • Revocations were completed within required timelines.

• What didn't go well:

  • File-type controls were insufficient on customer-facing support channels.
  • Inconsistent and incomplete EDR coverage enabled a blind spot that was unknown prior to the incident and that directly enabled the attacker's dwell time.
  • Initialization codes were not protected as bearer credentials. The portal function exposed initialization codes that are functionally equivalent to the certificates they enable, because they were classified as intermediate workflow data rather than credential material requiring masking and credential-tier protections.
  • Device-bound authentication (Okta FastPass) was used as an MFA bypass. FastPass allowed a threat actor operating on a compromised device to inherit the device's authenticated session and satisfy MFA requirements without a genuine second factor, enabling access to the portal initialization codes after the initial endpoint compromise.
  • Following containment of ENDPOINT1 on 2026-04-03, the investigation concluded that compromise attempts had been neutralized without validating all endpoints exposed through the same delivery vector.

• Where we got lucky:

  • A community member involved in security research reported the evolving pattern of misused certificates and engaged in dialogue with our support team. Without that report, the undetected compromise of ENDPOINT2 and the associated mis-issuance might have remained undiscovered for a longer period.
  • Our investigation indicates that the threat actor's activity was focused on gaining access to Code Signing certificates. A differently-motivated threat actor might have attempted to use the compromised account for broader actions. Several of our action items are designed to address this risk.

• Additional:

  • This incident demonstrates that internal support tooling with indirect paths to certificate issuance must be subject to the same security scrutiny as CA infrastructure. Tools that were designed for legitimate operational purposes can become high-value attack targets.
  • The incident also illustrates the importance of defining 'privileged access' broadly enough to encompass any system or function with a path to certificate issuance, not just those with direct access to HSMs or signing infrastructure.
  • The dwell time underscores the importance of comprehensive post-incident investigation scope and continuous EDR coverage monitoring. A single missed endpoint can negate the value of rapid containment elsewhere.

Action Items

The following action items address the contributing factors and lessons learned identified above. Each item is mapped to the corresponding root cause/s.

Action Item	Kind	Root Cause(s)	Evaluation Criteria	Due Date	Status
Complete wipe and reimage of ENDPOINT1; replacement laptop issued	Mitigate	CF #1	Endpoint re-enrolled in EDR with correct policy configuration	2026-04-03	Complete
Remove malicious files from Salesforce cases and associated chat records	Mitigate	CF #4	All identified malicious attachments removed; confirmed via case audit	2026-04-03	Complete
Correct Windows CrowdStrike prevention setting to eradicate-on-detection configuration	Prevent	CF #1	CrowdStrike policy confirms eradicate-on-detection applied to all Windows endpoints	2026-04-04	Complete
Disable Okta FastPass for support portal; enforce proper second-factor MFA for administrative workflows	Prevent	CF #1	FastPass disabled; phishing-resistant MFA enforced; confirmed via identity policy audit	2026-04-14	Complete
Mask initialization codes from proxied support users (UI)	Prevent	CF #2 / CF #3	Initialization codes inaccessible in proxied sessions via UI; verified by QA and production validation	2026-04-14	Complete
Mask initialization codes from proxied support users (API)	Prevent	CF #2 / CF #3	Initialization codes inaccessible in proxied sessions via API; verified by QA and production validation	2026-04-15	Complete
Detailed evaluation of capabilities of proxied support users.	Prevent	CF #2 / CF #3	Ensure that privileged access is enforced and "action items" and sensitive data are masked	2026-05-15	Ongoing
Engage CrowdStrike support on ENDPOINT2 sensor not being installed or configured and differential detection outcomes	Detect	CF #1	Root cause of sensor not being installed or configured documented; findings incorporated into remediation plan	2026-04-14	Complete
Collect ENDPOINT2 for hands-on sensor inspection	Detect	CF #1	Collected; being returned to US Service Desk for further investigation	2026-04-14	Complete
Review and restrict file types permitted through support chat and Salesforce case attachments	Prevent	CF #4	High-risk file types (.exe, .scr, .zip) blocked at ingestion; confirmed via attachment policy audit	2026-04-17	Complete
Evaluate and implement sandboxing or detonation controls for files delivered through support channels	Prevent	CF #4	Sandboxing/detonation deployed for inbound support attachments; integration tested	2026-08-01	Ongoing
Expand metadata logging and monitoring for support chat file delivery	Detect	CF #4	Enhanced metadata logging deployed; minimum log fields defined; confirmed via log coverage audit	2026-08-01	Ongoing
Targeted coaching for users involved; additional social engineering awareness training for staff	Prevent	CF #4	Training completed; completion rate tracked; refreshed annually	2026-04-17	Complete and Ongoing
Evaluate all CrowdStrike and zScaler policies; enforce EDR eradication globally; implement application allowlisting for high-risk roles	Prevent	CF #1	Policy review completed; eradication enforced globally; allowlisting deployed for validation and support roles	2026-05-01	Complete
Eliminate device-bound MFA (Okta FastPass) as a sole factor for sensitive applications; require phishing-resistant MFA	Prevent	CF #1	No device-bound MFA as sole factor for any CA-system-access application; confirmed via identity policy audit	2026-04-14	Complete
Analyze portal function access; implement JIT privileged access and dual authorization for certificate-impacting proxied operations; introduce anomaly detection on issuance workflows	Prevent	CF #2 / CF #3	JIT access and dual-auth deployed for defined certificate-impacting proxy operations; anomaly detection rule live with defined threshold	2026-10-01	Ongoing
Tune impossible travel detection and risk scoring to DigiCert's operational context; employ high-severity session hijacking alerts	Detect	CF #1	Updated risk scoring deployed; impossible travel on high-privilege accounts generates minimum High severity alert	2026-04-16	Complete
Enforce always-on zScaler Internet Access including when VPN is active; block direct internet egress; require TLS inspection for high-risk categories	Prevent	CF #4	ZIA always-on enforced with no direct egress exceptions for unapproved methods; confirmed via network policy audit	2026-04-17	Complete
Evaluate all Code Signing certificate delivery workflows to tokens	Prevent	CF #3	Improved association of certificate delivery to the account holder	2026-06-01	Ongoing
Implement automated continuous EDR/SASE coverage monitoring; enforce 100% enrollment	Detect	CF #1	Automated reconciliation in place; SOC alerted on coverage gaps	2026-06-01	Ongoing
Define device EDR posture hard-failure conditions blocking access to corporate systems	Detect	CF #1	Non-compliant devices denied access	2026-08-01	Delayed

Appendix

A CSV file with full certificate details is attached.

Comment 4

[DigiCert]

Full Incident Report

This is an updated version of our Full Incident Report, which completes the investigation of ENDPOINT2.

Summary

• CA Owner CCADB unique ID: A000021
• Incident description: On 2026-04-02, a threat actor contacted DigiCert's support team via a customer chat channel and delivered a ZIP file disguised as a customer screenshot. The file contained a .scr executable with a malicious payload. CrowdStrike and other security measures successfully blocked four delivery attempts. A fifth attempt compromised ENDPOINT1, a machine used by a support analyst; this delivery attempt was detected and contained by our Trust Operations team on 2026-04-03. Following an immediate internal investigation based on the telemetry data at hand, it was assessed that the incident had been contained.

DigiCert received the initial third party report related to this incident on 2026-04-05. Additional third party reports are identified in the timeline.

DigiCert regularly receives certificate problem reports from community members and security researchers for Code Signing certificates, and proven key compromise cases are revoked pursuant to the Code Signing Baseline Requirements. Initial problem reports ultimately linked to this incident report fit within the normal pattern of such revocations.

On 2026-04-14, further investigation identified that ENDPOINT2, a machine used by another analyst was compromised through the same delivery vector on 2026-04-04. CrowdStrike was not installed on that endpoint, meaning the compromise was not detected during the earlier 2026-04-03 investigation. The machine was established more than 3 years ago. Because our end-user machine logs are retained for three years, we cannot determine why CrowdStrike was not installed on this particular endpoint.

Our Trust Operations investigation found that the threat actor used the compromised analyst endpoint to access DigiCert's internal support portal. The threat actor used a limited function within the customer-support portal which allows authenticated DigiCert support analysts to access customer accounts from the customer's perspective to facilitate support tasks. This access is restricted and does not permit actions such as managing accounts, users, API-keys, or submitting or managing orders. However, the threat actor was able to use this function to access initialization codes for orders that were approved but pending delivery for EV Code Signing certificate orders across a finite set of customer accounts.

Possession of an initialization code, combined with an approved order, is sufficient to obtain the resulting certificate (see Contributing Factors discussion below). 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.

During our investigation between 2026-04-14 and 2026-04-17, as DigiCert identified certificates potentially affected by the threat actor's actions, we revoked them. DigiCert revoked 60 certificates issued from the following CAs:

• DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1
• DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
• GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1
• Verokey High Assurance Secure Code EV

27 of the revoked certificates were explicitly linked to the threat actor (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).

Our investigation included review of the threat actor's activity in the support system as well as tracing delivery to IP addresses known to have been used by the threat actor. The IP addresses used by the bad actor to install the certificates included: 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.

In addition to the 27 identified above, 33 of the 60 total certificates were revoked during our own investigation as a precautionary measure. For these certificates, we could not explicitly confirm customer control. In addition, pending orders were cancelled, closing access to the threat actor. All identified certificates were revoked within 24 hours of discovery, with the revocation date set to their date of issuance.

The exploited certificates identified by the community member were found to have been used to sign the "Zhong Stealer" malware family.

Our Trust Operations team conducted a detailed review of activity from the compromised endpoints and associated user accounts. This review did not identify related activity within other user accounts. The investigations did not find any misuse of validation information, improper validation actions or other steps that could lead to account settings changes, nor non-Code Signing certificate mis-issuance. In our investigation, we did not find evidence that the threat actor misused other internal systems other than the Code Signing initialization codes within specific accounts.

As a result of this incident, additional network and application security changes and reviews, described in the action items, have been undertaken or are underway.

• Timeline summary:
  • Non-compliance start date: 2026-04-04, ENDPOINT2
  • Non-compliance identified date: 2026-04-14
  • Non-compliance end date: 2026-04-17, last revocation date
• Relevant policies: Microsoft Trusted Root Program Policy v1.1, Section 2.1.16; Mozilla Root Store Policy v3, Section 2.4; Apple Root Certificate Program Section 3; Chrome Root Program Policy v1.8, Section 15.1; CCADB Policy v2, Section 1; CABF Code Signing Baseline Requirements v.3.10.0, Section 4.9.1.1, CABF Network and Certificate System Security Requirements (NetSec) v2.0.5, Sections 1, 2, and 3. Also relevant: Mozilla CA/Vulnerability Disclosure wiki.
• Source of incident disclosure: Third Party Reported

Impact

• Total number of certificates: 60 revoked Code Signing certificates of which 27 were explicitly linked to the threat actor
• Total number of "remaining valid" certificates: None
• Affected certificate types: 2.23.140.1.3
• Incident heuristic: Because the incident involves features of DigiCert's internal support portal rather than a systematic encoding or validation error, the affected corpus cannot be identified by inspecting certificate content alone. The full list of affected certificates is disclosed in the Appendix.
• Was issuance stopped in response to this incident, and why or why not?: No, because the actions of the threat actor could be traced and the exposed population of certificate orders was known. As a precaution, pending Code Signing orders were cancelled, and initialization codes were masked from all proxied support sessions both via the portal and API.
• Analysis: All impacted certificates were revoked within 24 hours of identification.
• Additional considerations: There is also observed use of compromised certificates from different CAs to sign the "Zhong Stealer" malware family.

Timeline

All times are UTC unless otherwise noted. Times marked '~' are approximate based on available log data.

Date / Time (UTC)	Event
2026-02-14	Migrated Salesforce legacy chat to Salesforce enhanced chat.
2026-04-02 ~20:15-21:54	Threat actor engages user on ENDPOINT1 via support chat, repeatedly sending malicious ZIP file attachments presented as customer screenshots.
2026-04-02 ~23:45	ENDPOINT1 opens malicious file. Initial execution of k3.exe and related binaries from AppData and Public directories.
2026-04-03 ~00:00-03:47	Additional binaries execute on ENDPOINT1 (updat.exe, uuu.exe, VideoManager.exe). CrowdStrike high-severity detections fire. Trust Operations team investigation initiated.
2026-04-03 ~03:00-06:00	ENDPOINT1 isolated. Malicious processes terminated, registry Run keys removed, artifacts deleted. No remaining IOCs confirmed on that host. Investigation is considered complete at this stage; ENDPOINT2 is not considered compromised.
2026-04-03	Partial forensic triage completed on ENDPOINT1. Host goes offline. Service Desk request submitted for full wipe and reimage.
2026-04-04	CrowdStrike Windows prevention setting hardened for eradicate-on-detection configuration. Delivery vector for ENDPOINT1 confirmed: malicious ZIP auto-converted to Salesforce case attachment. Additional similar ZIPs identified across other cases and removed before opening.
2026-04-04 16:58	Determined during subsequent investigation: earliest confirmed compromise-related activity observed for ENDPOINT2; exact host execution time unknown.
2026-04-04 16:59	Determined during subsequent investigation: unauthorized access associated with ENDPOINT2 confirmed.
2026-04-05 through 2026-04-14	As a pattern emerges of certificate revocations, Support intensifies an internal review.
2026-04-05 19:56	Third party certificate problem report received for 03A4E330B16DED8C61AD0FB23ECB2E1A. Certificate revoked within 24 hours.
2026-04-7 8:22	Third party certificate problem report received for 02ED93FDB6CFB33A477E218531F32922. Certificate revoked within 24 hours.
2026-04-8 20:27	Third party certificate problem report received for 01AF6469365C81AD7222E60FB1317062. Certificate revoked within 24 hours.
2026-04-9 12:48	Third party certificate problem report received for 0CAE428F1BDCBEBAF284EEE9A643B1D8. Certificate revoked within 24 hours.
2026-04-10 10:36	Third party certificate problem report received for 0AE04FFA7B23CC3F7395B25F41255157. Certificate revoked within 24 hours.
2026-04-11 9:57	Third party certificate problem report received for 049209454DB22190C7697285C3D5AD9B. Certificate revoked within 24 hours.
2026-04-12 18:44	Third party certificate problem report received for 0AF316CB4E5D9BAF35B35E85677B17EE. Certificate revoked within 24 hours.
2026-04-14 10:30	Scope of incident changes: Support leadership engages Trust Operations team.
2026-04-14 10:40	Third party certificate problem report received for 09186DCA3667374ADBD63A2F4FD96365. Certificate revoked within 24 hours.
2026-04-14 14:19	Code change preventing proxied support users from seeing Code Signing initialization codes deployed in US: (UI layer).
2026-04-14 17:25	Users for ENDPOINT2 and ENDPOINT1 placed on administrative leave pending investigation; accounts suspended/deactivated.
2026-04-14 17:25	Compromised machine ENDPOINT2 is collected by Service Desk; hard drive is found to be encrypted. Machine is being returned to Trust Operations for analysis.
2026-04-14 ~20:35	CrowdStrike support confirms ENDPOINT2 sensor was not installed.
2026-04-14 21:32	Okta FastPass disabled for support portal and related applications. MFA requirements tightened for affected administrative workflows.
2026-04-15 12:16	Third party certificate problem report received for 0B416CA38FFA8579C017C0311CCD8D8A. Certificate revoked within 24 hours.
2026-04-15 14:50	Code change preventing proxied support users from seeing Code Signing initialization codes deployed in US: (API layer).
2026-04-15 16:38	Code change deployed to EU: (UI layer and API layer).
2026-04-16 10:04	Third party certificate problem report received for 0654CDA3DEFAF29DC152EF189C11E337. Certificate revoked within 24 hours.
2026-04-17 00:00	Last identified certificate revoked.

Related Incidents

Bug	Date	Description
No Bugzilla	2022-06-18	Compromised internal systems via ransomware; the incident contributed to Mozilla updating its policy requirement for breach reporting.
1801345	2022-11-18	Unauthorized access to e-Tugra admin systems.

In addition, the older 2011 "comodohacker" incidents at Comodo (now Sectigo) and GlobalSign dealt with similar circumstances.

Root Cause Analysis

Root Cause Analysis methodology used: Five Whys

Technical Background: Understanding this incident requires understanding how EV Code Signing certificates are issued on hardware tokens:

• The customer requests a Code Signing certificate from DigiCert.
• Following validation, DigiCert securely provides an initialization code to the customer.
• The customer installs DigiCert's Hardware Certificate Installer software locally.
• The customer inputs the initialization code into the installer, which generates key pairs on the hardware token and submits them to the CA.
• The CA generates the certificate against the approved order.
• The installer retrieves the resulting certificate and installs it on the token.

The process is described in a public knowledgebase at https://knowledge.digicert.com/solution/set-up-your-digicert-provided-etoken. Possession of the initialization code, combined with an approved order, is functionally sufficient to generate and retrieve the corresponding certificate. The initialization code operates as a bearer credential for the approved order and is single use. This feature made it apparent which initialization codes had been used.

Contributing Factor #1: Inconsistent or incomplete endpoint detection coverage

• Description: Security tooling (CrowdStrike) was not uniformly configured by DigiCert across the user population exposed to the attack. The CrowdStrike prevention setting on ENDPOINT1 was below the intended organizational standard at the time of the initial compromise, allowing the malicious payload to execute before blocking engaged. The CrowdStrike sensor on ENDPOINT2 was not installed. As a result, no detection fired on the compromised machine. Logs for end-entity machines are retained for three years. Since this machine was set up more than three years ago, our security team could not determine why this particular machine either did not have an installed CrowdStrike sensor.
• Timeline: The CrowdStrike sensor was not installed on ENDPOINT2 before the incident.
• Detection: The sensor not being installed was identified on 2026-04-14 during the expanded investigation triggered by the third-party report. The original investigation on 2026-04-04 did not include a check of EDR enrollment status for all exposed users.
• Interaction with other factors: If the sensor was installed on ENDPOINT2, the connection on ENDPOINT2 would likely have been detected and contained in the same timeframe as the other targeted machine (ENDPOINT1). This created the window during which the threat actor was able to access the portal function (CF #2) and harvest initialization codes (CF #3).

Contributing Factor #2: Insufficient privilege minimization in the support portal function

• Description: DigiCert's internal support portal includes a function that allows authenticated support analysts to proxy into specific customer accounts, to facilitate customer support. In this mode, certain functions are masked from the analyst. However, access to initialization codes for pending Code Signing certificate orders was not among the masked data elements, leaving those codes accessible to support analyst operating in a proxied session.

  The portal function had not been formally classified within DigiCert's privileged access management (PAM) framework. The definition of 'privileged access' was primarily scoped to direct access to CA and did not encompass this indirect account management function that had a path to certificate issuance. As a result, the portal function was not subject to the PAM controls applicable to privileged users under the CABF NetSec, including formal threat modeling against misuse scenarios, least-privilege design review, and access recertification.

• Timeline: The portal function is a longstanding feature. On 2026-04-14 and 2026-04-15, following discovery of the incident, we deployed a code change to mask initialization codes from proxied users on both our US and EU platforms using either the UI or API.

• Detection: The absence of initialization code masking was identified during the investigation triggered by the third-party report on 2026-04-14.

• Interaction with other factors: This factor defines the scope of the damage enabled by CF #1. Without the EDR gap, the dwell time would have been minimal and the number of initialization codes accessible would have been limited. This factor also interacts with CF #3 as the absence of masking is a direct consequence of the codes not being recognized as requiring credential-tier protection.

Contributing Factor #3: Initialization codes not protected as bearer credentials

• Description: The EV Code Signing certificate pickup workflow was designed with a threat model that assumed initialization codes would only be accessible to the validated subscriber, delivered via a secure channel, and entered by the subscriber into their local Hardware Certificate Installer. The threat model did not account for the scenario in which initialization codes stored within DigiCert's internal support portal could be viewed by a compromised DigiCert analyst account operating through the portal function. Therefore, initialization codes were classified as intermediate workflow data rather than bearer credentials.
• Timeline: The initialization code workflow was designed at the time the EV Code Signing token issuance process was developed.
• Detection: The issue was identified during the investigation triggered by the third-party report on 2026-04-14. It was not identified through any previous design review prior to this incident.
• Interaction with other factors: This factor made CF #2 possible.

Contributing Factor #4: Overly permissive file transfer capability in customer-facing support channels

• Description: DigiCert's customer support chat channel and Salesforce case attachment workflow permitted delivery of inbound file attachments from external parties, including the general public, to CA support staff with insufficient restrictions on file type, automated sandboxing, or content inspection. This created a direct delivery path for malicious executable content to personnel with privileged access. The support chat channel had not been adequately evaluated as a potential attack surface for malware delivery against CA staff.
• Timeline: The support chat channel and Salesforce case attachment integration were operational prior to this incident. The delivery vector was confirmed on 2026-04-04/05, at which point additional malicious ZIPs were identified across other Salesforce cases and removed. Corrective controls (file type restrictions, sandboxing evaluation) are in progress as described in the Action Items.
• Detection: The number of channels by which customers can reach support staff has grown. The file controls on the chat channel were believed to be sufficient prior to this incident.
• Interaction with other factors: This factor is the initial attack vector that enabled all subsequent factors to come into play.

Lessons Learned

• What went well:

  • Rapid initial containment of endpoint machines where EDR was working as intended. For these machines, DigiCert's Trust Operations team completed containment, process termination, registry cleanup, and artifact deletion within hours of detection (2026-04-03).
  • Proactive identification of the full delivery chain. The investigation identified the Salesforce case attachment auto-conversion mechanism as the delivery path and located additional malicious ZIP files across other cases before they could be opened, preventing further compromises from the same campaign.
  • Same-day remediation of contributing vulnerabilities during incident response. Critical fixes were implemented without deferral: CrowdStrike prevention settings corrected on 2026-04-04; Okta FastPass disabled and MFA tightened on 2026-04-14; initialization code masking deployed across US and EU environments on 2026-04-14/15.
  • Confident attribution of the second compromise through forensic analysis. Linking the compromised machines' activity logs to the same threat actor required analysis across identity events, endpoint telemetry, and support workflow artifacts.
  • Revocations were completed within required timelines.

• What didn't go well:

  • File-type controls were insufficient on customer-facing support channels.
  • Inconsistent and incomplete EDR coverage enabled a blind spot that was unknown prior to the incident and that directly enabled the attacker's dwell time.
  • Initialization codes were not protected as bearer credentials. The portal function exposed initialization codes that are functionally equivalent to the certificates they enable, because they were classified as intermediate workflow data rather than credential material requiring masking and credential-tier protections.
  • Device-bound authentication (Okta FastPass) was used as an MFA bypass. FastPass allowed a threat actor operating on a compromised device to inherit the device's authenticated session and satisfy MFA requirements without a genuine second factor, enabling access to the portal initialization codes after the initial endpoint compromise.
  • Following containment of ENDPOINT1 on 2026-04-03, the investigation concluded that compromise attempts had been neutralized without validating all endpoints exposed through the same delivery vector.

• Where we got lucky:

  • A community member involved in security research reported the evolving pattern of misused certificates and engaged in dialogue with our support team. Without that report, the undetected compromise of ENDPOINT2 and the associated mis-issuance might have remained undiscovered for a longer period.
  • Our investigation indicates that the threat actor's activity was focused on gaining access to Code Signing certificates. A differently-motivated threat actor might have attempted to use the compromised account for broader actions. Several of our action items are designed to address this risk.

• Additional:

  • This incident demonstrates that internal support tooling with indirect paths to certificate issuance must be subject to the same security scrutiny as CA infrastructure. Tools that were designed for legitimate operational purposes can become high-value attack targets.
  • The incident also illustrates the importance of defining 'privileged access' broadly enough to encompass any system or function with a path to certificate issuance, not just those with direct access to HSMs or signing infrastructure.
  • The dwell time underscores the importance of comprehensive post-incident investigation scope and continuous EDR coverage monitoring. A single missed endpoint can negate the value of rapid containment elsewhere.

Action Items

The following action items address the contributing factors and lessons learned identified above. Each item is mapped to the corresponding root cause/s.

Action Item	Kind	Root Cause(s)	Evaluation Criteria	Due Date	Status
Complete wipe and reimage of ENDPOINT1; replacement laptop issued	Mitigate	CF #1	Endpoint re-enrolled in EDR with correct policy configuration	2026-04-03	Complete
Remove malicious files from Salesforce cases and associated chat records	Mitigate	CF #4	All identified malicious attachments removed; confirmed via case audit	2026-04-03	Complete
Correct Windows CrowdStrike prevention setting to eradicate-on-detection configuration	Prevent	CF #1	CrowdStrike policy confirms eradicate-on-detection applied to all Windows endpoints	2026-04-04	Complete
Disable Okta FastPass for support portal; enforce proper second-factor MFA for administrative workflows	Prevent	CF #1	FastPass disabled; phishing-resistant MFA enforced; confirmed via identity policy audit	2026-04-14	Complete
Mask initialization codes from proxied support users (UI)	Prevent	CF #2 / CF #3	Initialization codes inaccessible in proxied sessions via UI; verified by QA and production validation	2026-04-14	Complete
Mask initialization codes from proxied support users (API)	Prevent	CF #2 / CF #3	Initialization codes inaccessible in proxied sessions via API; verified by QA and production validation	2026-04-15	Complete
Detailed evaluation of capabilities of proxied support users.	Prevent	CF #2 / CF #3	Ensure that privileged access is enforced and "action items" and sensitive data are masked	2026-05-15	Ongoing
Engage CrowdStrike support on ENDPOINT2 sensor not being installed and differential detection outcomes	Detect	CF #1	Root cause of sensor not being installed documented; findings incorporated into remediation plan	2026-04-14	Complete
Collect ENDPOINT2 for hands-on sensor inspection	Detect	CF #1	Collected; being returned to US Service Desk for further investigation	2026-04-14	Complete
Review and restrict file types permitted through support chat and Salesforce case attachments	Prevent	CF #4	High-risk file types (.exe, .scr, .zip) blocked at ingestion; confirmed via attachment policy audit	2026-04-17	Complete
Evaluate and implement sandboxing or detonation controls for files delivered through support channels	Prevent	CF #4	Sandboxing/detonation deployed for inbound support attachments; integration tested	2026-08-01	Ongoing
Expand metadata logging and monitoring for support chat file delivery	Detect	CF #4	Enhanced metadata logging deployed; minimum log fields defined; confirmed via log coverage audit	2026-08-01	Ongoing
Targeted coaching for users involved; additional social engineering awareness training for staff	Prevent	CF #4	Training completed; completion rate tracked; refreshed annually	2026-04-17	Complete and Ongoing
Evaluate all CrowdStrike and zScaler policies; enforce EDR eradication globally; implement application allowlisting for high-risk roles	Prevent	CF #1	Policy review completed; eradication enforced globally; allowlisting deployed for validation and support roles	2026-05-01	Complete
Eliminate device-bound MFA (Okta FastPass) as a sole factor for sensitive applications; require phishing-resistant MFA	Prevent	CF #1	No device-bound MFA as sole factor for any CA-system-access application; confirmed via identity policy audit	2026-04-14	Complete
Analyze portal function access; implement JIT privileged access and dual authorization for certificate-impacting proxied operations; introduce anomaly detection on issuance workflows	Prevent	CF #2 / CF #3	JIT access and dual-auth deployed for defined certificate-impacting proxy operations; anomaly detection rule live with defined threshold	2026-10-01	Ongoing
Tune impossible travel detection and risk scoring to DigiCert's operational context; employ high-severity session hijacking alerts	Detect	CF #1	Updated risk scoring deployed; impossible travel on high-privilege accounts generates minimum High severity alert	2026-04-16	Complete
Enforce always-on zScaler Internet Access including when VPN is active; block direct internet egress; require TLS inspection for high-risk categories	Prevent	CF #4	ZIA always-on enforced with no direct egress exceptions for unapproved methods; confirmed via network policy audit	2026-04-17	Complete
Evaluate all Code Signing certificate delivery workflows to tokens	Prevent	CF #3	Improved association of certificate delivery to the account holder	2026-06-01	Ongoing
Implement automated continuous EDR/SASE coverage monitoring; enforce 100% enrollment	Detect	CF #1	Automated reconciliation in place; SOC alerted on coverage gaps	2026-06-01	Ongoing
Define device EDR posture hard-failure conditions blocking access to corporate systems	Detect	CF #1	Non-compliant devices denied access	2026-08-01	Delayed

Appendix

A CSV file with full certificate details is attached.

Comment 5

[Wayne]

First of all, good work on the report and remediation. The transparency on missing ENDPOINT2 initially is commendable.

There are a couple of patterns that jump out to me however:

(In reply to DigiCert from comment #4)

Full Incident Report

Our investigation included review of the threat actor's activity in the support system as well as tracing delivery to IP addresses known to have been used by the threat actor. The IP addresses used by the bad actor to install the certificates included: 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.

Q1: The endpoints for receiving the compromised code signing certificates were identified, but is there any infrastructure overlap with the initial support chat, C2, and any further infrastructure the attacker used?

In our investigation, we did not find evidence that the threat actor misused other internal systems other than the Code Signing initialization codes within specific accounts.

Q2: Were there are indications that the attacker had any familiarity with your internal processes, such as knowing the functional workflow to get to the initialization codes?

As an example during the compromise of ENDPOINT1 there had to be some internal recon to pivot to ENDPOINT2. That there only seems to be a direct path to obtaining code signing certificates through this specific method from then onwards is unusual. I would expect some more persistence attempted to be used by the attacker. That they were able to find the one machine that has below standard EDR posture is concerning. By the report, any other system compromise would have been detected and raised more flags but the attackers seemed quite lucky.

My thought process there is not necessarily any internal assistance, but on how involved the prior recon period was and if any undisclosed compromises outside of this specific CA infrastructure was informative to the attacker's later purpose. Likewise, if there was a lack of interest in enumerating your customer list and the potential to use your support channel as a pivot point to customers.

Q3: I presume that any support communication from the compromised endpoints and accounts in the time period was also reviewed?

The lack of any obvious interaction from your side doesn't necessitate that any customer information wasn't passed along to a different group for phishing purposes, of course.

• Additional considerations: There is also observed use of compromised certificates from different CAs to sign the "Zhong Stealer" malware family.

Q5: Can DigiCert name the different CAs?

Q6: Is there a public timeline for usage of the compromised certificates to layout a pattern?

Q7: Are DigiCert aware of any other CA that has not disclosed their infrastructure being compromised?

Date / Time (UTC)	Event
2026-04-14 17:25	Compromised machine ENDPOINT2 is collected by Service Desk; hard drive is found to be encrypted. Machine is being returned to Trust Operations for analysis.

Q8: Is the implication here that the attacker became aware of the investigation and attempted to cover their tracks, or that the machine used disk encryption that wasn't known by the investigating team?

There are very useful details missing from the timeline currently, specifically for the timeline of the compromised code signing certificates. The RCA notes:

The initialization code operates as a bearer credential for the approved order and is single use. This feature made it apparent which initialization codes had been used.

However the timeline doesn't give us a picture of:

• how long the initialization codes were sitting valid post-purchase
• how quickly the attacker was able to become aware of newly active initialization codes
• how quickly they were added to hardware tokens
• and any interesting telemetry from those steps

Q9: The third party reports have implied to all be security researchers, but did any customers not ask why their initialization codes were non-functional during 04-05 to 04-14?

Q10: Presumably the attacker wasn't success with all of the initialization codes, did this produce any alerts? Re-use via impossible travel for instance - no reason that should be purely internal.

This has been a very interesting report and I'm sure I'm only scratching the surface of thoughts everyone has had on reading it.

Comment 6

[Martijn Katerbarg]

Hi Wayne,

Q5: Can DigiCert name the different CAs?

I wanted to inject on this question. Please note my answers here are in my capacity as Chair of the Code Signing Working Group.
Code Signing certificates in use by threat actors is a big topic within the industry. Last year we had security researchers present to us at one of the CA/B Forum F2F meetings, specifically around code signing.

A problem generally is that CAs are not able to tell at time of issuance if an organization will start signing malware or not. It’s been pointed out several times that threat actors will register organizations, then wait several years, before utilizing said company to purchase code signing certificates. With that, this is a hard-to-tackle issue, as initially these certificates are issued in line with the requirements.

There are websites which provide more insight into certificates being used for malware signing, among which one is https://certgraveyard.org/, run by one of the researchers who presented previously at the F2F.

Comment 7

[DigiCert]

Thanks for your feedback and questions Wayne. Responding to Comment 5:

Our investigation included review of the threat actor's activity in the support system as well as tracing delivery to IP addresses known to have been used by the threat actor. The IP addresses used by the bad actor to install the certificates included: 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.

Q1: The endpoints for receiving the compromised code signing certificates were identified, but is there any infrastructure overlap with the initial support chat, C2, and any further infrastructure the attacker used?

We have not identified any infrastructure overlap between the endpoints used to receive the compromised Code Signing certificates and those associated with the initial support chat, nor subsequent command and control (C2) activity.

In our investigation, we did not find evidence that the threat actor misused other internal systems other than the Code Signing initialization codes within specific accounts.

Q2: Were there are indications that the attacker had any familiarity with your internal processes, such as knowing the functional workflow to get to the initialization codes? As an example during the compromise of ENDPOINT1 there had to be some internal recon to pivot to ENDPOINT2. That there only seems to be a direct path to obtaining code signing certificates through this specific method from then onwards is unusual. I would expect some more persistence attempted to be used by the attacker. That they were able to find the one machine that has below standard EDR posture is concerning. By the report, any other system compromise would have been detected and raised more flags but the attackers seemed quite lucky. My thought process there is not necessarily any internal assistance, but on how involved the prior recon period was and if any undisclosed compromises outside of this specific CA infrastructure was informative to the attacker's later purpose. Likewise, if there was a lack of interest in enumerating your customer list and the potential to use your support channel as a pivot point to customers.

We believe the threat actor simply followed the workflow for customers to pick up initialization codes as documented at https://knowledge.digicert.com/solution/set-up-your-digicert-provided-etoken. As the threat actor accessed the accounts using the support view (seeing account details from the customer's perspective), the knowledgebase provided clear instructions.

As noted in our Full Incident Report, there were six different attempts on 2026-04-02. Four attempts were blocked entirely, and the compromise of ENDPOINT1 was quickly identified and remediated. The compromise of ENDPOINT2 was not initially detected due to missing EDR.

Our subsequent investigation has 1) verified that support/frontline machines are enrolled in EDR, and 2) has not identified other compromised machines. Our investigation did not find evidence that the threat actor misused internal systems other than to access active initialization codes within specific accounts.

Q3: I presume that any support communication from the compromised endpoints and accounts in the time period was also reviewed? The lack of any obvious interaction from your side doesn't necessitate that any customer information wasn't passed along to a different group for phishing purposes, of course.

Communications, network activity, and portal use from the compromised endpoints and accounts were reviewed in detail. Our investigation included analysis of support chat logs, outbound communications, and data access/export activity. Based on this review, we found no evidence that customer-related data was misused, and no indicators of data staging, bulk extraction, or onward transmission.

Q4:

There was no Q4 question.

Additional considerations: There is also observed use of compromised certificates from different CAs to sign the "Zhong Stealer" malware family.

Q5: Can DigiCert name the different CAs?

During our investigation, we became aware of Code Signing certificates from the following CAs being used in conjunction with the “Zhong Stealer” malware family issued between January 1, 2025 and March 31, 2026 (before this incident).

CA Name	Certificates
Certum	7
DigiCert	1
GlobalSign	5
Sectigo	26
SSL.com	2

We are not aware of any link, either in timeframe or approach, between those certificates and this report.

Q6: Is there a public timeline for usage of the compromised certificates to layout a pattern?

We do not track the dates when compromised certificates are misused, but rather the dates we receive certificate problem reports (detailed in our timeline). As a pattern, we observe that, following comprise, Code Signing certificates are rapidly put to use in signing malware, recognizing the narrowing window of response by security researchers to identify the misuse and by CAs to revoke the certificates.

DigiCert is grateful for the specialized assistance of security researchers in identifying and promptly reporting misused Code Signing certificates.

Q7: Are DigiCert aware of any other CA that has not disclosed their infrastructure being compromised?

No. DigiCert has noted an ongoing increase in social engineering attempts in the current time period through our CA customer support channels that is believed to be associated with this incident, but we have no knowledge of similar attempts made against other CAs or whether such attempts have been successful on other CAs.

Compromised machine ENDPOINT2 is collected by Service Desk; hard drive is found to be encrypted. Machine is being returned to Trust Operations for analysis.

Q8: Is the implication here that the attacker became aware of the investigation and attempted to cover their tracks, or that the machine used disk encryption that wasn't known by the investigating team?

DigiCert encrypts the hard drives of employee laptops. ENDPOINT2 was encrypted when recovered, but that encryption did not match the recovery key in our possession. We are not certain of the circumstances of that encryption, and do not have (nor anticipate gaining) unencrypted access to the content of the machine. As a result, our investigation has been based on logging data. DigiCert acknowledges the assistance of CrowdStrike support desk in our investigation of ENDPOINT2.

There are very useful details missing from the timeline currently, specifically for the timeline of the compromised code signing certificates. The RCA notes: The initialization code operates as a bearer credential for the approved order and is single use. This feature made it apparent which initialization codes had been used. However the timeline doesn't give us a picture of: how long the initialization codes were sitting valid post-purchase, how quickly the attacker was able to become aware of newly active initialization codes, how quickly they were added to hardware tokens, and any interesting telemetry from those steps

The workflow of initialization codes is described in our Root Cause Analysis. The initialization codes are provided to the customer in the portal following the completion of validation for the order. The initialization code disappears from the order when it is used to issue the certificate to an eligible token.

The attachment “2033170_initialization_code_analysis” provides detail on the timing related to the 11 certificate problem reports.

• Case_created: timestamp of the certificate problem report. All certificates were revoked within 24 hours of the report.
• Initialization_code_created: timestamp indicating when the initialization code becomes visible in the portal after the order is approved.
• Initialization_code_accessed: timestamp indicating when the token was viewed by the threat actor.
• Initialization_code_used: timestamp indicating when the threat actor installed the certificate on an eligible bring-your-own token using the DigiCert Hardware Certificate Installer.

Typically, there is a variable delay between approval and when the customer uses the initialization code, at their discretion, which accommodates delivery time for the token and the customer’s own internal processes. DigiCert initialization codes have a 30-day time out.

The data shows that the threat actor harvested the initialization codes and, with two exceptions, picked up the corresponding certificates before DigiCert’s discovery of the ENDPOINT2 compromise and closing of the threat actor’s access. In most cases, the certificates were picked up and used to sign malware within hours of the initialization code being accessed.

The two exceptions occurred as we worked through identifying the method of attack and potentially impacted accounts, contacting customers to confirm legitimate activity. In the interim, in possession of valid initialization codes, the threat actor was still able to pick up remaining active orders. These were rapidly identified and revoked.

Q9: The third party reports have implied to all be security researchers, but did any customers not ask why their initialization codes were non-functional during 04-05 to 04-14?

The third party reports were from security researchers. Affected customers were informed as we cancelled pending orders (which removed the corresponding initialization codes) and revoked certificates.

We did not receive customer reports about non-functional initialization codes during this period. As the initialization codes are single use, they would have disappeared from customer view with use by the threat actor.

Q10: Presumably the attacker wasn't success with all of the initialization codes, did this produce any alerts? Re-use via impossible travel for instance - no reason that should be purely internal.

Once we cancelled all affected pending orders (thereby nullifying initialization codes), our systems began creating alerts as the threat actor (who no longer had access to the portal to know up-to-date status for the initialization codes) attempted to use now-invalid codes.

Comment 8

[DigiCert]

Attachment: 2033170_initialization_code_analysis.csv

Comment 9

[Wayne]

(In reply to Martijn Katerbarg from comment #6)

Hi Wayne,

Q5: Can DigiCert name the different CAs?

I wanted to inject on this question. Please note my answers here are in my capacity as Chair of the Code Signing Working Group.
Code Signing certificates in use by threat actors is a big topic within the industry. Last year we had security researchers present to us at one of the CA/B Forum F2F meetings, specifically around code signing.

A problem generally is that CAs are not able to tell at time of issuance if an organization will start signing malware or not. It’s been pointed out several times that threat actors will register organizations, then wait several years, before utilizing said company to purchase code signing certificates. With that, this is a hard-to-tackle issue, as initially these certificates are issued in line with the requirements.

There are websites which provide more insight into certificates being used for malware signing, among which one is https://certgraveyard.org/, run by one of the researchers who presented previously at the F2F.

Yup, I'm aware and was more concerned on the implication of further CA compromise implied in the statement where no public evidence existed.

(In reply to DigiCert from comment #7)

We have not identified any infrastructure overlap between the endpoints used to receive the compromised Code Signing certificates and those associated with the initial support chat, nor subsequent command and control (C2) activity.

Thank you for answering.

We believe the threat actor simply followed the workflow for customers to pick up initialization codes as documented at https://knowledge.digicert.com/solution/set-up-your-digicert-provided-etoken. As the threat actor accessed the accounts using the support view (seeing account details from the customer's perspective), the knowledgebase provided clear instructions.

As noted in our Full Incident Report, there were six different attempts on 2026-04-02. Four attempts were blocked entirely, and the compromise of ENDPOINT1 was quickly identified and remediated. The compromise of ENDPOINT2 was not initially detected due to missing EDR.

Our subsequent investigation has 1) verified that support/frontline machines are enrolled in EDR, and 2) has not identified other compromised machines. Our investigation did not find evidence that the threat actor misused internal systems other than to access active initialization codes within specific accounts.

I did read the knowledge base documentation before asking, but it sounds like the attackers were quite focused on their goals.

Communications, network activity, and portal use from the compromised endpoints and accounts were reviewed in detail. Our investigation included analysis of support chat logs, outbound communications, and data access/export activity. Based on this review, we found no evidence that customer-related data was misused, and no indicators of data staging, bulk extraction, or onward transmission.

Understood, just making that clear in the public report.

Q4:

There was no Q4 question.

I could provide one if necessary, however I'll make sure to double check the numbers next time.

During our investigation, we became aware of Code Signing certificates from the following CAs being used in conjunction with the “Zhong Stealer” malware family issued between January 1, 2025 and March 31, 2026 (before this incident).

CA Name	Certificates
Certum	7
DigiCert	1
GlobalSign	5
Sectigo	26
SSL.com	2

We are not aware of any link, either in timeframe or approach, between those certificates and this report.

I didn't specify the timeframe, however I can see that focus is being given to the PR angle here and not the factually relevant details. Please do not try to conflate certificates obtained through fraudulent representation of entities, with ones obtained through system compromise of CAs themselves.

Q6: Is there a public timeline for usage of the compromised certificates to layout a pattern?

We do not track the dates when compromised certificates are misused, but rather the dates we receive certificate problem reports (detailed in our timeline). As a pattern, we observe that, following comprise, Code Signing certificates are rapidly put to use in signing malware, recognizing the narrowing window of response by security researchers to identify the misuse and by CAs to revoke the certificates.

The initialization code analysis you provided should help establish a pattern, thank you for posting it.

DigiCert is grateful for the specialized assistance of security researchers in identifying and promptly reporting misused Code Signing certificates.

I'll be sure to continue on that front then.

Q7: Are DigiCert aware of any other CA that has not disclosed their infrastructure being compromised?

No. DigiCert has noted an ongoing increase in social engineering attempts in the current time period through our CA customer support channels that is believed to be associated with this incident, but we have no knowledge of similar attempts made against other CAs or whether such attempts have been successful on other CAs.

Thank you for clarifying that.

DigiCert encrypts the hard drives of employee laptops. ENDPOINT2 was encrypted when recovered, but that encryption did not match the recovery key in our possession. We are not certain of the circumstances of that encryption, and do not have (nor anticipate gaining) unencrypted access to the content of the machine. As a result, our investigation has been based on logging data. DigiCert acknowledges the assistance of CrowdStrike support desk in our investigation of ENDPOINT2.

Okay so it is strongly implied that the attackers encrypted the drive upon detection, but there is no explicit evidence that this occurred on your end?

The workflow of initialization codes is described in our Root Cause Analysis. The initialization codes are provided to the customer in the portal following the completion of validation for the order. The initialization code disappears from the order when it is used to issue the certificate to an eligible token.

The attachment “2033170_initialization_code_analysis” provides detail on the timing related to the 11 certificate problem reports.

• Case_created: timestamp of the certificate problem report. All certificates were revoked within 24 hours of the report.
• Initialization_code_created: timestamp indicating when the initialization code becomes visible in the portal after the order is approved.
• Initialization_code_accessed: timestamp indicating when the token was viewed by the threat actor.
• Initialization_code_used: timestamp indicating when the threat actor installed the certificate on an eligible bring-your-own token using the DigiCert Hardware Certificate Installer.

Typically, there is a variable delay between approval and when the customer uses the initialization code, at their discretion, which accommodates delivery time for the token and the customer’s own internal processes. DigiCert initialization codes have a 30-day time out.

The data shows that the threat actor harvested the initialization codes and, with two exceptions, picked up the corresponding certificates before DigiCert’s discovery of the ENDPOINT2 compromise and closing of the threat actor’s access. In most cases, the certificates were picked up and used to sign malware within hours of the initialization code being accessed.

The two exceptions occurred as we worked through identifying the method of attack and potentially impacted accounts, contacting customers to confirm legitimate activity. In the interim, in possession of valid initialization codes, the threat actor was still able to pick up remaining active orders. These were rapidly identified and revoked.

The initialization code analysis posted is quite interesting for how short of a timeframe there is from viewing the code to obtaining the certificate. Thank you for sharing that very useful slice of information.

I would like to note that this report mentioned '45.144.227.29' as receiving a compromised certificate, however this does not appear in the analysis.

The third party reports were from security researchers. Affected customers were informed as we cancelled pending orders (which removed the corresponding initialization codes) and revoked certificates.

We did not receive customer reports about non-functional initialization codes during this period. As the initialization codes are single use, they would have disappeared from customer view with use by the threat actor.

Thank you that was all I was checking - that no customer usage made this misuse apparent.

Once we cancelled all affected pending orders (thereby nullifying initialization codes), our systems began creating alerts as the threat actor (who no longer had access to the portal to know up-to-date status for the initialization codes) attempted to use now-invalid codes.

This incident is primarily dealing with the system compromise, however would it be prudent at some point to give a limited lifespan for these initialization codes?

The case created on '4/12/2026 18:44' noted a Initialization_code_created time of '3/20/2026 1:04', and Initialization_code_accessed time of '4/10/2026 19:20'. That's over 3 weeks of viability for the third-party's account to be compromised post-purchase, and it did not seem like the customer was in a rush to grab it.

That discussion is likely more pertinent on CSCWG, or NETSEC depending on your view. The masking of codes from support's side covers one half of the issue, but I believe there is still more ground to be gained.

Comment 10

[DigiCert]

Martijn, thank you for the contribution in Comment 6. DigiCert reiterates our gratitude for the assistance of security researchers in identifying misused certificates.

Suspected certificate misuse, such as compromised keys, may be reported by emailing [e-mail] with details or using the DigiCert Problem Reporting form to request revocation.

Comment 11

[DigiCert]

Wayne, responding to Comment 9:

Okay so it is strongly implied that the attackers encrypted the drive upon detection, but there is no explicit evidence that this occurred on your end?

The drive is in an unrecoverable state, but we have no evidence whether this was due to actions by the threat actor or the employee.

I would like to note that this report mentioned '45.144.227.29' as receiving a compromised certificate, however this does not appear in the analysis.

This analysis detailed the certificates that were the subject of Certificate Problem Reports. Additional related IP addresses were included in our Full Incident Report.

Once we cancelled all affected pending orders (thereby nullifying initialization codes), our systems began creating alerts as the threat actor (who no longer had access to the portal to know up-to-date status for the initialization codes) attempted to use now-invalid codes.

This incident is primarily dealing with the system compromise, however would it be prudent at some point to give a limited lifespan for these initialization codes? … That discussion is likely more pertinent on CSCWG, or NETSEC depending on your view. The masking of codes from support's side covers one half of the issue, but I believe there is still more ground to be gained.

Currently, the initialization codes have a 30-day validity, which is consistent with allowed Random Value validity in the CABF TLS BR. The topic may be in-scope for the CSCWG as the CABF Code Signing BR do not currently have an equivalent standard. As noted previously, we have an active Action Item to evaluate all our Code Signing certificate delivery workflows to tokens.

Comment 12

[DigiCert]

We are pleased to provide an update of the action items, noting that DigiCert allocated additional resources to accelerate the performance and closure of several items that were initially assigned conservative delivery dates.

Notably, the important tasks addressing sandboxing (see 11), EDR/SASE enrollment (see 20), and EDR hardfail (see 21) are complete. We continue work on the three ongoing items.

We request that the whiteboard next update be set to 20260603 (reporting on 19).

#	Action Item	Kind	Root Cause(s)	Evaluation Criteria	Due Date	Status
1	Complete wipe and reimage of ENDPOINT1; replacement laptop issued	Mitigate	CF #1	Endpoint re-enrolled in EDR with correct policy configuration	2026-04-03	Complete
2	Remove malicious files from Salesforce cases and associated chat records	Mitigate	CF #4	All identified malicious attachments removed; confirmed via case audit	2026-04-03	Complete
3	Correct Windows CrowdStrike prevention setting to eradicate-on-detection configuration	Prevent	CF #1	CrowdStrike policy confirms eradicate-on-detection applied to all Windows endpoints	2026-04-04	Complete
4	Disable Okta FastPass for support portal; enforce proper second-factor MFA for administrative workflows	Prevent	CF #1	FastPass disabled; phishing-resistant MFA enforced; confirmed via identity policy audit	2026-04-14	Complete
5	Mask initialization codes from proxied support users (UI)	Prevent	CF #2 / CF #3	Initialization codes inaccessible in proxied sessions via UI; verified by QA and production validation	2026-04-14	Complete
6	Mask initialization codes from proxied support users (API)	Prevent	CF #2 / CF #3	Initialization codes inaccessible in proxied sessions via API; verified by QA and production validation	2026-04-15	Complete
7	Detailed evaluation of capabilities of proxied support users.	Prevent	CF #2 / CF #3	Ensure that privileged access is enforced and "action items" and sensitive data are masked	2026-05-15	Complete
8	Engage CrowdStrike support on ENDPOINT2 sensor not being installed and differential detection outcomes	Detect	CF #1	Root cause of sensor not being installed documented; findings incorporated into remediation plan	2026-04-14	Complete
9	Collect ENDPOINT2 for hands-on sensor inspection	Detect	CF #1	Collected; being returned to US Service Desk for further investigation	2026-04-14	Complete
10	Review and restrict file types permitted through support chat and Salesforce case attachments	Prevent	CF #4	High-risk file types (.exe, .scr, .zip) blocked at ingestion; confirmed via attachment policy audit	2026-04-17	Complete
11	Evaluate and implement sandboxing or detonation controls for files delivered through support channels	Prevent	CF #4	Sandboxing/detonation deployed for inbound support attachments; integration tested	2026-08-01	Complete
12	Expand metadata logging and monitoring for support chat file delivery	Detect	CF #4	Enhanced metadata logging deployed; minimum log fields defined; confirmed via log coverage audit	2026-08-01	Ongoing
13	Targeted coaching for users involved; additional social engineering awareness training for staff	Prevent	CF #4	Training completed; completion rate tracked; refreshed annually	2026-04-17	Complete
14	Evaluate all CrowdStrike and zScaler policies; enforce EDR eradication globally; implement application allowlisting for high-risk roles	Prevent	CF #1	Policy review completed; eradication enforced globally; allowlisting deployed for validation and support roles	2026-05-01	Complete
15	Eliminate device-bound MFA (Okta FastPass) as a sole factor for sensitive applications; require phishing-resistant MFA	Prevent	CF #1	No device-bound MFA as sole factor for any CA-system-access application; confirmed via identity policy audit	2026-04-14	Complete
16	Analyze portal function access; implement JIT privileged access and dual authorization for certificate-impacting proxied operations; introduce anomaly detection on issuance workflows	Prevent	CF #2 / CF #3	JIT access and dual-auth deployed for defined certificate-impacting proxy operations; anomaly detection rule live with defined threshold	2026-10-01	Ongoing
17	Tune impossible travel detection and risk scoring to DigiCert's operational context; employ high-severity session hijacking alerts	Detect	CF #1	Updated risk scoring deployed; impossible travel on high-privilege accounts generates minimum High severity alert	2026-04-16	Complete
18	Enforce always-on zScaler Internet Access including when VPN is active; block direct internet egress; require TLS inspection for high-risk categories	Prevent	CF #4	ZIA always-on enforced with no direct egress exceptions for unapproved methods; confirmed via network policy audit	2026-04-17	Complete
19	Evaluate all Code Signing certificate delivery workflows to tokens	Prevent	CF #3	Improved association of certificate delivery to the account holder	2026-06-01	Ongoing
20	Implement automated continuous EDR/SASE coverage monitoring; enforce 100% enrollment	Detect	CF #1	Automated reconciliation in place; SOC alerted on coverage gaps	2026-06-01	Complete
21	Define device EDR posture hard-failure conditions blocking access to corporate systems	Detect	CF #1	Non-compliant devices denied access	2026-08-01	Complete

Comment 13

[DigiCert]

DigiCert continues to work on the remaining action items described in Comment 12.

Comment 14

[DigiCert]

DigiCert has completed action item 19, evaluating the Code Signing certificate delivery workflows used by DigiCert. This included a review of the handling of initialization codes, and system changes to ensure that these codes are only accessible to authorized customer account admins. We request that the whiteboard next update be set to 20260701.

Comment 15

[DigiCert]

Action Item 12 has been completed earlier than our original due date. DigiCert expanded logging and monitoring for file delivery, covering endpoints via all support channels.

Comment 16

[DigiCert]

Action Item 16 has been completed in advance of our original due date. All proxy access is read-only, and sensitive fields (such as initialization codes) have been masked. That completes all the Action Items described in our report.

We will follow up with the closure report.

Comment 17

[DigiCert]

Report Closure Summary

Incident description: On 2026-04-02, a bad actor social-engineered DigiCert support analysts into executing a malicious file delivered via the customer chat channel, compromising two support analyst workstations. An endpoint detection and response (EDR) coverage gap on the second workstation allowed the bad actor to access an internal support portal, during which initialization codes for approved Code Signing certificate orders were obtained. DigiCert revoked 60 Code Signing certificates and cancelled pending initialization codes within the window of interest, closing the noncompliance by 2026-04-17.

Communications, network activity, and portal use from the compromised endpoints and accounts were reviewed in detail. Our investigation did not find evidence that the bad actor misused internal systems other than to access active initialization codes within specific accounts.

Incident Root Cause(s): Our Full Incident Report identified several contributing factors, which were addressed in our remediation Action Items:

• CF1: Inconsistent or incomplete EDR coverage allowed the attacker to extend their dwell time.
• CF2: Insufficient privilege minimization in the support portal function allowed the attacker to access initialization codes.
• CF3: Initialization codes were not protected as bearer credentials accessible only to the customer.
• CF4: Permissive file transfer capability in customer-facing support channels facilitated the attack.

Remediation description: Affected certificates were revoked within 24 hours of discovery. DigiCert implemented Action Items to prevent social engineering via support channels through file-type restrictions, sandboxing, training, and network egress controls; to prevent unauthorized certificate access through initialization code masking and restriction of proxied support capabilities; and to prevent and detect endpoint compromise through EDR policy remediation, MFA hardening, and continuous coverage monitoring. All Action Items have been completed. See Comment 12 for more detailed descriptions of the Action Items.

Commitment summary: DigiCert commits to enhancing monitoring and alerting to detect future gaps in EDR sensor deployment, so that coverage is remediated proactively. DigiCert notes that the number of channels by which customers can reach support staff evolves, and commits to review file handling controls and sandboxing across new customer-facing support channels. DigiCert commits to implementing controls treating initialization codes as single-use bearer credentials throughout their lifecycle, including expiry controls.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 18

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2026-07-16.