Ransomware Doesn't Break In. It Logs In

The security team gets the alert at 2:14 AM. File servers are encrypting. Backups are unreachable. The ransom note is already sitting on endpoints across three regions.

Forensics spends the next 72 hours working backwards. What they find isn't a zero-day. It isn't a firewall bypass. It's a helpdesk account — active, MFA-exempt, with local admin rights on every workstation in the environment — that authenticated to the VPN six days ago from an IP in Eastern Europe.

No one flagged it. The account belonged to a contractor who finished the engagement eight months prior. No one deprovisioned it. No one audited it. (This is one of the four categories of identity debt most enterprises are carrying right now — we broke it down in Issue 1: The Debt Your Security Team Isn't Tracking)

The attacker didn't defeat the perimeter. They found a door that was still open and walked through it. From there, an over-privileged service account reached the domain controllers. Four hours later, ransomware was deploying through Group Policy.

This is how it happens. Not through sophisticated tradecraft. Through IAM failures sitting quietly in the environment for months.

It's also not hypothetical. In February 2024, ALPHV/BlackCat used a single compromised credential — no MFA on a Citrix remote access portal — to breach Change Healthcare. No zero-day. No perimeter defeat. Just a login that should never have worked. UnitedHealth Group paid $22 million in ransom. Losses across the US healthcare system exceeded $870 million. The entire claims processing infrastructure went dark for weeks, delaying payments to hospitals and providers nationwide.

The credential that opened the door wasn't sophisticated. It was just unprotected.

Ransomware operators have a playbook. It isn't subtle.

Initial access is almost always a stolen or abused credential — phishing, credential stuffing, an exposed RDP endpoint with a recycled password. The attacker doesn't exploit a flaw in your application code. They authenticate as a user.

Lateral movement comes next. The account they land on is rarely the one they need. So they pivot — using whatever access that account has to discover what's reachable. Service accounts are the primary vehicle. Most enterprise environments have hundreds of them, many with local admin rights, none with meaningful scope constraints. Over-privileged service accounts are one of the most common findings when organizations finally audit their identity debt.

Domain dominance is the objective. The target is Active Directory or its cloud equivalent. Once an attacker has a path to a domain controller, they can create persistence, extract credential hashes, and pre-stage encryption tools across the environment before triggering anything visible.

Impact follows in that order: encryption, backup deletion, data exfiltration — usually across a window measured in hours once the attacker decides to execute.

The pattern holds across industries, across attack groups, across ransomware families. What changes is the initial credential. What never changes: somewhere in the identity infrastructure, there was an account with more access than it needed, that lived longer than it should have.

Three forces accelerated this problem in the last 18 months.

Identity infrastructure expanded without proportional governance. Cloud workloads, SaaS proliferation, and hybrid work created more authentication surfaces — more accounts, more service principals, more OAuth integrations — managed by the same teams, with the same tooling, against a much larger target.

Attackers industrialized initial access. Credential markets now sell authenticated session tokens, not just passwords. An attacker can purchase an active enterprise SSO session for under $50. MFA doesn't stop this — the session is already past authentication. We talked about it in our Issue 4: Your Token Budget Just Became Your Attack Surface.

AI tooling created a new category of unmanaged credential. Every AI coding assistant, productivity agent, and automation workflow carries delegated credentials. Most have no revocation mechanism. Most have no expiration policy. Most live in environments where no one has mapped what they can reach. We've covered three angles of this problem in recent issues — the permission scope problem in Issue 2: Your Autonomous Agents Are Running With God Mode Permissions and Issue 3: Your AI Agent Has More Access Than Your Domain Admin, the approved-tool-as-wiretap problem in Issue 6: The Free AI Tool You Installed Last Week Is Robbing You Blind and how AI coding assistants expose secrets they were never meant to touch in Issue 7: Your AI Coding Assistant Just Cloned Your Entire Repository. You Told It To.

The attack surface isn't your perimeter. It's your identity plane.

The most expensive ransomware recovery I've seen didn't start with a phishing email. It started with a service account that was created during a migration project three years prior, never decommissioned, and had local admin rights across 400 servers "temporarily" — because removing it might break something and nobody wanted to own that risk.
That's the real pattern. Not sophistication. Risk aversion dressed up as IT debt.
The account wasn't a secret. It showed up in every audit. It just kept getting deferred because decommissioning it required coordination between three teams, and none of them owned the outcome.
Ransomware doesn't need a clever entry point. It needs one account nobody wanted to deal with. In every environment I've assessed, there are dozens of them. Start there — not with your firewall.

This post on ramsonware was a request from one of the members from Identity Decoded and a very good friend Marc Tedeschi. Thank you!

What's the identity gap you've seen ransomware walk through most often in production? Reply and tell me — it belongs in this newsletter.

Identity Decoded publishes every week at identity-decoded.com