DigiCert Data Breach: Rogue Account on Internal System Exposes Business Customer Data — Detection and Hardening Guide

DigiCert, one of the world's largest certificate authorities and a trust anchor for a significant share of the internet's TLS infrastructure, has disclosed a data breach affecting business customer information. According to the company's disclosure, threat actors created an account on an internal DigiCert system and used that access to obtain customer names, email addresses, phone numbers, and business addresses.

Let me be direct about why this matters beyond the headline. First, the intrusion vector is the one I see most often in IR engagements that end badly: not a zero-day, not a sophisticated implant — just an unauthorized account created on an internal system that nobody was watching. Second, the victim profile is high-value. DigiCert's business customers are enterprises, and their contact data — names, corporate emails, direct phone numbers, business addresses — is precisely the raw material for targeted phishing, vishing, and business email compromise campaigns. If your organization is a DigiCert customer, your employees should treat any inbound communication referencing certificates, renewals, or PKI matters as suspect until verified out-of-band.

The good news: this attack pattern is highly detectable if you have basic identity telemetry in place. The bad news: most organizations don't alert on account creation in their internal SaaS and admin portals at all.

Technical Analysis

What happened

Based on DigiCert's disclosure as reported by SecurityWeek:

• Attack vector: Threat actors created an account on an internal DigiCert system. The reporting does not indicate exploitation of a software vulnerability — no CVE has been associated with this incident. This is an identity-plane intrusion, not a code-plane one.
• Data accessed: Business customer names, email addresses, phone numbers, and business addresses.
• Data not reported as affected: There is no indication that private keys, issued certificates, or certificate signing infrastructure were compromised. That distinction is critical — a CA breach that touches key material or issuance pipelines would be a trust-level event (think DigiNotar 2011). This incident, as disclosed, is a customer-data exposure event.

The attack pattern: rogue account creation + valid account abuse

From a defender's perspective, this maps cleanly to two MITRE ATT&CK techniques:

• T1136 – Create Account: The adversary establishes a foothold by creating a new account rather than stealing an existing one. This is common when registration or provisioning workflows are exposed, when invitation flows can be abused, or when an attacker has brief access to an admin console and uses it to mint persistent credentials.
• T1078 – Valid Accounts: Once the account exists, all subsequent activity looks 'legitimate' to most logging stacks. Authentication succeeds. Authorization checks pass. Traditional anomaly detection tuned for failed logons and impossible travel sees nothing.

The typical chain we see in cases like this:

1. Initial access — compromised credentials, an exposed self-service registration endpoint, a social-engineered invitation, or abuse of a partner/vendor onboarding flow.
2. Account creation — a new user is provisioned directly in the application's user store (not through the corporate IdP, which is why it evades centralized IAM monitoring).
3. Dwell and reconnaissance — the account is used intermittently, often from VPN or residential proxy exit nodes, to explore what data the role can reach.
4. Collection and exfiltration — bulk export of customer records via the application's own reporting, API, or admin export functionality. The exfil channel is the application itself, over HTTPS, blending into normal traffic.

Why this evades typical controls

• IdP blind spot: Many internal business applications maintain local user databases alongside SSO. Accounts created locally never generate an Entra ID/Okta 'user created' event.
• No malware involved: EDR has nothing to detect. The entire attack lives in the application layer.
• Low-and-slow access patterns: A handful of sessions over weeks doesn't trip volume-based alerting.
• Export functionality is a feature: Bulk data access uses sanctioned UI/API paths, so DLP and network controls rarely flag it unless they're tuned for volume and destination anomalies.

Exploitation status

This is a confirmed, completed intrusion — not theoretical. The relevant question for your organization is not 'is this exploited' but 'are the same conditions present in our environment': internal applications with local account stores, self-service registration, weak provisioning governance, and no alerting on new account creation. In 2025–2026, identity-first intrusions of exactly this type remain the dominant initial-access pattern across the incidents my firm responds to.

Detection & Response

The detections below target the two behaviors at the heart of this incident: unauthorized account creation and abuse of that account for bulk data access. They are deliberately scoped to minimize noise — account creation events are low-frequency in most environments and reviewing them is cheap.

