Title: 2033170 - DigiCert: Misissued code signing certificates

Author: DigiCert

Source: https://bugzilla.mozilla.org/show_bug.cgi?id=2033170

Page Structure Map

2033170 - DigiCert: Misissued code signing certificates
├── Preliminary Incident Report
│   └── Summary
└── Full Incident Report
    ├── Summary
    ├── Impact
    ├── Timeline
    ├── Related Incidents
    ├── Root Cause Analysis
    ├── Lessons Learned
    ├── Action Items
    └── Appendix

2033170 - DigiCert: Misissued code signing certificates
├── Preliminary Incident Report
│   └── Summary
└── Full Incident Report
    ├── Summary
    ├── Impact
    ├── Timeline
    ├── Related Incidents
    ├── Root Cause Analysis
    ├── Lessons Learned
    ├── Action Items
    └── Appendix

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

Assignee: nobody → dcbugzillaresponse

Status: UNCONFIRMED → ASSIGNED

Ever confirmed: true

Whiteboard: [ca-compliance] [code-signing-misissuance]

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.

Related Incidents

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.

Appendix

A CSV file with full certificate details is attached.

A CSV file with full certificate details is attached.