You can spend millions on next-gen firewalls. Deploy AI-powered threat detection. Build a SOC that never sleeps. And an attacker will still walk in through the front door using credentials they bought for $10 on a dark web market.

Credential compromise isn’t a security gap. It’s the security gap. In over 80% of breaches we investigate, credentials play a starring role—either as the initial access vector or the mechanism that turns a foothold into full domain compromise.

This isn’t a technology problem with a technology solution. It’s a systemic failure in how organizations think about identity, and fixing it requires confronting uncomfortable realities about how credentials are actually created, shared, stored, and stolen.

The Data Is Brutal

Let’s establish scope before we go further.

According to Verizon’s Data Breach Investigations Report, stolen credentials are the top attack vector year after year. Not vulnerabilities. Not zero-days. Not sophisticated malware. Credentials.

IBM’s Cost of a Data Breach report finds that credential-related breaches take the longest to identify—an average of 250+ days compared to under 200 for other attack types. Attackers with valid credentials don’t trigger the same alerts as attackers with exploits.

Our own data from dozens of penetration tests tells a consistent story: when we attempt credential-based attacks, we succeed more than 70% of the time. Password reuse, weak passwords, default credentials, credentials in code repositories—something almost always works.

These aren’t edge cases or particularly vulnerable organizations. This is the baseline state of credential security across industries.

How Credentials Get Compromised: The Attack Chain

Understanding the threat requires understanding specific attack patterns, not just “credentials get stolen.”

Pattern 1: Credential Stuffing

Billions of credentials are available from previous breaches. LinkedIn, Adobe, Dropbox, Marriott—the list is endless. Attackers collect these dumps, extract email/password pairs, and systematically try them against other services.

The math is simple. If 2% of your users reuse passwords from breached sites, and you have 10,000 users, 200 accounts are immediately vulnerable. No hacking required—just a login attempt with known credentials.

Credential stuffing is automated at scale. Services exist specifically to “test” credential lists against target sites, rotating through residential proxies to avoid rate limiting. What used to require technical skill is now a commodity service.

The defense isn’t just “don’t reuse passwords” (though that helps). It’s detecting and blocking stuffing attempts through rate limiting, anomaly detection, and monitoring for login patterns that indicate automated attacks.

Pattern 2: Phishing for Credentials

Classic phishing remains devastating. An email impersonating IT, a fake password reset, a cloned login page—and the user hands over their credentials directly to the attacker.

Modern phishing doesn’t look like the Nigerian prince emails of 2005. Targeted spearphishing uses information scraped from LinkedIn and company websites to craft believable messages. Adversary-in-the-middle (AitM) attacks can even capture MFA tokens in real-time by proxying the actual login page.

One phishing kit we analyzed could be deployed in under 30 minutes, automatically generated site-specific login pages, and captured both passwords and session cookies. The attacker investment was minimal; the success rate was high enough to make it worthwhile.

The hard truth: if an attacker sends enough well-crafted phishing emails, someone will click. User training helps but doesn’t eliminate the risk. The question is whether you have controls that limit damage when—not if—someone enters credentials into a fake site.

Pattern 3: Infostealers

Malware designed specifically to harvest credentials is now a major industry. Infostealers like Raccoon, Vidar, and RedLine target browser-saved passwords, session cookies, and authentication tokens.

These aren’t sophisticated state-sponsored tools. They’re commodity malware available for rent on criminal forums, often distributed through fake software downloads, malicious ads, or cracked application packages.

When a user is infected—often on a personal device that accesses work applications—the infostealer exfiltrates everything. Browser passwords for every saved site. Active session cookies that bypass MFA. Saved credit cards. Cryptocurrency wallets. All uploaded to the attacker’s infrastructure automatically.

Infostealer logs are then sold or traded, searchable by domain. “Show me all credentials for @company.com” returns harvested credentials from infected users, often within days of capture.

Pattern 4: Internal Exposure

Not all credential compromise requires external attackers. Credentials leak internally all the time:

• Hardcoded in source code and accidentally committed to repositories
• Stored in shared drives, Confluence pages, or team wikis
• Sent via email or Slack and forgotten
• Saved in plaintext configuration files
• Written on sticky notes or whiteboards
• Shared between team members “just this once”

In one assessment, we found domain admin credentials in a Git repository, AWS keys in a public Confluence space, and the CEO’s password written on a Post-it note visible through their office window.

Internal exposure doesn’t require malice. It happens through convenience, institutional knowledge that was never documented securely, and the natural tendency to share access rather than solve underlying permission problems.

Pattern 5: Lateral Movement via Credential Harvesting

Once an attacker has initial access—through any vector—harvesting additional credentials is priority one.

On Windows networks, tools like Mimikatz extract passwords and hashes from memory. Pass-the-hash attacks use extracted credential hashes without needing the plaintext password. Kerberoasting extracts service account credentials that can be cracked offline.

On any system, attackers search for credentials stored in files, environment variables, browser storage, and memory. Cloud credentials are particularly valuable—an AWS key found on a compromised workstation often provides more access than the workstation itself.

The typical pattern: compromise one user, harvest credentials, move laterally to a higher-privilege account, harvest more credentials, repeat until domain admin or equivalent. Each hop uses valid credentials, making detection difficult.

Why “Use a Password Manager” Isn’t Enough

The standard advice is “use a password manager.” This is correct but incomplete.

Password managers solve password reuse and weak passwords for credentials they manage. They do nothing about:

Credentials users don’t put in the manager. That legacy system with a memorable password nobody bothered to save. The personal account used for work tasks. The “temporary” password that’s been the same for three years.

Session tokens and cookies. Infostealers don’t need passwords when they can steal active sessions. A captured cookie authenticates the attacker directly, bypassing both password and MFA.

Credentials stored in code and configuration. Developers store secrets in environment variables, config files, and sometimes directly in source code. These aren’t in anyone’s password manager.

Shared service accounts. The database admin password that’s been the same since 2018, known by everyone who’s ever worked on that system, never rotated because “it would break things.”

The password manager itself. If the master password is weak or phished, everything is compromised at once. If the manager syncs to a compromised device, infostealers harvest the vault.

Password managers are a necessary control, not a sufficient one. Treating them as a complete solution leaves massive gaps.

The Credential Attack Surface You Don’t See

Most organizations dramatically underestimate their credential exposure.

Run this exercise: list every system, service, and application in your environment. For each, identify:

• How many accounts exist?
• What password policies apply?
• When were credentials last rotated?
• Where are credentials stored?
• Who has access to those stored credentials?
• How would you know if credentials were compromised?

Most organizations can’t answer these questions for even half their environment. The answers for the other half are “unknown,” which means “unmanaged.”

Unmanaged credentials are compromised credentials waiting to be discovered. Either you find them first (through assessment and inventory) or attackers do (through reconnaissance and exploitation).

What Actually Reduces Risk

Real credential security requires multiple layers:

Minimize credential existence. The best credential is one that doesn’t exist. Wherever possible, replace passwords with certificate-based authentication, SAML/SSO integration, or short-lived tokens. Every password that doesn’t exist can’t be compromised.

Assume compromise and limit blast radius. Segmentation, least-privilege access, and just-in-time provisioning mean that compromised credentials can’t go everywhere. An attacker who captures a user’s credentials should not be able to become domain admin.

Monitor for credential abuse. Impossible travel, access from new devices, privilege escalation attempts, failed authentication spikes—these signals indicate credential compromise. Detection won’t prevent initial access but limits dwell time.

Regularly assess exposure. Scan for your organization’s credentials in breach databases. Check code repositories for secrets. Enumerate service accounts and their privilege levels. Know what’s exposed before attackers do.

Make secure behavior easy. If using a password manager is harder than writing passwords down, people will write passwords down. If SSO isn’t available for a critical application, people will create weak passwords. Remove friction from secure practices.

The next article in this series covers the implementation roadmap—specific tools, processes, and timelines for organizations ready to actually solve this problem rather than accept it.