Sigma Rules

---
title: Local Account Created Outside Identity Provider on Server or Application Host
id: 3f8a2c14-9b7d-4e51-a6c2-8d4f1a9b7e30
status: experimental
description: Detects creation of local user accounts on servers hosting internal business applications. Rogue account creation on internal systems — as in the DigiCert breach — is a hallmark persistence and access technique (T1136). Local accounts bypass IdP monitoring and should be rare on production application servers.
references:
  - https://attack.mitre.org/techniques/T1136/001/
  - https://www.securityweek.com/digicert-data-breach-impacts-business-customer-information/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.persistence
  - attack.t1136.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_net:
    Image|endswith:
      - '\net.exe'
      - '\net1.exe'
    CommandLine|contains:
      - 'user'
      - '/add'
  selection_powershell:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'New-LocalUser'
      - 'New-ADUser'
      - 'net user'
  condition: selection_net or selection_powershell
falsepositives:
  - Automated provisioning tools and configuration management (Ansible, SCCM) creating service accounts — whitelist known deployment accounts and hosts
level: high
---
title: New Local User Account Registered via Security Audit Event
id: 7c2e9b41-5d38-4f6a-b1e4-2a8c6d3f9e17
status: experimental
description: Detects Windows Security event 4720 (user account created) on servers where account creation is not routine. In the DigiCert incident, attackers established access by creating an account on an internal system; alert on any account creation on hosts outside defined provisioning windows or approved admin groups.
references:
  - https://attack.mitre.org/techniques/T1136/
  - https://www.securityweek.com/digicert-data-breach-impacts-business-customer-information/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.persistence
  - attack.t1136
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4720
  filter_approved:
    SubjectUserName|endswith:
      - '$'
  condition: selection and not filter_approved
falsepositives:
  - Helpdesk and IAM provisioning activity — correlate against change tickets; tune SubjectUserName allowlist to approved provisioning accounts
level: medium
---
title: Bulk Export or Mass Read of Customer Records from Application Database
id: a4d7f2c8-1e96-4b3a-95d0-6c1a8f4b2e59
status: experimental
description: Detects database service accounts or application processes executing mass-read patterns consistent with customer record exfiltration, such as SELECT statements against customer/contact tables originating from unexpected client processes or hosts. Mirrors the collection phase of the DigiCert breach where customer names, emails, phone numbers, and addresses were accessed.
references:
  - https://attack.mitre.org/techniques/T1213/
  - https://attack.mitre.org/techniques/T1530/
  - https://www.securityweek.com/digicert-data-breach-impacts-business-customer-information/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.collection
  - attack.t1213
  - attack.t1530
logsource:
  category: database
  product: windows
detection:
  selection:
    Query|contains:
      - 'customer'
      - 'contact'
      - 'email'
      - 'phone'
    Query|contains|all:
      - 'select'
  filter_app_hosts:
    ClientHost|startswith:
      - '10.10.5.'
  condition: selection and not filter_app_hosts
falsepositives:
  - Reporting jobs, ETL pipelines, and backup processes — baseline approved ClientHost ranges and service accounts before enabling
level: high

KQL — Microsoft Sentinel / Defender

This query hunts for the account-creation foothold across Windows, and pairs it with detection of anomalous first-seen sign-ins to internal applications — the two observables most likely to have surfaced the DigiCert intrusion earlier.

// Hunt 1: New account creation events on servers — flag accounts created by non-approved actors
let ApprovedProvisioners = dynamic(["svc_iam_provisioning", "svc_sccm", "helpdesk-admin"]);
SecurityEvent
| where EventID == 4720
| where TimeGenerated > ago(30d)
| where SubjectUserName !in~ (ApprovedProvisioners)
| summarize AccountsCreated = make_set(TargetUserName), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SubjectUserName, Computer
| extend CreatedCount = array_length(AccountsCreated)
| order by LastSeen desc;

