Credential Compromise

What Is Credential Compromise?

Credential compromise means a secret that proves identity has been disclosed to, or used by, someone who should not have it. The secret can be a password, a session cookie, an API key, a private key or the seed behind an authenticator app. NIST’s glossary defines a compromise as “the unauthorized disclosure, modification, substitution, or use of sensitive data”, and it names keys as an example.

The secrets in that state are called compromised credentials. A compromised password, cookie or key works for whoever holds it until it is changed, expires or is revoked. The sign-in system checks the secret, not the person, so its use looks like normal work.

A compromise does not need a breach of your own systems. The password may have been typed into a fake page, copied from an infected home laptop or reused from a site that was breached years ago. Microsoft’s password spray investigation playbook separates two stages:

• Password compromise: the attacker has the password, but MFA or another control stops the sign-in.
• Account compromise: the attacker has the password and has signed in.

Credential compromise covers both stages. Treat the first one as an early warning, because the attacker’s next move is to get past the second factor.

How Is It Different From Leaked Credentials and Account Takeover?

Several terms describe the same chain of events from different points. The table puts them in order, from the moment a secret is taken to the moment an attacker controls the account.

Theft, leaks, stealer logs and combolists are ways a credential becomes compromised. Account takeover is what often follows. Some definitions call a credential compromised only after an attacker has used it.

NIST’s wording also covers a disclosure that “may have occurred”. That is the safer reading for a defender, because you can rarely prove that a leaked password was never tried.

How Do Credentials Get Compromised?

Most compromised credentials come from a short list of routes. MITRE ATT&CK documents each one as a technique, which helps when you map an alert to a detection or a fix.

Two public cases show how ordinary these routes are. In January 2024 Microsoft said Midnight Blizzard used password spraying to compromise “a legacy, non-production test tenant account that did not have multifactor authentication (MFA) enabled”. Microsoft attributes the attack to this Russian state-sponsored actor, which MITRE lists under APT29.

The second case is Mandiant’s 2024 investigation of data theft from Snowflake customer instances. The stolen customer credentials were “primarily obtained from multiple infostealer malware campaigns” on systems that Snowflake did not own. Our stealer logs entry walks through that case step by step.

Why Does a Compromised Credential Matter So Much?

A valid login does not look like an attack. In its Valid Accounts technique (T1078), MITRE notes that adversaries “may choose not to use malware or tools” with the access a credential gives. They do this “to make it harder to detect their presence”.

Compromised credentials also stay useful for a long time. In the Snowflake customer case, Mandiant found credentials that were “still valid, in some cases years after they were stolen”. The oldest infostealer infection it tied to a used credential dated back to November 2020. The affected accounts had no MFA, and in many cases the credentials had not been rotated for as long as four years.

The share of breaches that start this way is still large, even as other routes grow. Verizon’s 2026 Data Breach Investigations Report puts credential abuse at 13% of breaches with a known initial access vector. It was the leading vector in the previous report; exploitation of vulnerabilities now leads at 31%.

Fixes are slow when the gap sits with a supplier. The same report found that only 23% of third-party organizations fully fixed missing or improperly secured MFA on their cloud accounts. For weak passwords and permission misconfigurations, resolving half of all findings took almost eight months.

What Can an Attacker Do With a Compromised Credential?

The login is rarely the goal. It is the way in, and what follows depends on what the account can reach.

• Steal data and extort. Mandiant describes the Snowflake customer campaign as aimed at “data theft and extortion”. About 165 potentially exposed organizations were notified.
• Read mail. Midnight Blizzard created malicious OAuth applications after breaking into the test account, and used them to “target Microsoft corporate email accounts”.
• Move further and stay. MITRE says valid accounts serve “Initial Access, Persistence, Privilege Escalation, or Defense Evasion”.
• Resell the access. In our Initial Access Offers chapter, most offers under Blackhole’s “Initial Access Selling” label were footholds on websites and servers.

What Does Brandefense Blackhole Data Show About Stolen Logins?

Our Cybercrime Report 2026 read posts that Brandefense Blackhole, our cybercrime database, collected from 1 January to 27 October 2026. These are counts of collected posts, not of victims or offers. Four findings change how a defender should read a credential alert.

