Orphaned account abuse

How it works

An orphaned account is an active account with no valid owner, typically left behind after an employee departs, a contractor's engagement ends, or a project's service account outlives the project. Deprovisioning workflows generally trigger off an HR termination event, which works well for accounts inside single sign-on that HR-driven automation actually reaches. It works poorly for local admin accounts on network appliances, accounts in SaaS applications procured outside IT, and service accounts created manually for a one-time task.

An attacker who obtains credentials for an orphaned account, through a prior breach, a credential dump, or simple guessing against a weak or reused password, logs in as an account nobody is checking on. There is no owner to notice unfamiliar activity, no scheduled access review that would catch it because it may not even appear in the population that review covers, and frequently no MFA enrollment because the account was set up before MFA was mandatory and never revisited.

Why it works

Identity governance assumes every active account has an accountable human or a documented business owner who would notice anomalous use. The control assumption that fails is coverage: deprovisioning automation only reaches the systems it is wired into, and any account outside that wiring, an appliance's local login, a SaaS tool bought with a corporate card, a service account nobody remembers creating, persists exactly as it was left. Attackers do not need a sophisticated technique here; they need patience to find the accounts that fell outside the reconciliation process, because those accounts inherit none of the monitoring built around the accounts that did not.

How to detect it

• Reconciling every active account across every system against an authoritative source of current employees and approved service accounts, and flagging anything with no match.
• Any login from an account with no activity in the preceding several months, since orphaned accounts are typically dormant until an attacker uses them.
• Accounts excluded from MFA policy, which correlates strongly with accounts that predate current identity standards and were never revisited.

Be honest about the limits: a full reconciliation catches only what it is pointed at, and systems outside SSO are precisely the ones least likely to be included in the reconciliation's scope in the first place. This is a coverage problem before it is a detection problem; the account has to be discoverable before it can be flagged.

How to stop it

• Extend deprovisioning automation beyond SSO to appliances, local admin accounts, and any application procured outside central IT, since these are exactly where orphaned accounts cluster.
• Run recurring account-to-owner reconciliation, not a one-time cleanup, treating any unreconciled account as a finding regardless of whether it has been misused yet.
• Include every system in scope for access certification, not only the applications integrated with the identity provider.
• Set expiration on service and project accounts by default, so an account created for a defined purpose does not silently outlive it.
• Treat an orphaned account as a standing incident once found, disabling it immediately rather than queueing it for the next scheduled cleanup.

Seen in the wild

• Midnight Blizzard vs Microsoft: a forgotten, non-MFA test tenant account was the entry point

Sources

• MITRE ATT&CK T1078: Valid Accounts
• NIST SP 800-53: Account Management (AC-2)