// Hunt 2: First-seen sign-in to internal apps from accounts with no prior 90-day history
// Catches valid-account abuse where a rogue account is used after creation (T1078)
let Lookback = 90d;
let Recent = 7d;
let HistoricUsers =
    SigninLogs
    | where TimeGenerated > ago(Lookback) and TimeGenerated < ago(Recent)
    | where ResultType == 0
    | distinct UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(Recent)
| where ResultType == 0
| where UserPrincipalName !in~ (HistoricUsers)
| where AppDisplayName has_any ("internal", "admin", "portal", "crm", "customer")
| summarize SignIns = count(), Apps = make_set(AppDisplayName), IPs = make_set(IPAddress)
    by UserPrincipalName
| order by SignIns desc;

// Hunt 3: Anomalous data egress volume from application/database servers (bulk export pattern)
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where DeviceName has_any ("sql", "db", "crm", "app")
| where RemotePort in (443, 8443)
| summarize BytesOut = sum(BytesSent), Connections = count(), Destinations = make_set(RemoteIP)
    by DeviceName, InitiatingProcessAccountName
| where BytesOut > 500000000   // ~500MB baseline — tune to your environment
| order by BytesOut desc;

Velociraptor VQL

Use this artifact during IR scoping on any host suspected of being the application or jump server involved in unauthorized account creation. It inventories local accounts, their creation timestamps, and active sessions/connections so you can diff against your known-good account list.

-- IR scoping: enumerate local accounts, creation times, and live network sessions
-- Goal: identify accounts that do not appear in the approved provisioning manifest
LET accounts = SELECT Name, Description, SID, LastLogon
  FROM wmi(query="SELECT Name, Description, SID, LastLogon FROM Win32_UserAccount WHERE LocalAccount = TRUE")

LET sessions = SELECT Pid, Name, Username, RemoteAddr, RemotePort, State
  FROM netstat()
  WHERE State = 'ESTABLISHED' AND RemotePort IN (443, 8443, 3389, 22)

SELECT * FROM accounts
UNION ALL
SELECT * FROM sessions

For a tighter account-focused hunt across a fleet, deploy this as a hunt and compare results against your CMDB export — any account not in the manifest is an immediate investigation lead:

-- Fleet hunt: surface local accounts created recently on application servers
SELECT Name, SID,
       timestamp(epoch=atoi(string=parse_string_with_regex(
         string=SID, regex=".*").g1)) AS Placeholder
FROM wmi(query="SELECT Name, SID FROM Win32_UserAccount WHERE LocalAccount = TRUE")
WHERE Name !~ '^(Administrator|DefaultAccount|Guest|WDAGUtilityAccount|svc_)'

Remediation & Verification Script

Run this on Windows application servers to audit local accounts against an approved list and disable anything unauthorized. For the application layer, pair it with your IdP audit (second half).

# Requires elevation. Audit local accounts against an approved manifest and disable rogues.
# Replace the approved list with your CMDB/provisioning source of truth.

$ApprovedAccounts = @("Administrator","DefaultAccount","Guest","WDAGUtilityAccount","svc_app","svc_backup")
$ReportPath = "C:\IR\LocalAccountAudit_$(Get-Date -Format 'yyyyMMdd_HHmm').csv"
New-Item -ItemType Directory -Path "C:\IR" -Force | Out-Null

$LocalAccounts = Get-LocalUser | Select-Object Name, Enabled, LastLogon, Description, SID
$Findings = foreach ($acct in $LocalAccounts) {
    $isApproved = $ApprovedAccounts -contains $acct.Name
    [PSCustomObject]@{
        Name       = $acct.Name
        Enabled    = $acct.Enabled
        LastLogon  = $acct.LastLogon
        Approved   = $isApproved
        Action     = if (-not $isApproved -and $acct.Enabled) { "DISABLE" } else { "NONE" }
    }
    if (-not $isApproved -and $acct.Enabled) {
        Disable-LocalUser -Name $acct.Name
        Write-Warning "Disabled unauthorized local account: $($acct.Name)"
    }
}
$Findings | Export-Csv -Path $ReportPath -NoTypeInformation
Write-Host "Audit complete. Report: $ReportPath" -ForegroundColor Green