• A “Botnet Log” label is not one product. In 160 hand-read posts under Blackhole’s Botnet Log label, bank-account listings and requests made up 23.8% and game-account lots 21.3%, a moderate-confidence reading. Strict stealer-log clouds were only 6.3%. All three are weighted estimates.
• Buyers want the second factor and the session. Of 59 hand-coded buyer rate sheets, 47.5% asked for a 2FA-secret column and 57.6% for a cookie column. A password reset alone touches neither.
• “Fresh” and “valid” are sales words. Of 57 combolist texts that were reposted, 49% said fresh and 32% said valid. In 2,661 posts whose text we saw only once, the shares were 26% and 14%. The report reads this as copied adverts, not as proof that the logins work.
• A malware name is a label, not a source. Of 160 posts naming Lumma, RedLine, Vidar or StealC, only 6.2% offered that malware. The report’s advice is to reset credentials and revoke sessions without waiting to confirm the family.

Two rules follow from the chapters’ advice for defenders. Act on a verified match of your own accounts, and count exposure by credential or session, not by post. Method and limits are in the stolen accounts and combolists chapter and the infostealers chapter.

What Survives a Password Reset?

A new password closes one door. An attacker who had the account for even a short time can open others, and these stay open after the reset. Check each one below; each is also a sign that the credential was used.

• Session cookies and tokens. MITRE says signing in with stolen session cookies “bypasses some multi-factor authentication protocols since the session is already authenticated” (T1550.004). In Microsoft Entra ID, access tokens last one hour by default. Entra cannot revoke a session token that an app issued itself.
• An MFA device the attacker added. MITRE records APT29 enrolling its own device in MFA after guessing the password of a dormant account. It also records Scattered Spider registering MFA devices to keep VPN access (T1098.005).
• Mailbox rules. Per MITRE, Scattered Spider created inbox rules on security staff accounts that deleted emails from security products (T1564.008, part of Hide Artifacts). Rules that forward or hide mail keep working after a password change.
• OAuth apps and consents. Microsoft says misuse of OAuth “enables threat actors to maintain access to applications, even if they lose access to the initially compromised account”. Midnight Blizzard used this method against Microsoft.
• The infected device. If an infostealer was the source, a new password typed on the same machine can be stolen again. Clean or rebuild the device first, as our stealer logs entry explains.
• Copies of a key. GitHub says a leaked secret must be revoked or rotated as the first step. Rewriting history does not reach forks or other people’s clones.

What Are the Warning Signs of Compromised Credentials?

Signals come from two directions: outside sources that show your data for sale, and your own logs. Outside signals usually arrive first.

• Your domain, a staff email or a customer login appears in a stealer log, combolist or breach dump that a monitoring service reports.
• A vendor or researcher tells you. Mandiant began notifying potential victims of the Snowflake customer campaign on 22 May 2024 through its Victim Notification Program.

Inside your logs, Microsoft’s password spray playbook and Mandiant’s findings point to these signs:

• A sign-in from an unfamiliar location, or MFA prompts the user did not start.
• A correct password followed by a failed MFA step, which is Microsoft’s “password compromise” stage.
• A new device, operating system or IP address on the account.
• Sign-ins from commercial VPN services. Mandiant saw the Snowflake campaign connect mainly from Mullvad and Private Internet Access addresses.
• Many failed sign-ins across many accounts from one source, often over legacy protocols. Microsoft says most password spray attacks use legacy authentication.

What Should You Do in the First 24 Hours?

NIST SP 800-63B says verifiers “SHALL force a change if there is evidence that the authenticator has been compromised”. A leak alert, a stealer log match or a suspicious sign-in is that evidence. The clock starts when the alert arrives, but the investigation starts at the exposure date.

If the account shows a sign-in you cannot explain or an attacker session that is still open, contain first. Disable the account and revoke its sessions, then come back to step 1.

1. Hour 0 to 1: confirm and scope. Name the exact credential, the systems it opens and the date it was exposed. Check whether it still works: was the password changed after that date, or the key rotated? Save the alert and the logs before you change anything.
2. Hour 1: find the source. A stealer log points to an infected device and a combolist to reuse. Phishing points to a user who clicked, and a commit to a key in code. The source decides what you clean next.
3. Hours 1 to 4: contain. Reset the password, revoke sessions and refresh tokens, and remove MFA methods the user does not recognize. Disable or rotate keys. If an infostealer was involved, isolate the device before the user signs in again.
4. Hours 4 to 12: investigate. Read sign-in logs from the exposure date, not only from today. Check mailbox rules, forwarding, OAuth apps and new accounts. List what data the account opened or exported.
5. Hours 12 to 24: recover and harden. Put the old password on your blocklist and require MFA, phishing-resistant where you can. Bring in legal and privacy owners if personal data was reached, since duties depend on sector and country. Write down the timeline while it is fresh.

