The “No-Breach” Breach: How Stealer Logs Lead to Active Directory Incidents

A 2026 Forbes article reported that the previous year’s credential-theft wave exposed 2.86 billion compromised credentials, with infostealers tied to roughly 3.9 million infected machines and 347.5 million stolen logins; business cloud and authentication services accounted for more than 30% of targeted data, while sensitive corporate access points such as Active Directory/ADFS and RDP frequently appeared among compromised services.

Read on Forbes: 2.8 Billion Credentials Stolen As Password Attacks Surge

Executive summary

In recent Active Directory (AD) investigations, attackers often access systems by using valid credentials rather than exploiting vulnerabilities. Typically, there’s no obvious breach or malware; instead, attackers log in through remote entry points such as virtual private networks (VPNs) or cloud portals, blending in as legitimate users (MITRE ATT&CK T1078 – “Valid Accounts”).

Infostealer malware frequently enables this by collecting and distributing saved credentials from infected devices. As a result, compromised AD credentials pose a significant risk and should be treated as an access control issue, regardless of other security measures like MFA.

What’s changed isn’t attacker sophistication but defender blind spots. Infostealer logs turn ordinary passwords into persistent access paths, and in AD, a working password is often enough. That’s why compromised credentials should be treated as an exposure problem, not a policy failure or user mistake.

The “No Breach” breach problem

For years, most people pictured an AD compromise the same way: an exploit, a foothold, malware, lateral movement, privilege escalation. That still happens. But more and more incidents now start with something much less dramatic: a successful login.

This can make these cases frustrating to investigate. From the identity layer’s point of view, the activity looks normal. The username is real. The password is correct. The authentication succeeds. In a hybrid environment full of remote workers, contractors, service accounts, and cloud-connected apps, that can blend in fast.

This shows up clearly in real-world breach data. Verizon’s 2025 DBIR shows that identity abuse still sits at the center of real-world intrusions. Credential abuse remains a leading entry point, and Verizon found that more than half of ransomware victims had domains that appeared in credential dumps.

For AD teams, the first sign of a breach is often not an obvious compromise, but evidence that someone got in with a valid identity. That is also why the rising risk of compromised credentials in AD deserves more attention than another conversation about password complexity rules.

Stealer logs in plain English

The easiest way to think about a stealer log is as a prepackaged access bundle pulled off an infected endpoint.

Stealer logs start with an infected endpoint (often via a malicious download or phishing). The infostealer then exfiltrates data, especially browser-stored usernames/passwords and the surrounding context (login URLs, browsing history, and system details), and packages it into a “log” that’s easy for a buyer to search and use.

Stealer logs are especially dangerous because they expose cleartext credentials that victims often believe are protected, particularly when they use a password manager. Once attackers have a real username and password, they need very little else, and stealer logs make it easy to package and sell that access at scale.

Instead of an attacker having to manually phish your user, guess your VPN portal, and figure out how your identity stack works, the infected device often hands them all the requisite information on a platter. The log tells them which portals the user visits, which credentials are stored, and which services are worth trying first.

Stealer logs are traded at scale in established criminal markets. For example, an FBI and CISA advisory on LummaC2 cited thousands of listings selling stealer logs over a short period. For AD admins, the takeaway is simple: if corporate passwords are already circulating in these logs, auditing for compromised passwords is no longer optional.

For AD admins, the key point is this: infostealers are not just a malware problem. They are an identity problem.

Why saved browser data affects AD security

Browsers now hold a surprising amount of enterprise identity material: Microsoft 365, SSO portals, VPN gateways, VDI environments, internal web apps, help desk tools, and admin consoles. In many organizations, those identities are AD-backed or AD-synced. And password reuse often ties them to the same underlying credential. So when a stealer pulls a browser-saved password, it may be enough to open remote access and, from there, an AD-connected foothold.

That browser-to-AD connection is why infostealers can have outsized impact in hybrid environments. If you want to quantify your exposure, Enzoic’s AD Lite Password Auditor Report provides a useful snapshot of what compromised-password risk can look like across organizations.

For AD admins, the takeaway is straightforward: browser credential theft should be treated as a directory risk, not a side issue.

What is inside a stealer log, and why it works

A stealer log is dangerous because it gives attackers more than a username and password. It gives them enough context to move quickly.

That can include saved enterprise credentials, login URLs, browsing history, system information, and sometimes session-related artifacts. The value is the context: it reduces guesswork and helps an attacker move straight to the most likely entry points, like VPN, SSO, Microsoft 365, and other exposed portals, without having to map your environment first.

Still, for Active Directory teams, the most important part of the log is usually the most mundane: the password.

That is the part that keeps working after the initial confusion dies down. It is the part that can be reused across multiple access paths and turn a compromised endpoint into a compromised VPN login, then a compromised cloud identity, then an AD-connected foothold. That is also why discussions about credential stuffing and password spraying are so relevant to AD teams: the attack changes shape, but the dependency stays the same.

Token theft and session abuse are real, and they matter. But for most AD admins, the more actionable issue is simpler. If a password from a stealer log still works, the attacker has a durable path back into the environment. 

How stealer logs become Active Directory incidents

The path from infostealer infection to AD incident is usually pretty straightforward.

A user endpoint gets infected. The infostealer harvests credentials and context. The log is sold or traded. The buyer tests those credentials anywhere they might work, which usually means the obvious remote entry points first: VPN, VDI, SSO, Microsoft 365, and other internet-facing portals.

