MITRE ATT&CK T1136 Create Account Guide: Detecting Rogue Account Creation

An attacker who can create an account no longer needs the credential they came in with, and a new account created with legitimate admin rights rarely looks like an attack. MITRE ATT&CK tracks this as T1136 Create Account, a Persistence technique with three current sub-techniques in ATT&CK v20: Local Account, Domain Account and Cloud Account. This guide covers each sub-technique, the v20 detection strategies and the log sources they name, the four mitigations MITRE maps to the technique, and the identity governance controls that make a rogue account stand out against a clean provisioning baseline. It is written for detection engineers, identity and IAM teams and cloud platform owners, and it focuses on detection and prevention, not attacker procedures.

Key takeaways

• Account creation is a persistence move. ATT&CK describes T1136 as establishing secondary credentialed access that does not need remote access tools left on the system, so removing the malware does not remove the attacker.
• Every legitimate account should come from a known pipeline. If your HR-driven joiner process, SCIM connector or infrastructure-as-code is the only expected creator, anything else is an exception worth an alert.
• Creation is rarely the last step. The v20 cloud analytics chain account creation to role assignment, policy attachment and credential generation; detect the chain, not just the create event.
• Limit who can create accounts. M1026 Privileged Account Management asks for the fewest possible accounts with permission to create other accounts, which also shrinks your detection scope.
• Cloud service accounts count. ATT&CK includes Azure service principals and managed identities and GCP service accounts under T1136.003, which is where non-human identity governance and ITDR meet. See the ITDR Guide.

How the attack works

T1136 assumes the attacker already holds enough privilege to create accounts, usually through T1078 Valid Accounts (see the MITRE ATT&CK T1078 Valid Accounts Guide). The new account then serves as a fallback that survives a password reset of the original victim. From the defender's view, the pattern has three observable parts:

1. A creation event from an unusual actor, host, tool or time: for example an account created on a domain controller from an interactive session rather than by the provisioning service.
2. Empowerment of the new account: group or role membership, attached policies, or added credentials. ATT&CK links this follow-on activity to T1098.001 Additional Cloud Credentials and T1098.003 Additional Cloud Roles. See the MITRE ATT&CK T1098 Account Manipulation Guide.
3. First use: a sign-in or API call by an account with no history, often from infrastructure that the creating session also used.

The three sub-techniques in ATT&CK v20

ATT&CK also notes that in cloud environments an attacker may create accounts that can reach only specific services, which reduces the chance of detection: a narrowly scoped account can be more dangerous than an obvious new admin.

Where it shows up

• Domain controllers and AD management hosts: new users added outside the IAM or IGA pipeline, often followed by membership of a privileged group. See the Active Directory and Entra ID Hardening Guide.
• Servers and virtual machines: local administrator accounts created on individual hosts, including through cloud VM management extensions, which sit outside central directory reviews entirely.
• Appliances and hypervisors: ATT&CK specifically mentions super-admin accounts created on firewall management systems and accounts added to ESXi hosts.
• Cloud IAM: IAM users with access keys and console login profiles, new roles with trust policies, service principals and GCP service accounts. See the AWS IAM Policies and Roles Guide and the Google Cloud IAM and Service Accounts Guide.
• IdP tenants and SaaS: new members or guests in Entra ID, Okta or Google Workspace, and local accounts in SaaS applications that bypass SSO. See the Entra ID Applications and Consent Guide.

Impact

Detection

ATT&CK v20 defines one detection strategy for the parent technique and one per sub-technique. The table lists their analytics, the log sources MITRE names, and the elements MITRE says to tune.

Event and API reference

Detection logic that works

• Creator allow list: alert on any creation event whose actor is not the provisioning service account, the IGA connector or the infrastructure-as-code pipeline identity. This is the single most effective rule and needs a clean inventory of those creators.
• Creation outside the joiner record: reconcile new accounts daily against HR or ticket records; an account without a matching request is either a process gap or an intrusion. See the Joiner-Mover-Leaver Guide.
• Create then empower: creation followed within a short window by privileged group membership, role assignment or credential creation. Microsoft's 4720 guidance also suggests alerting on unusual attribute values, such as "Don't Expire Password", delegation flags or a non-default Primary Group ID.
• Hidden and look-alike names: service-style names such as svc* or backup*, which the v20 macOS analytic calls out, and names that do not match your naming standard.
• First use from unusual infrastructure: the new account's first sign-in or API call from the same IP or user agent as the creating session, or from outside admin networks.

Metrics

