Your AD Has 200 Service Accounts. How Many Are Ghosts?

The dashboard shows green. Last login: recent. Status: enabled.

But the engineer who created that account left in 2023. The project it served was scrapped in Q1 2024. And the account still holds Domain Admin on three servers nobody remembers provisioning.

That's not a hypothetical. It's the most common finding in any serious Active Directory audit, and it's precisely why identity-based attacks keep climbing even as security budgets grow.

The Identity Problem Nobody Is Solving

Credential abuse accounted for 32% of all incidents in the IBM X-Force 2026 Threat Intelligence Index, the second most common initial access vector. The same report notes that most of these exposures are entirely preventable. Organizations had the tools. The gaps persisted because no single tool had visibility into how identity exposures chain together across environments into actual attack paths.

The Qualys Cloud Security Forecast 2026 makes the same point from a different angle: most cloud incidents originate from misgoverned identities and access relationships, not software vulnerabilities. Excessive permissions, long-lived credentials, service accounts with delegated trust that nobody revisited after the project shipped — these are the conditions that let attackers move through an environment using legitimate APIs without ever touching an exploit.

The perimeter isn't the wall anymore. The perimeter is the identity graph.

Human vs. Non-Human Identity: The Governance Gap

Most security programs still haven't fully internalized this part.

Human identities have a lifecycle. Users onboard, change roles, and eventually offboard. HR drives the process. There are tickets, approvals, and deprovisioning workflows. It's imperfect, but the machinery exists.

Service accounts, API keys, OAuth tokens, SSH keys, automation credentials — none of that applies. According to Netwrix's identity security research, the differences run deeper than just "no MFA":

Non-human identities don't complain about excessive privilege. They don't trigger anomaly alerts when they sit dormant for 18 months. And they don't get deprovisioned when their creator leaves.

Rubrik Zero Labs puts the NHI-to-human identity ratio at 45:1 in the modern enterprise. For cloud-native and DevOps environments, Entro Labs H1 2025 research puts that figure at 144:1. You are not staffed to govern that manually.

What a Ghost Account Actually Looks Like

A ghost service account isn't broken. It doesn't throw errors. It authenticates cleanly against AD and carries legitimate SPN registrations. From a monitoring perspective, it looks identical to any healthy service account.

What makes it a ghost is context that lives outside the directory. The engineer who created it no longer works at the company. The application it served was decommissioned. No ticket or ownership record exists. It hasn't been used in nine months, but nobody disabled it because nobody thought to look.

Research from late 2025 found that 1 in 20 AWS machine identities carries full Administrator privileges, typically created by developers during a quick fix and never revoked. The Active Directory equivalent is the service account that was given Domain Admin "temporarily" for a migration and never scoped back down.

The Google Mandiant M-Trends 2026 report documents attackers exploiting misconfigured AD Certificate Services templates to create admin accounts that bypass password rotation entirely. The foothold they needed to reach those templates in the first place? A stale service account with excessive delegation.

Three Ways Ghost Accounts Form

When Retrievy's ISPM engine runs against an AD environment, ghost service accounts almost always surface through one of three patterns.

Over-privilege at creation. The account needed broad permissions to ship on time, and scoping it properly was a problem for later. Later never came. A service account running a read-only sync job with Domain Admin membership isn't a misconfiguration anyone would write a ticket about. It's just how it ended up, and it stays that way indefinitely.

Orphaned ownership. The user who created the account left. The application team was reorganized. Nobody knows who owns it, so nobody disables it. Ownership ambiguity is the most reliable predictor of an account that will never be cleaned up. According to Obsidian Security's research on service account security, accounts without defined owners represent the most persistent lateral movement paths in enterprise environments, precisely because their authentication activity blends in with legitimate automation traffic.

Lifecycle abandonment. The project ended. The application was decommissioned. The VM was deleted. The service account was not. It sits in AD, fully enabled, with a password that hasn't rotated in two years, until something authenticates with it.

The Attack Path Nobody Draws in the Threat Model

Security teams draw threat models for external attackers hitting the perimeter. They rarely model the path that starts inside AD with a forgotten service account.

Here's how it typically plays out. An attacker gains initial access through phishing or a leaked credential. Enumeration reveals a dormant service account with a weak password policy and overly broad group membership. The account is used for lateral movement, generating authentication logs that look identical to automation traffic. Privilege escalation happens through the account's group memberships or delegation rights. The SIEM doesn't fire because the account has an established authentication history that nothing about the current activity deviates from.

Palo Alto's 2025 incident response investigations found identity weaknesses played a significant role in nearly 90% of cases. The organizations weren't flying blind. They had tooling, they had staff, and they still got hit. What they lacked was unified visibility into how individual identity exposures chain together into an actual attack path. A single over-privileged dormant account doesn't look like much in isolation. In context, it's the bridge between initial access and full domain compromise.

What Retrievy's ISPM Engine Checks

Retrievy's Identity Security Posture Management module runs dedicated checks against Active Directory via MS Graph. Several of them target exactly the failure modes described above.

Account hygiene checks include: accounts with no activity past a configurable threshold, accounts with passwords that haven't rotated in over 180 days, enabled accounts with no assigned owner or description, and service accounts living outside dedicated OUs.

Privilege audit checks cover: service accounts with Domain Admin or Enterprise Admin membership, Kerberoastable accounts with SPNs on high-privilege objects, accounts with unconstrained delegation enabled, and excessive permission inheritance chains.

Beyond individual checks, the identity graph traversal maps how permissions flow across nested group memberships. It surfaces cases where a service account appears low-privilege in isolation but inherits Domain Admin through a group three levels deep — the kind of thing a manual review almost never catches.

Every finding feeds into the asymptotic decay score. A score that can't be gamed with cosmetic patches: disabling an account only closes the finding after the next scan confirms the change in the environment.

From Finding to Fix

Surfacing ghost accounts is half the problem. Doing something about them at scale is the other half.

Retrievy routes each finding into the Hardening Kanban, a native remediation workflow that turns posture findings into assignable tasks. For each ghost service account, the card includes the last authentication timestamp, current group memberships, suggested remediation action (disable, scope down, transfer ownership), and compliance mappings to CIS Controls v8, NIST 800-53, and MITRE ATT&CK.

The task doesn't close as resolved until the next ISPM scan confirms the change. A ticket marked done in the workflow means nothing if the account is still enabled in AD.

A Manual Baseline to Start With

If you want to see the scope of the problem in your own environment before running a formal posture assessment, these queries give you a starting point.

# Service accounts inactive for 90+ days
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {
    Enabled -eq $true -and
    PasswordNeverExpires -eq $true -and
    LastLogonDate -lt $cutoff
} -Properties LastLogonDate, Description, MemberOf |
Select-Object Name, LastLogonDate, Description |
Sort-Object LastLogonDate

# Accounts with no description (high orphan probability)
Get-ADUser -Filter {
    Enabled -eq $true -and
    Description -notlike "*"
} -Properties Description |
Where-Object { -not $_.Description } |
Select-Object Name, SamAccountName, DistinguishedName

Most environments running this for the first time find between 15 and 60 accounts matching at least one of these criteria. That number tends to surprise people, and it tends to be conservative.

Continuous Posture, Not Quarterly Audits

CrowdStrike's research on non-human identities identifies the root issue clearly: service accounts and automation credentials get created without privilege scoping and without the oversight structures that govern human identity lifecycle. The result is a permanent backlog of ungoverned access that grows faster than any manual review process can address.

Point-in-time audits aren't useless, but they're not enough either. Your AD environment changes daily. New service accounts get created. Group memberships shift. Delegation rights get modified. A clean audit in January tells you nothing about what February looks like.

Continuous posture management is the only operationally sustainable answer.

The question isn't whether ghost accounts exist in your environment. They do.

The question is whether you find them before an attacker does.

See What Retrievy Finds in Your AD

Most environments aren't purely one thing. You have on-premises Active Directory running alongside Entra ID, and identity risk doesn't respect that boundary. A ghost service account on-prem can be the stepping stone to cloud resources. An over-permissioned Entra service principal can grant access back into hybrid-joined machines. The exposure chains across both.

Retrievy's ISPM module covers both sides of that boundary.

For on-premises Active Directory, a lightweight Windows agent collects identity data directly from the domain. No schema changes, no write permissions, no impact to existing infrastructure. The agent runs read-only and feeds findings back into the posture engine.

For Entra ID and cloud identity, there's no agent at all. Collection happens via MS Graph API with read-only delegated permissions. Nothing installed, nothing to maintain on the cloud side.

Every finding from both environments maps to CIS Controls v8 and NIST 800-53, lands in the same prioritized remediation queue, and contributes to the same posture score. Ghost accounts, over-privileged service accounts, orphaned identities, stale credentials. Surfaced in one place regardless of where they live.

Start your posture assessment →

References:

• IBM X-Force Cloud Threat Intelligence Index 2026
• Qualys Cloud Security Forecast 2026
• Google Mandiant M-Trends 2026
• The Hacker News: When Identity is the Attack Path (2026)
• The Hacker News: The Non-Human Identity Crisis (2026)
• Netwrix: Non-Human Identities Guide
• Obsidian Security: Service Account Security Best Practices
• CrowdStrike: What Are Non-Human Identities