User account creation can indicate legitimate onboarding or an attacker creating a foothold for persistence. Security teams should verify the requester, source system, and timing, then check whether the new account has elevated privileges, remote access, or mailbox and cloud application permissions. Unexpected service, admin, or dormant accounts need prompt investigation.
What attack patterns are commonly associated with user account creation?
Account creation is often a visibility point for initial access, persistence, or abuse of a trusted onboarding path. Attackers may create ordinary-looking accounts, service accounts, or dormant accounts that can be activated later. They may also exploit weak approval flows, poor identity proofing, or delegated provisioning to blend malicious access into normal operations.
Watch for timing that does not match business onboarding, repeat requests from the same source, and accounts created with permissions that exceed the stated job function. Creation events become more suspicious when they are paired with remote access enablement, mailbox access, cloud app consent, or changes that make the account useful before any legitimate business activity exists.
In practice, the attack pattern is less about the mere existence of a new account and more about whether the account is being positioned for later control. That means the same creation workflow can be normal in one environment and a persistence foothold in another, depending on who initiated it, what identity evidence was used, and how much access the account received at birth.
Why newly created accounts are useful to attackers
New accounts are attractive because they often sit at the boundary between provisioning and monitoring. If the control plane assumes the request is legitimate once creation succeeds, an attacker can gain an account that looks administrative, temporary, or low risk until it is used. Human vs Non-Human Identity is useful here because many abuses start when people, automation, and delegated access are not clearly separated.
One common failure mode is over-privileged creation. The account may be born with mailbox permissions, cloud app access, or admin rights because provisioning templates are reused too broadly. Another is delayed detection: if the account is created outside normal hours or from an unusual source system, the event can be visible in logs but not escalated until after the account has been used for access or persistence.
Attackers also value accounts that are easy to re-use later. Dormant accounts, service accounts, and test accounts can survive long after the original request, especially when offboarding and review are inconsistent. That makes account creation not just an access event, but the start of an identity lifecycle problem.
What investigators should confirm first
The first question is whether the creation was requested by a real business process and approved through the expected path. The second is whether the source system, workflow, or operator matches normal provisioning behavior. The third is whether the new account has any access that would make it immediately useful to an attacker, especially remote login, privileged roles, inbox access, API tokens, or cloud application consent.
Selection of the right response depends on what the account can do, not just what it is called. A standard employee account with no elevated permissions is usually a lower-risk signal than a newly created admin or service account that can authenticate across multiple systems. If the account exists only to support automation, verify ownership, purpose, and rotation expectations before treating it as routine.
When the account looks suspicious, investigators should treat creation as the opening of a compromise chain, not the end of it. That means checking for parallel changes such as privilege assignment, mailbox rule creation, token issuance, session activity, or access from unusual locations soon after provisioning.
Risk and Threat Considerations
user account creation is a high-value event because it can hide persistence inside normal onboarding. A malicious account may look legitimate long enough to survive review, especially when creation, privilege grant, and first use happen close together or through a trusted provisioning system.
Failure mechanism: The attacker abuses weak requester verification, excessive default permissions, or unclear ownership so the new account becomes a durable access path rather than a checked identity record. If the account can reach mail, cloud apps, or remote access, it can support follow-on abuse with minimal friction.
Impact: The result can be unauthorized access, stealthy persistence, mailbox or application abuse, and delayed detection of a broader compromise. In environments with shared provisioning or delegated administration, one bad creation event can also create an ongoing blind spot across multiple systems.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1136.001 — Create Account: Local Account | Account creation events are a common persistence mechanism and attack indicator. |
| T1136.003 — Create Account: Cloud Account | Cloud account creation can establish attacker-controlled access in SaaS and cloud estates. | |
| T1098 — Account Manipulation | New accounts often become dangerous when paired with added rights, tokens, or access paths. | |
| Recommendation — Hunt for unauthorized account creation and correlate it with persistence and privilege changes. Review cloud account creation for abnormal origin, timing, and immediate access expansion. Monitor account changes for privilege grants, mailbox rules, and persistence-enabling modifications. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Account creation, approval, review, and removal are directly governed by account management controls. |
| IA-5 — Authenticator Management | New accounts become risky when secrets, tokens, or authenticators are issued without tight control. | |
| Recommendation — Require approval, review, and lifecycle tracking for every newly created account. Control issuance, rotation, and revocation of authenticators attached to new accounts. | ||
Practitioner Guidance
What to verify: Confirm who requested the account, what business process justified it, and whether the source system and timing match normal provisioning. If the request cannot be tied to a known workflow, treat the account as suspect until ownership and purpose are established.
Decision rule: If a newly created account has elevated privileges, remote access, mailbox permissions, or cloud application consent, escalate immediately and assess for persistence, not just misuse. If it is meant to be a service or dormant account, validate naming, ownership, and activation controls before accepting it as benign.
Practitioner takeaway: The key judgement is whether account creation is introducing a trusted identity or quietly creating an access path that will matter later. The sooner teams separate legitimate onboarding from durable foothold creation, the less likely they are to miss the start of an intrusion.