• Percentage of account creations in the last 30 days that came from an approved pipeline.
• Number of accounts with no owner or no matching joiner record.
• Number of identities holding account-creation rights, per platform, against a target.
• Median time from an unapproved creation alert to disablement.
• Coverage of DET0583, DET0447, DET0003 and DET0319 analytics by platform. See the MITRE ATT&CK Coverage Mapping Guide.

Prevention and hardening

Platform controls beyond the ATT&CK list

• Entra ID: set "Register applications" to No and "Restrict non-admin users from creating tenants" to Yes, review "Guests can invite" and the guest invite settings, and make privileged roles that can create users eligible through just-in-time activation. See the Privileged Identity Management (PIM) Guide.
• AWS: use IAM Identity Center for people instead of IAM users, and a service control policy that denies IAM user and access key creation outside a named pipeline role.
• Google Cloud: restrict service account and key creation with organisation policy constraints, and grant service account admin roles only to pipeline identities.
• Windows and Linux hosts: enable Audit User Account Management and Audit Security Group Management on every server, not just domain controllers; with Windows LAPS managing the one local admin, any other local admin is an anomaly. See the Local Administrator Password Solution (LAPS) Guide.
• Non-human identities: require an owner and purpose at creation for every service account and service principal. See the NHI Ownership Guide.

Implementation order

1. Turn on the logs: Windows audit subcategories, auditd rules for user management binaries and passwd/shadow, CloudTrail in all regions, Entra and M365 audit export, GCP Admin Activity logs to the SIEM.
2. Name the legitimate creators: list every pipeline and admin group that creates accounts; this becomes the allow list.
3. Run detections in report mode for two to four weeks: tune automation exemptions, then promote to alerting.
4. Reduce creation rights: remove standing rights and move the rest to just-in-time; deploy SCPs and organisation policies first to a sandbox account or folder, then by environment, keeping a documented rollback.
5. Automate containment: disable rather than delete an unapproved account so evidence survives, revoke its credentials and sessions, and review everything it touched. See the Account Takeover Response Playbook.

Decision guidance

• Small estates: alert on every creation event; the volume is low enough to review by hand.
• Large or automated estates: alert only on creation outside the allow list or followed by privilege, and reconcile the rest daily against the joiner record. ITDR and IGA tools help here. See the ITDR Buyer's Guide.
• Prevent or detect: preventive policies (SCPs, organisation policies, tenant settings) block the most damaging paths but can break legitimate automation, so pair them with an exception process; detection still matters because an attacker holding the pipeline identity passes every preventive check.

Framework mapping

Lessons from incidents

• Cloud account creation follows key theft quickly: in the AWS crypto-mining campaign, the attacker created a new IAM user, attached an SES full-access policy, and generated both an access key and a console login profile. Hunting for new IAM users, roles and keys before closing an incident is the lesson.
• Local accounts on cloud VMs escape directory reviews: in the Storm-2949 Azure attack, the attacker used a VM management extension to create a new local administrator account, which no Entra ID review would show.
• Persistence objects are not always users: the Storm-0501 attacks added a federated domain rather than a user, which ATT&CK tracks separately as T1484.002 Trust Modification. Monitor tenant trust changes alongside account creation.

Practitioner checklist

• Enable account and group management auditing on every Windows server and workstation, and auditd rules for user management on Linux.
• Stream CloudTrail, Entra audit, M365 unified audit, GCP Admin Activity and IdP system logs to the SIEM.
• Document every legitimate account creator and alert on creation by anything else.
• Reconcile new accounts daily against joiner and change records.
• Alert on creation followed by privileged group, role or credential assignment.
• Reduce the number of identities that can create accounts; make the rest just-in-time.
• Apply preventive guardrails: Entra user settings, AWS SCPs, GCP organisation policies.
• Require owner and purpose metadata for every service account and service principal at creation.
• After any credential compromise, hunt for new users, roles, service principals and local admins before closing. See the MITRE ATT&CK T1586 Compromise Accounts Guide.

Standards and references

• MITRE ATT&CK: Create Account (T1136)
• MITRE ATT&CK: Create Account: Cloud Account (T1136.003)
• Microsoft Learn: 4720(S) A user account was created
• Microsoft Learn: 4732(S) A member was added to a security-enabled local group
• Microsoft Learn: Microsoft Entra audit log activities
• AWS: Logging IAM and AWS STS API calls with AWS CloudTrail
• Google Cloud: IAM audit logging
• Microsoft Learn: What are the default user permissions in Microsoft Entra ID?

Related NHI Mgmt Group resources: ITDR Guide · Identity Visibility, Posture and Threat Detection Guide · MITRE ATT&CK T1078 Valid Accounts Guide · Service Account Security Guide · MITRE ATT&CK Guide for Defenders