On premises, Microsoft advises resetting an Active Directory password twice to reduce the risk of pass-the-hash. For a single alert, our shorter leaked credentials response checklist covers the first steps. Larger cases belong in your incident response plan.

How Do You Revoke Each Type of Credential?

Each kind of secret has its own off switch. The table lists the first move and the trap to avoid for the most common types.

The commands below follow Microsoft’s revoke access guide and the AWS CLI reference. Replace the example user and key, and run them only on accounts you are responsible for.

# Microsoft Entra ID (Microsoft Graph PowerShell): block sign-in, revoke refresh tokens
$User = Get-MgUser -Search UserPrincipalName:'jdoe@example.com' -ConsistencyLevel eventual
Update-MgUser -UserId $User.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $User.Id

# On-premises Active Directory: disable first, then reset the password twice
Disable-ADAccount -Identity jdoe

# AWS: switch off a leaked access key (AKIAIOSFODNN7EXAMPLE is AWS's own sample ID)
aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name jdoe

How Can You Check Whether a Password Is Already Exposed?

NIST requires new passwords to be checked against a blocklist of commonly used, expected or compromised values. Its examples include “passwords obtained from previous breach corpuses”. The free Pwned Passwords API lets you run that check without sending the password itself.

You send only the first five characters of the password’s SHA-1 hash. The service returns the rest of every hash in its data set that starts with them, each with a count. We ran this check for a weak sample password on 10 November 2026:

# macOS uses shasum; on Linux use sha1sum
HASH=$(printf '%s' 'P@ssw0rd' | shasum -a 1 | awk '{print toupper($1)}')
curl -s https://api.pwnedpasswords.com/range/${HASH:0:5} | grep "${HASH:5}"

# Output on 10 Nov 2026
2DC183F740EE76F27B78EB39C8AD972A757:6421042

The number after the colon is how often that password appears in the data set: more than 6.4 million times. Build checks like this into your own password change flow rather than testing staff passwords by hand. For your company domain, see breach and credential monitoring; the free Domain Scanner on Atlas grades a domain, leaked credentials included.

How Do You Prevent Credential Compromise?

• Use phishing-resistant MFA, starting with admins and remote access. CISA calls phishing-resistant MFA “the gold standard” and names FIDO/WebAuthn and PKI-based methods. Passkeys are built on FIDO standards. Any MFA is still better than none, CISA adds.
• Change passwords on evidence, not on a schedule. NIST says verifiers “SHALL NOT require subscribers to change passwords periodically”. It requires a change when there is evidence of compromise.
• Block known breached passwords at every password change, as shown above.
• Use a unique password for every account, kept in a password manager. Reuse is what turns another site’s breach into your compromise. NIST requires verifiers to allow password managers and autofill, and says they make stronger passwords more likely.
• Give each account only the access it needs, and audit privileged and dormant accounts. MITRE advises routine audits of accounts and their permission levels, so one stolen credential cannot open wide access. It also asks you to check that default accounts are off and to remove accounts nobody needs.
• Teach staff to spot phishing and to report MFA prompts they did not start. MITRE lists user training against phishing emails. It also asks users to accept only valid push notifications and to report the rest.
• Prefer short-lived credentials. AWS recommends temporary credentials, such as IAM roles, over long-term access keys. Service accounts and keys are non-human identities and need owners too.
• Keep secrets out of code. GitHub suggests a pre-commit hook with a tool such as git-secrets or gitleaks.
• Separate work and personal devices. Mandiant found that several Snowflake-related infections began on contractor systems also used for gaming and pirated software.
• Limit where sensitive systems accept sign-ins. Mandiant advised limiting traffic to trusted locations for the most valuable systems.
• Watch criminal sources for your domain, so you hear about a compromise before an attacker uses it. Our leaked credential monitoring use case shows how teams set this up.

Brandefense Dark Web Monitoring shows when your company’s passwords, data or name appear on criminal forums and markets, and alerts within 24 hours after a breach on average.