Ghost Credentials Expose Cloud Systems to Hidden Identity Risks

# The Credentials That Never Die: How Ghost Identities Are Quietly Owning Cloud Infrastructure

Every company has a graveyard it doesn't know about.

Somewhere in your AWS account, an IAM user created in 2021 for a contractor who left eight months later still has AdministratorAccess. In your Azure tenant, a service principal tied to a decommissioned CI pipeline still holds write access to production secrets. In GCP, an API key scoped to an app that was sunset two years ago keeps rotating in a config file nobody's opened since the team that built it disbanded.

These are ghost credentials — and unlike the humans who created them, they don't age out, call in sick, or get offboarded. They just wait.

## What Makes a Credential a Ghost

The term sounds dramatic, but the mechanics are mundane. Ghost credentials emerge from ordinary development work: a dev needs quick access to test a feature, a vendor integration requires a dedicated service account, a short-term automation project gets a token with enough permissions to actually work. The task finishes. The project ships. The contractor's badge gets deactivated. Nobody touches the cloud console entry.

The result is an identity that looks legitimate to every automated check — because it *is* legitimate. It was created by a real person for a real purpose. The access policies are intact. The permissions are valid. The logs will show activity if someone uses it. From a cloud provider's perspective, nothing is broken.

That's precisely what makes ghost credentials so dangerous. They don't trigger anomaly detection that keys on obviously malicious behavior. They often carry elevated permissions from when they were provisioned — because at the time, those permissions were justified.

## How Attackers Find and Use Them

Credential hunting has become systematic. Threat actors don't need to compromise your perimeter if they can find your secrets in publicly exposed repositories, leaked config files, or improperly secured object storage. Tools like TruffleHog, GitLeaks, and cloud-native scanning services have commoditized this — and so have the attackers.

Once a ghost credential is found, the playbook is straightforward:

The lateral movement phase is where ghost credentials shine for attackers. A dormant IAM user doesn't have MFA requirements that would block an automated login. There's no behavioral baseline to violate. SIEM alerts tuned to "first login from new geography" don't fire if the account hasn't been used in a year — some organizations suppress alerts for accounts with no recent activity entirely, treating them as noise.

## Why Cloud Infrastructure Makes This Catastrophically Worse

On-prem, credential sprawl was bad. In cloud, it scales exponentially.

Modern cloud infrastructure is built for ephemeral services and rapid iteration. Developers spin up new environments, create service accounts, generate API keys, and integrate with managed services dozens of times per sprint. Cloud providers make credential creation frictionless by design — that's a feature, not a bug. But credential *lifecycle management* has never kept pace with credential *creation*.

AWS alone has IAM users, roles, access keys, instance profiles, and OIDC federation to manage. Azure adds app registrations, managed identities, service principals, and legacy authentication credentials. GCP has service accounts, JSON key files, and OAuth clients. Each has its own console, its own audit trail, and its own conventions for what "active" means.

The result: organizations lose track. Enterprise environments with hundreds of accounts and thousands of service principals accumulate orphaned identities faster than any manual process can catch them. Security teams that do run credential audits often find ghost accounts representing 20-30% of their total identity footprint — and those are the teams that run credential audits.

## The Signals Hiding in Your Logs

The frustrating thing is that ghost credentials leave evidence — it's just evidence most teams aren't instrumented to catch.

AWS CloudTrail will show when credentials were last used. GCP provides serviceAccounts.list with oauth2ClientId metadata. Azure's sign-in logs capture service principal activity. The data exists. The problem is that nobody runs the query.

GetLastUsedAccessKey in AWS is a single API call that returns exactly when a key was last used. A script that cross-references IAM users against HR offboarding records, or that flags any access key unused for 90 days, is not technically complex. It's just not being run.

---

## HackWire Analysis

Ghost credentials aren't a new vulnerability class — they're a consequence of how organizations have chosen to manage identity, which is to say, they haven't really managed it at all.

The pattern here tracks closely with what we saw in the 2023 CircleCI breach, where stolen session tokens from developer machines cascaded into customer infrastructure access. It echoes the Uber breach mechanics, where hardcoded credentials in a private repository gave an attacker administrative AWS access. It's present in a significant chunk of cloud breach postmortems if you read past the sanitized press releases: a credential that shouldn't have existed, or shouldn't have still worked, opened the door.

What's different now is the scale of exposure. Cloud-native development practices have made credential creation so cheap that organizations genuinely don't know how many active identities they have. This isn't negligence in the traditional sense — it's an organizational capability gap. No one person was responsible for the ghost credential. No one team owns the audit. The cloud console isn't sending anyone a monthly reminder that a contractor's IAM user from three years ago is still sitting there with S3 full access.

The industries most exposed are the ones that moved fastest to cloud without building identity governance foundations first: fintech, healthtech, and mid-market SaaS companies that scaled engineering teams rapidly between 2020 and 2023. These organizations built a lot of infrastructure quickly. They didn't build the operational processes to govern it.

For defenders, the immediate priority is an access key age report — any key older than 90 days without documented, active use should be disabled on a provisional basis. That's not a six-month project. It's an afternoon. The harder work is building credential lifecycle into offboarding and project decommission checklists at the process level, so the problem stops compounding.

The cloud providers could do more here. AWS now flags unused credentials in IAM Advisor. But none of the major providers have made it genuinely difficult to create long-lived credentials with broad permissions — a design choice that keeps the ghost population growing every day.

— HackWire Editorial

---

## Related Coverage