Finding Enterprise Credentials in Data Breaches: How to Detect Exposure

Why Credential Exposure Is Your Most Common Initial Access Risk

When organizations assess their breach risk, they typically focus on external vulnerabilities: unpatched systems, exposed services, phishing susceptibility. Credential exposure from third-party data breaches rarely gets equivalent attention, despite being the most common initial access vector in enterprise breaches that CyberOne investigates.

The mechanism is straightforward: an employee uses their corporate email address and a personal password on a consumer service — LinkedIn, Adobe, Dropbox, a gaming platform, a retail site. That service gets breached. The credential database is sold on darknet markets. Attackers run the credential pairs against corporate VPN portals, Microsoft 365 tenants, web applications, and Citrix environments. If the employee reused the same password — which studies consistently show occurs in 60-70% of cases — the attacker has valid credentials for your environment without exploiting a single vulnerability.

How to Detect Credential Exposure

The primary tools for enterprise credential exposure monitoring are:

HaveIBeenPwned (HIBP) API: Troy Hunt’s HIBP database indexes credentials from known public breaches and provides an API for domain-level queries. The organization domain query returns all email addresses from your domain that appear in indexed breaches. HIBP is not comprehensive — it covers publicly disclosed breaches, not credentials traded in private darknet markets — but it’s the accessible starting point for understanding exposure scale.

Here’s a basic Python implementation for domain-level HIBP queries:

import requests

API_KEY = "your-hibp-api-key"
DOMAIN = "yourcompany.com"

headers = {
    "hibp-api-key": API_KEY,
    "user-agent": "Enterprise-Credential-Monitor"
}

# Query breached accounts for the domain
response = requests.get(
    f"https://haveibeenpwned.com/api/v3/breacheddomain/{DOMAIN}",
    headers=headers
)

if response.status_code == 200:
    breaches = response.json()
    for email, breach_list in breaches.items():
        print(f"{email}: {', '.join(breach_list)}")
elif response.status_code == 404:
    print("No breached accounts found for this domain")

Commercial threat intelligence platforms: SpyCloud, Flare, Constella Intelligence, and similar platforms provide broader credential exposure monitoring that includes credentials from non-public breach data, darknet market postings, and stealer malware logs. These platforms go significantly beyond HIBP and are appropriate for organizations where credential exposure is a primary threat (financial services, healthcare, technology, any organization with high-value access credentials).

Microsoft Entra ID Password Protection: Blocks the use of known compromised passwords in your Azure AD tenant — credentials in Microsoft’s breach database can’t be set as user passwords. This is a preventive control rather than a detection control, but it addresses the subset of cases where employees attempt to reuse breached passwords.

What to Do When You Find Exposed Credentials

When credential exposure is identified — whether from HIBP monitoring, a threat intelligence alert, or an active incident — the response sequence is:

  1. Force password reset immediately for all accounts with confirmed exposure. Don’t wait for the user to do it voluntarily — force reset via your identity provider before completing any other steps.
  2. Check for concurrent sessions in your identity provider (Microsoft Entra ID, Okta) for the affected accounts. If an attacker used the credential before you detected the exposure, they may have an active session that persists after a password reset. Revoke all active sessions.
  3. Verify MFA is enforced on all affected accounts. A password reset provides limited protection if MFA isn’t enforced — an attacker with the old credential can’t authenticate, but if MFA was bypassed or not required, the same credential may still provide access via legacy authentication protocols.
  4. Review sign-in logs for affected accounts in the relevant timeframe. Impossible travel, logins from unfamiliar locations or IP ranges, and access to resources the user doesn’t normally access are indicators of credential use by an attacker.
  5. Assess whether the exposed account has privileged access. Admin accounts, service accounts, and accounts with access to sensitive systems require enhanced response — full forensic review of activity since the credential appeared in breach data, not just a password reset.

Preventing Credential Reuse: The Structural Controls

Credential exposure monitoring is a detection and response control. The preventive controls that reduce reuse risk:

  • Phishing-resistant MFA: FIDO2 hardware keys and passkeys are the only forms of MFA that prevent attacker-in-the-middle credential interception. TOTP codes and SMS are better than nothing but are bypassable via real-time phishing proxy toolkits (Evilginx, Muraena). Phishing-resistant MFA for privileged accounts is non-negotiable.
  • Enterprise password manager: Employees who use a password manager for all accounts don’t reuse passwords. Enterprise password manager deployment — 1Password, Bitwarden, or similar — is the single most effective intervention for password reuse behavior.
  • Conditional Access with sign-in risk: Microsoft Entra ID Identity Protection evaluates sign-in risk in real-time based on threat intelligence, including known leaked credentials. High-risk sign-ins can be blocked or stepped up to MFA. This is a complementary detection layer to external credential monitoring.

CyberOne’s exposure management program includes continuous credential exposure monitoring as a component, and our offensive security assessments simulate credential stuffing and password spraying attacks to measure how existing controls perform against actual attacker techniques.