How can security teams detect create account activity?

What “create account” activity looks like in logs

Create account activity is rarely a single event. In practice, teams should expect a new principal to appear in directory, authentication, SaaS admin, cloud control plane, or host logs, followed by one or more changes that make the account usable. That includes role grants, group membership changes, password or key assignment, mailbox or profile setup, and first logon or first API use.

Detection works best when the event stream is interpreted as a sequence, not an isolated record. A legitimate account creation usually aligns with an approved workflow, a named requester, and a change record. A suspicious one often appears outside normal hours, in an unusual system, or in proximity to other compromise indicators such as new admin membership or audit suppression.

For host-level visibility, compare local account creation against baseline administration patterns and look for creation of local administrators on endpoints or servers that normally should not be modified that way. For directory and cloud environments, focus on privileged groups, delegated admin roles, and service principals or service accounts that suddenly appear without a matching provisioning trail. The account type matters because the telemetry source and expected follow-on actions differ.

Where attackers hide account creation and why it matters

Account creation becomes dangerous when it is used to establish persistence, extend privilege, or replace a lost access path. Attackers often create a new user, service account, or local admin after initial compromise so they can return later without relying on the original entry point. That is why create-account alerts should be correlated with privilege changes, log tampering, and first-use activity. See Persistence Techniques Guide for the adjacent techniques that frequently follow account creation.

Service accounts deserve special attention because they are often granted broad access, long lifetimes, and weaker governance than human users. When a new service account appears, security teams should ask whether it is truly tied to an approved application or whether it is being used as a covert foothold. The same pattern can also show up in cloud and SaaS environments where privilege assignment and token issuance happen quickly after account creation. Service Account Security Guide is useful for separating legitimate automation from risky standing access.

Log integrity is part of the detection problem. If audit settings are disabled, truncated, or redirected soon after an account is created, treat that as a stronger signal than the creation event alone. In compromise investigations, the creation of a new account plus suppressed telemetry often points to a deliberate attempt to preserve access while reducing visibility. That is also why host and directory events should be checked against identity and authentication logs rather than reviewed in isolation.

How to confirm whether the account is legitimate

The practical test is whether the creation can be tied to an approved business process. Security teams should verify the requester, the ticket or provisioning record, the owning application or team, and the expected privilege set. If the account has no clear owner, no valid use case, or more access than the stated role requires, treat it as suspicious until proven otherwise.

Pay close attention to timing and sequence. Legitimate provisioning usually follows a known pattern, while malicious creation often appears after failed logons, privilege escalation, or other compromise signs. If the new account is immediately added to an admin group, assigned a key or token, or used to disable monitoring, the confidence that it is malicious rises sharply. Credential Dumping Guide is relevant when account creation appears alongside theft of existing credentials and rapid reuse of access.

Use this as an investigative decision point: if the account cannot be explained by a standard workflow and the supporting evidence is weak, escalate quickly and contain the associated identity before assuming it is administrative housekeeping. In most environments, false negatives are more costly than temporarily pausing a questionable new account.

Risk and Threat Considerations

Unapproved account creation is a persistence and privilege problem, not just an admin hygiene issue. Once an attacker can create a principal, they can often re-enter the environment, blend into normal administration, or create a backup access path that survives password resets on the original account.

Failure mechanism: The attacker abuses directory, cloud, or host administration rights to create a new account, then chains that event into role assignment, group membership, or local administrator status before defenders notice.

Impact: The organisation may gain a hidden foothold, lose confidence in account inventory, and miss the point at which access was first expanded. That can increase dwell time, complicate containment, and force broader credential and privilege review.

Practitioner Guidance

What to verify: Require a match between the creation event, the change record, and the eventual privilege state. The most useful evidence is not just that an account exists, but that its owner, purpose, and access level align with an approved workflow.

What to prioritise: Investigate any new account that appears near an incident window, especially if it is a service account, local administrator, or privileged directory user. Those cases combine high blast radius with low tolerance for ambiguity.

Practitioner takeaway: Treat account creation as a lifecycle event, not a point event, because the security question is whether the new identity is both authorised and bounded before it becomes a durable access path.

Related resources from NHI Mgmt Group

• How should security teams detect cloud account abuse when attackers use valid AWS access keys to create persistence?
• How should security teams detect automated bot activity before it turns into account takeover or scraping at scale?
• How should security teams detect account takeover attempts during a sudden surge in phishing and spoofing activity?
• How should security teams use SIEM correlation to detect suspicious privileged account activity across systems?