# Verify: pull account creation events from the last 30 days for IR correlation
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720; StartTime=(Get-Date).AddDays(-30)} |
    Select-Object TimeCreated, @{N='CreatedAccount';E={$_.Properties[0].Value}},
                  @{N='CreatedBy';E={$_.Properties[4].Value}} |
    Format-Table -AutoSize

For the cloud/IdP side (Entra ID), audit application-level accounts and consent grants that bypass SSO — the SaaS equivalent of DigiCert's internal-system account:

# Find cloud accounts created recently and service principals with new credentials
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","Application.Read.All"

$since = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgUser -Filter "createdDateTime ge $since" -All |
    Select-Object DisplayName, UserPrincipalName, CreatedDateTime, AccountEnabled |
    Format-Table -AutoSize

# Audit directory role assignments — who granted admin rights recently?
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add member to role'" -Top 50 |
    Select-Object ActivityDateTime, @{N='InitiatedBy';E={$_.InitiatedBy.User.UserPrincipalName}},
                  @{N='TargetUser';E={$_.TargetResources[0].UserPrincipalName}} |
    Format-Table -AutoSize

Remediation

If your organization is a DigiCert customer

1. Assume your contact data is in adversary hands. Names, corporate emails, phone numbers, and business addresses are a complete phishing kit. Expect well-crafted lures referencing certificate renewals, revocation notices, CT log anomalies, or 'urgent PKI action required' themes in the coming weeks.
2. Brief your help desk and finance teams now. Vishing against 'the person who handles certificates' is a near-certain follow-on. Establish an out-of-band verification procedure for any DigiCert-related request — hang up, call the number in your contract portal, never the number in the inbound call or email.
3. Verify your certificate inventory independently. Although there's no indication issuance infrastructure was touched, best practice after any CA-vendor incident is to confirm your issued-certificate inventory via CT log monitoring (crt.sh, Cert Spotter, or your EASM platform) matches what you expect. Rogue certificates for your domains would be the worst-case scenario and are publicly observable — check.
4. Rotate any credentials or API keys used with DigiCert services (CertCentral API keys, automation tokens) as a precaution until DigiCert confirms the full scope.

If you operate internal systems with customer data (the real lesson)

1. Inventory every application with a local user store. Any app that can create accounts outside your IdP is a monitoring gap. Force SSO where possible; where not, ship application audit logs to your SIEM.
2. Alert on account creation — everywhere. This is one of the highest signal-to-noise detections in existence. Legitimate account creation is rare and almost always tied to a ticket. Everything else is an incident until proven otherwise.
3. Enforce phishing-resistant MFA (FIDO2/passkeys) on all administrative and customer-data-bearing portals. Account creation abuse frequently follows credential theft; MFA breaks the chain.
4. Gate bulk export functionality. Mass export of customer records should require step-up authentication, dual approval, or at minimum generate a high-priority alert. Treat 'export all contacts' as a privileged operation, because it is one.
5. Baseline egress volume from application and database servers. A low-and-slow attacker still has to move the data out eventually.
6. Tabletop this exact scenario with your IR team: 'an account was created on our CRM by an unknown party and 40,000 customer records were exported.' If your answer to 'would we have detected it?' is anything other than an immediate yes, you have work to do this quarter.

Vendor and disclosure follow-up

Monitor DigiCert's official communications for the completed forensic scope — particularly confirmation of how the account was created (exposed registration flow vs. compromised admin access), the dwell time, and whether the system held anything beyond the disclosed fields. Notification obligations for affected customers under state breach notification laws and GDPR (for EU data subjects) are DigiCert's responsibility, but downstream customers should document their own exposure assessment for their regulators and cyber insurers.

Conclusion

The DigiCert breach is not a story about a sophisticated zero-day. It's a story about the most common and most preventable intrusion pattern of this era: an account created where nobody was looking, on a system holding data worth stealing. Certificate authorities are high-trust targets, and their customer lists are high-value targeting data. If you take one action from this post, make it this: build the 'account created outside the IdP' alert this week. It costs almost nothing to run, fires almost never, and when it fires, it matters.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub