# The Identity That Never Existed: How Attackers Are Fabricating Machine Accounts From Scratch
For twenty years, the financial industry's fraud teams chased the wrong problem. They built sophisticated detection systems for stolen identities — flagging the moment a real person's credit file got hijacked. Synthetic identity fraud, where attackers constructed entirely new people from fragments of real and invented data, sailed through those systems undetected. No real victim meant no fraud alert, no dispute call, no suspicious activity report. The fake person simply... accumulated trust.
Security teams protecting enterprise infrastructure are making the same mistake right now, just one layer up.
## The Machine That Was Never Supposed to Exist
Most of the attention on Non-Human Identities — the service accounts, API tokens, machine certificates, and workload credentials that now outnumber human users in enterprise environments by a factor of forty-five to one — focuses on credential theft. Protect the secret. Rotate the key. Detect unauthorized use.
That's the right instinct for the wrong attack.
The emerging threat isn't an attacker stealing a service account's credentials. It's an attacker creating a service account that was never supposed to exist, building it to look native, and letting it accumulate permissions in the background until it's useful. No compromised credential. No victim to file a complaint. No anomalous login behavior because every login is technically the first one.
This is synthetic identity fraud applied to machine identities — and it's largely invisible to the detection infrastructure most organizations have built.
## What Makes a Fabricated Identity Convincing
The individual techniques attackers use aren't new. Rogue service accounts have been a post-exploitation move since the early days of Active Directory. DCShadow, which lets an attacker with domain admin rights temporarily spin up a fake domain controller so malicious changes replicate as legitimate traffic, was demonstrated at Black Hat in 2018. Shadow credentials — injecting attacker-controlled authentication material onto an existing object — emerged as a recognized threat a few years later.
What's new is recognizing them as a single pattern, not isolated tactics.
A well-constructed fabricated machine identity inherits its environment's naming conventions. It exists in the correct domain. It carries plausible metadata. It requests exactly the kinds of permissions that a dozen other service accounts in the same environment already hold. Drop it into a directory of fifty thousand service accounts and it's invisible to any human scanning the list.
The key mechanism is borrowed legitimacy. Consumer synthetic ID fraud works because a credit bureau sees a Social Security number that's real, an address that's real, and a name that doesn't belong to anyone. The contradictions are subtle enough that automated systems approve it. Machine synthetic identity fraud works for the same reason: the domain is real, the naming pattern is real, the permission request is routine. The account just has no legitimate owner.
## Why the Timing Is Worse Than It Looks
Enterprise NHI proliferation has outpaced governance for years. The average large organization now has hundreds of thousands of machine identities distributed across cloud providers, SaaS platforms, CI/CD pipelines, and on-premise infrastructure. Security teams that can't maintain basic inventories of what NHIs they've legitimately provisioned have no realistic chance of spotting one that was injected.
There's a compounding problem: the growth isn't slowing. Every new microservice spins up credentials. Every third-party integration requests a service account. DevOps teams create tokens under deadline pressure with no formal provisioning process. In that environment, "we have an account that shouldn't be here" is nearly impossible to distinguish from "we have an account someone created last Tuesday and forgot to document."
Shadow credentials specifically deserve more attention than they're getting. Unlike rogue accounts, they don't create new objects — they attach attacker-controlled authentication material to objects that already exist and already look legitimate. The account passes every ownership check because it's a real account. Only the authentication path has been poisoned.
## What Defenders Actually Need to Change
The instinct to add more detection on top of existing NHI monitoring won't fix this. Detection downstream of a fabricated identity's creation is a losing race — the fabricated account generates no "compromised credential" signal because nothing was compromised.
The necessary shift is to governance before detection:
The deeper shift is cultural. NHI governance has been treated as an IAM housekeeping problem — something to clean up quarterly. The synthetic identity fraud parallel suggests it should be treated the same way banks treat their account opening process: with controls specifically designed to prevent fraudulent accounts from existing in the first place.
---
## HackWire Analysis
The synthetic ID fraud analogy is sharper than it might first appear, and the industry is behind on taking it seriously.
In financial services, it took roughly fifteen years after synthetic fraud became a documented pattern before regulators and banks implemented meaningful controls — identity verification at account opening, Social Security Administration number validation, synthetic-specific machine learning models. During that window, estimated losses ran into the tens of billions of dollars annually. The lag happened because existing fraud infrastructure was built around a different threat model, and retrofitting it was expensive and disruptive.
Enterprise NHI security is at an earlier inflection point. The dominant threat model is still "protect the credential" — vault secrets, detect anomalous usage, rotate tokens. That's necessary but not sufficient. There's no equivalent of "verify this identity actually belongs to someone" baked into how most organizations manage machine accounts.
What makes the timing particularly concerning: the tooling to execute this class of attack is widely available and well-documented. DCShadow tooling is in common offensive security frameworks. Shadow credentials attacks have public proof-of-concept code. The barrier to fabricating a convincing machine identity is lower than fabricating a convincing synthetic human identity, because the "checks" that would catch a fraudulent human identity — a real SSN, a credit history that predates the fraud — simply don't have equivalents in most NHI governance programs.
The vendors selling NHI security solutions are increasingly sophisticated at detecting stolen credentials. The fabricated credential problem is where the gap is — and the gap is wide. Security teams that think they've addressed machine identity risk because they've deployed NHI monitoring should be asking a harder question: how confident are you that every identity in your environment was legitimately provisioned?
Most organizations can't answer that question. That's the problem.
— HackWire Editorial
---
## Related Coverage