If one of those doors opens into an AD-connected environment, the blast radius starts to grow.

This is where Active Directory changes the stakes. AD is the trust hub for users, groups, service accounts, admin roles, and permissions across large parts of the environment. Once an attacker lands with a valid credential, AD can magnify the impact through lateral movement, privilege discovery, access to higher-value accounts, and eventually domain-wide risk. You reduce blast radius by removing exposed credentials before they are abused.

A simple model for AD admins:
In an identity-first breach, a password that still authenticates is part of your external attack surface.
Active Directory can’t tell whether that password was stolen by phishing, malware, or reuse. It only sees “valid.”

That is why these incidents can look so strange in the early stages. They often start with something as ordinary as a saved browser credential. But because that credential is tied to real enterprise access, the result can be anything but ordinary.

What begins as “a user password was exposed” can quickly become “an attacker got into the environment with a valid account.”

Why “we have MFA” does not close the loop

MFA raises the cost of an attack, but it doesn’t address the question that matters most in a stealer-log scenario: whether the password is already in the attacker’s hands. This gap is where many AD teams need to focus their attention.

In the real world, MFA coverage is rarely perfect. Exceptions for legacy protocols, location, device trust, remembered sessions, or Conditional Access rules can create gaps attackers can target, especially in hybrid identity environments. And infostealer logs may include more than passwords: stolen session cookies and browser artifacts can help attackers find a path where MFA is reduced, deferred, or never triggered.

More importantly, MFA is a control around the authentication flow. It doesn’t tell you whether the password itself has already been exposed in stealer data or breach data. If a compromised password still works in AD, you still have an access problem. That is why stealer logs matter on both sides of the story: they can explain the “how did MFA fail?” moment, and they can confirm the password is already known to attackers. That is also why the NIST password guidelines, and the newer NIST 800-63B Rev. 4 updates, emphasize screening out passwords attackers already know, not just enforcing complexity.

That is the mindset shift AD admins should care about. Good MFA helps, but it does not replace compromised-password protection. A password can meet your policy and still be the exact credential that shows up in breach data, infostealer data, or attacker tooling. 

What AD admins should do now

Securing AD doesn’t have to mean a massive identity overhaul. Use this checklist to reduce the risk of stealer-log-driven incidents:

1. Audit what is already exposed (including compromised and reused passwords).
2. Prioritize the accounts that expand blast radius (privileged and delegated roles first).
3. Prevent compromised passwords from coming back (block at set/reset, then monitor continuously).

Audit what is already exposed

• Quantify how many accounts are using compromised passwords (not just weak ones).
• Identify reused passwords (especially across multiple users or admin vs. standard accounts).
• Flag accounts with blank passwords, password never expires, or other high-risk settings.
• Find stale accounts (inactive users, old contractors, legacy service accounts) that still authenticate.

Prioritize the accounts that expand blast radius

• Start with Tier 0 / privileged identities (Domain Admins, Enterprise Admins, schema admins, etc.).
• Next, focus on delegated admin roles and helpdesk accounts that can reset passwords or modify group membership.
• Review service accounts and app identities with broad rights or interactive sign-in capability.
• Then prioritize accounts with access to sensitive systems/data (finance, HR, production, backups, security tools).

Prevent compromised passwords from coming back

• Block known-compromised passwords at set and reset time (don’t wait for the next rotation).
• Require resets for accounts already using compromised or reused passwords, starting with privileged tiers.
• Monitor continuously as new exposures appear (today’s “safe” password can become tomorrow’s stealer-log password).
• Reduce where high-value credentials are exposed: limit interactive sign-in for service accounts and tighten privileged credential use.

For this threat, the easiest choke point is the compromised password that still works. That is why Enzoic’s core value is so straightforward: find those passwords, block them, and keep checking them continuously.

Once you treat exposed passwords as an access problem and not a one-time clean-up task, the tooling question becomes much clearer.

Where Enzoic for Active Directory fits

Enzoic for Active Directory is designed to address that specific gap: detecting and blocking passwords attackers already have.

Enzoic isn’t an identity provider, an MFA platform, or a session-control layer. It solves a different problem, one that stealer logs make painfully relevant: passwords that attackers already have.

This matters because stealer-log-driven incidents depend on valid credentials. If a password appears in breach data or infostealer data and still works in Active Directory, it can be used for valid-account abuse. Remove that password from the environment, and you remove one of the easiest paths to persistence and re-entry.

Enzoic for Active Directory is built to identify, monitor, and remediate unsafe passwords in AD. It helps organizations find compromised passwords already in use, block compromised passwords from being set again, and keep checking over time as new password exposures appear.

For teams that want a fast starting point, Enzoic AD Lite is the easy first step. It gives you a quick audit of compromised-password exposure in the domain so you can quantify the problem before the next “no-breach” breach turns into a real incident. It also does that in a way that is practical for enterprise teams, using partial-hash matching so full hashes do not leave your environment.

And that brings the whole conversation back to the main point. Stealer logs are often built from browser data, but the risk does not stay in the browser. In most environments, those same credentials open the door to VPN, cloud identity, and Active Directory.

At first glance, nothing may seem wrong. The vulnerability may not have been exploited yet, and there may be no obvious breach signal at all.

But if those credentials still work, an attacker may not need anything else.

Run Enzoic AD Liteto see how many compromised passwords exist in your domain right now, then move to Enzoic for Active Directory for continuous monitoring, enforcement, and remediation before stealer-log credentials get used against your VPN, cloud identity, and Active Directory.