Haunted by Old Credentials: The Ghost Accounts Still Walking Your Network

In the spring of 2021, an attacker logged in to Colonial Pipeline’s network through a VPN profile that Mandiant’s lead investigator described as “no longer being used but had never been disabled.” The profile was a legacy one, and it had no multifactor authentication. Its password, which Colonial’s CEO told the Senate was complex, had turned up in a batch of leaked passwords on the dark web. Ransomware was deployed on May 7, and the company shut down its pipeline operations for nearly a week.

Nobody was using that account. That was the problem, and it was also the reason nobody noticed it being used.

With Halloween arriving this Saturday, the metaphor is almost too convenient: every environment has ghosts. They’re the accounts that belong to people who left years ago, the projects that were wrapped up without anyone closing out their access, the vendors whose contracts ended while their logins didn’t, and the scripts that still run with a key nobody remembers creating. Ghosts don’t appear on org charts or file tickets, and nobody asks whether it was really them when they log in. What follows isn’t really a ghost story. It’s an inventory problem, with unusually well-documented consequences.

Three Kinds of Ghosts

The first kind is the human leftover: former employees, contractors, interns, and people who changed roles but kept all their entitlements from the old role. A 2022 Beyond Identity survey of former employees found that 83% admitted to keeping access to accounts from a previous employer. That’s a vendor-run, self-reported survey, and it’s several years old, but the pattern will be familiar to anyone who has ever run an access review and found a name they didn’t recognize.

The second kind is the third-party leftover. Third-party involvement now touches nearly half of all breaches in the 2026 Verizon DBIR, and a vendor relationship that ends doesn’t automatically end the access it created. Shared logins, vendor VPN accounts, and integrations set up for a project that’s long over tend to outlive the paperwork behind them.

The third kind is growing fastest: non-human identities. Service accounts, API keys, tokens, and automation credentials now outnumber the people in an organization by a wide margin, with ManageEngine’s 2026 identity security outlook reporting machine-to-human ratios anywhere from 100:1 to 500:1. Other vendor research cited by CSO Online paints an uncomfortable picture of how those identities are managed: Entro Security found 97% of non-human identities carry excessive privileges, an estimated 71% aren’t rotated within recommended timeframes, and Veza reported dormant accounts nearly doubling year over year while orphaned identities grew 40%. These are vendor-sourced figures, so the exact numbers are best read as directional, but every source points in the same direction.

Why Attackers Love a Ghost

A credential doesn’t expire just because the person or project behind it did, and that gap between when a credential is created, stolen, and used is where ghosts do their damage.

The 2024 Snowflake customer breaches are the clearest example. Mandiant’s investigation found that at least 79.7% of the accounts the attacker used had prior credential exposure, with the earliest infostealer infection dating back to November 2020, roughly three and a half years before the campaign surfaced. In some cases, the credentials hadn’t been rotated in as long as four years. The accounts didn’t have MFA enabled, and the customer instances had no network allow lists restricting where logins could come from. Around 165 organizations were notified as potentially exposed. A password stolen in 2020 was still working in 2024, because nothing in those environments ever asked whether it should.

The 2026 DBIR adds the other side of the timeline: infostealer events preceded roughly half of ransomware attacks within a 95-day window. Sometimes stolen credentials get used within weeks, and sometimes they sit for years. Either way, the question that decides the outcome is the same: Does the credential still work when someone tries it?

Detection is the other half of the problem. A login from a ghost account uses valid credentials on a real account, so it looks legitimate to most tooling. With no owner to ask and no baseline of normal behavior to compare against, there’s very little to trip an alert.

Why the Ghosts Stick Around

Ghosts persist because no single team owns the full lifecycle. HR knows who left, IT knows what’s in the directory, application owners know which SaaS tools exist, and engineers mint keys on their own schedule. An offboarding checklist that disables the directory account doesn’t necessarily reach the SaaS tool someone signed up for with a work email, the password shared in a spreadsheet, the API key committed to a repository, or the session token that stays valid after a password reset.

Legacy access paths survive for a different reason. The old VPN profile, the pre-SSO portal, and the application nobody wants to touch all stay because turning them off might break something no one can name. That’s how a profile ends up “no longer used” and “never disabled” at the same time.

Laying Them to Rest

Human accounts: offboarding is triggered by the HR event and covers SaaS applications, not just the directory. Sessions and tokens are revoked, not just passwords reset. Contractor and vendor accounts expire by default and must be renewed rather than removed.

Non-human identities: every service account, API key, and token has a named owner and a documented purpose. Anything without an owner gets reviewed and disabled if no one claims it. Rotation is automated wherever possible, and short-lived credentials replace long-lived ones where the platform supports them.

Legacy access paths: MFA covers every inbound route, including those scheduled for retirement. The missing MFA on a legacy profile is the common thread between Colonial Pipeline and the Snowflake incidents, and it’s the cheapest gap on this list to close. Whatever can be retired outright should be.

Detection: a dormancy policy that disables accounts after a set period of inactivity; an alert for any login to a dormant account; and monitoring of the organization’s own credentials in infostealer logs, with rotation as the standard response when one appears.

A Pre-Halloween Séance

Before October 31, it’s worth running three checks: which accounts haven’t had a successful login in 90 days, which accounts belong to someone who no longer works at the organization, and which service accounts, API keys, and tokens have no named owner or haven’t been rotated in the past year. The results are rarely comfortable, which is the point.

The cheapest breach to prevent is the one that depends on an account nobody was using. It’s far better to find your ghosts on your own schedule than to meet them on an attacker’s.

Sources consulted: NHIMG — Colonial Pipeline Attack 2021: One Unused VPN Account, Google Cloud / Mandiant — UNC5537 Targets Snowflake Customer Instances, CSO Online — Why non-human identities are your biggest security blind spot in 2026, Help Net Security — 83% of employees continue accessing old employer’s accounts, Help Net Security — Verizon 2026 DBIR, Tech Insider — Verizon DBIR 2026