Attackers use Establish Accounts to create new local, domain, or cloud accounts for persistence and access after initial compromise. These accounts may blend into normal administration if naming and group membership are not reviewed. Defenders should monitor account creation, privilege assignment, and sign-ins from newly created identities, especially outside approved provisioning workflows.
How Establish Accounts supports an attacker’s persistence
“establish accounts” is an attacker persistence step, not just a setup action. It gives the intruder a fresh identity they control, which can survive password resets on the original foothold, complicate attribution, and provide a quieter route back into the environment. The core defensive question is whether account creation is expected, approved, and visible.
Attackers usually prefer accounts that look operational rather than obviously malicious. That can mean local admin-style accounts on endpoints, dormant-looking domain users, or cloud identities that resemble service, integration, or support accounts. If naming patterns, group membership, and owner fields are not reviewed, the new account can blend into routine administration.
Because account establishment is only useful when the account can actually do something, attackers often pair it with privilege assignment, role changes, or token and session access. A newly created identity that cannot sign in or cannot reach the target system is far less valuable. That is why defenders need to look at the full chain, account creation, privilege grant, and first use, rather than treating creation as an isolated event.
Why the account creation method matters
The attack is more effective when it uses the same pathways your environment already trusts. In an enterprise, that may mean directory changes, delegated administration, automation pipelines, API-driven provisioning, or cloud console actions. If those pathways are not tightly governed, the attacker can create an account in a way that appears to be ordinary administration rather than a compromise indicator.
Context matters because “create account” can mean different things across local systems, domain services, and cloud platforms. A local account may help the attacker retain access to a single host. A directory or cloud account may extend reach across many systems, especially if it inherits existing roles or is added to a broadly trusted group. The more central the identity system, the more damaging one quiet account can become.
One useful defender lens is whether the account creation event is linked to an approved workflow and a known owner. If not, the event deserves immediate review even when the username itself looks harmless. That same principle applies to identities created through automation, because the security question is not whether a machine created the account, but whether the creation was legitimate and traceable. See the MITRE ATT&CK Guide for Defenders for attacker technique mapping and detection planning around account creation and related behaviour.
What defenders should verify after new identities appear
After any unexpected account creation, verify three things fast: who created it, what privileges it received, and whether it has already signed in. That sequence helps separate harmless administrative activity from a persistence foothold. If the identity has admin rights, access to sensitive systems, or signs of immediate use, treat it as a potential compromise rather than a bookkeeping issue.
It also helps to check whether the account follows your normal naming, onboarding, and approval standards. Accounts that lack a clear owner, break naming conventions, or appear outside change windows are high-signal anomalies. In cloud environments, review whether the account has API keys, console access, federation trust, or role bindings that expand its reach beyond the visible username.
New account monitoring should be tied to adjacent signals, not only the creation event itself. New sign-ins, first-time privilege changes, mailbox or token activity, and lateral movement from the new identity often provide the evidence that turns a suspicious account into a confirmed persistence method. Service Account Security Guide is also useful where attackers try to hide inside legitimate-looking operational identities.
Risk and Threat Considerations
Attackers use newly established accounts because they convert one-time access into repeatable access. The danger is highest when account creation is weakly audited, when approval workflows are bypassable, or when the new identity inherits existing trust and privilege without a second review.
Failure mechanism: The attacker creates or modifies an identity that is accepted by normal control paths, then uses that identity for persistence, privilege expansion, or stealthy re-entry. If the environment does not correlate account creation with ownership, approval, and first use, the compromise can persist unnoticed.
Impact: A single hidden account can extend dwell time, enable lateral movement, and survive remediation of the original entry point. In cloud and domain environments, that can also expose broader administrative surfaces, making a contained incident look like ordinary account sprawl.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1136 — Create Account | Directly covers attacker-created accounts for persistence and access. |
| Recommendation — Detect and alert on unsanctioned account creation across endpoints, directories and cloud. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Account creation, review, and removal are central to this attacker technique. |
| AU-12 — Audit Record Generation | Creation and first-use events need logging to spot hidden persistence accounts. | |
| IA-5 — Authenticator Management | New accounts often become persistence vehicles through credentials and tokens. | |
| Recommendation — Enforce approval, review, and disablement controls for all accounts and privileged changes. Generate audit records for account creation, privilege changes, and first sign-in events. Manage credential issuance and rotation so newly created accounts cannot retain stale access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Prescribes controlling and reviewing account lifecycle to reduce unauthorized accounts. |
| Recommendation — Inventory, approve, and continuously review accounts, especially those with elevated access. | ||
Practitioner Guidance
What to verify: Confirm that every nonstandard account has a documented business owner, an approved reason for existence, and a matching provisioning record. If any of those are missing, treat the account as suspicious until proven legitimate.
What to measure: Track the gap between account creation and first sign-in, and flag accounts that appear outside approved provisioning windows or receive privileges immediately after creation. Those are often the clearest indicators that the identity exists for attacker use rather than operational need.
Common mistake: Teams often focus on password resets and ignore the new account itself. That leaves a durable backdoor in place even after the original compromise path is closed.
Practitioner takeaway: The highest-value control is not just detecting account creation, but proving that each new identity is owned, expected, and minimally privileged before it can be used.
Related resources from NHI Mgmt Group
- What breaks when attackers use AI agents to establish persistence inside SaaS accounts?
- Why do non-human identities create more risk than many human accounts?
- Why do non-human identities create more remediation risk than many human accounts?
- How do attackers turn a supply-chain incident into wider NHI compromise?