Create Account

A new identity can preserve access

Unauthorized account creation establishes an identity that can provide access independently of the original compromised credential. The account may exist locally, in a directory, or in a cloud service. Its significance depends on the permissions, credentials, relationships, and resources actually available to it.

Account creation is also routine administration. Provisioning employees, service identities, and temporary project access produces similar events. An investigator should establish the creator, purpose, authorization, intended lifetime, and resulting access before deciding whether the account is malicious.

An unfamiliar service account appears

In a fictional academy, an audit alert reports a newly created account with a name resembling a backup service. The analyst identifies the immutable account identifier, creation time, creating principal, assigned permissions, and credential or authentication settings.

The backup team might have introduced an approved integration. The investigator compares the account with the change request and checks whether its permissions match the stated purpose. A plausible name does not establish legitimacy, and a legitimate creation request does not justify unrelated privileges added afterward.

The team searches for subsequent sign-ins and resource actions by the new identity. Creation establishes the identity's existence; it does not prove the account was used. Conversely, an account with no interactive sign-ins may still act through service credentials or APIs.

Follow the authority that created it

The creating principal's access matters because it may be able to create more identities or alter others. Disabling the new account while leaving the abused provisioning authority available can produce an incomplete containment.

Review related changes such as group membership, role assignment, application grants, recovery details, and additional credentials. Account Manipulation explains modifications that can expand or preserve access after an identity already exists.

Scope the search to the relevant environment, then expand it when evidence supports a broader reach. A local account and a cloud account with the same display name are not automatically the same identity.

Remove access deliberately

Preserve creation and activity records, then restrict or remove the unauthorized identity through the approved process. Check dependencies before deleting an account that might support a legitimate service. Verify what happens to active sessions, keys, tokens, or owned resources under the platform's behavior.

For practice, compare a documented temporary project account with a fictional account created by a compromised administrator. Identify which evidence supports authorization, which records establish later use, and what prevents recreation after cleanup. Persistence describes the objective, while Logs and telemetry and Incident reporting and handover keep the distinction between creation, access, and impact clear.

Related concepts

• MITRE ATT&CK
• Incident response