Detecting T1136 Create account in ATT&CK v20

How T1136 create account keeps an adversary inside your environment

When a new local, domain or cloud account appears in your environment and nobody can explain it, the SOC lead has to decide quickly whether it is an administrative change or an adversary keeping a way back in. T1136 Create Account is the MITRE ATT&CK technique where an adversary creates a new account so that access survives password resets, malware removal and the loss of a single foothold. It sits under the Persistence tactic, TA0003, which ATT&CK describes as the adversary trying to maintain their foothold. A new account is one of the simplest ways to do that, because it looks like a normal identity once it exists.

In intrusions, T1136 usually appears after an adversary has already obtained some level of access, typically when they want a credential that does not depend on the account they first compromised. The technique has three sub-techniques that separate the target: local accounts on endpoints and servers, domain accounts in the directory, and cloud accounts in the identity or infrastructure platform. Each one leaves different records, so your detection plan should name which of these your estate can create accounts in and which systems hold the authoritative logs. This page targets ATT&CK Enterprise version 20.0. Technique and sub-technique mappings can be renamed, deprecated or revoked between releases, so confirm the version your detection content references before you rely on a mapping.

Before you write any detection, confirm three things with your identity and platform owners: which account-creation events each directory, endpoint and cloud control plane records, where those events are forwarded, and who is authorized to create accounts outside a change process. An unexplained account is far easier to judge when the expected creators are documented. Those baselines are what let the SOC lead answer the first question quickly: is this account on the approved list, and does its creation match a ticket?

Which telemetry reveals a new account on Windows, Linux, macOS and IaaS

This table maps the data components most often tied to Persistence techniques (Process Creation, Command Execution, File Modification and File Creation) to the platforms where T1136 Create Account shows up, and to the open-source collector that can gather each one. Read each row as a starting point: the exact event sources and log paths must be confirmed in your own environment before you write detection logic against them.

Data component	Platforms where it helps	Signal to look for	Open-source collector
Process Creation (DC0032)	Windows, Linux, macOS	Execution of account-management utilities or commands that create users or groups, launched by unexpected parent processes or accounts	Wazuh agent process and command auditing, Velociraptor hunts on endpoints
Command Execution (DC0064)	Linux, macOS, IaaS management consoles and CLIs	Administrative command invocations that add accounts, reset passwords or attach roles, captured from shell history or cloud CLI audit records	Wazuh agent log collection, Velociraptor artifacts for shell history
File Modification (DC0061)	Linux, macOS	Writes to local account database files such as the passwd, shadow and group files, or their macOS directory service equivalents, outside of approved change windows	Wazuh file integrity monitoring, Velociraptor file collection
File Creation (DC0039)	Linux, macOS, Windows	New home directories, profile folders or local account artifacts appearing without a matching change ticket	Wazuh file integrity monitoring, Velociraptor filesystem artifacts
Windows account-management events	Windows domain and local accounts	Security log events for account creation, group membership changes and password resets, correlated with the account that performed them	Wazuh Windows event collection, Security Onion ingest of Windows logs
Cloud directory and IaaS audit records	IaaS and identity providers	Audit entries for user, service principal or role creation, including the initiating identity and source address	Wazuh log collection from cloud audit feeds, Security Onion where audit logs are forwarded
Network-side authentication traffic	Linux, Windows, IaaS	Authentication to services by newly created accounts shortly after creation, as observed in protocol metadata	Zeek authentication and protocol logs, Security Onion

Detection logic for new accounts that a SOC can tune

Account creation is noisy on its own, so the useful signal comes from combining who created the account, when, and what happened next. The five ideas below are starting points: each names the logic, the threshold a SOC should tune against its own baseline, and the legitimate sources that will fire first.

Account creation outside change windows

Alert when a user or local account is created outside approved provisioning windows or without a matching change ticket. The logic is a time and context check on account creation events from directory services, Windows security logs and IaaS audit trails. Tune the window to your change calendar and start with a short grace period for on-call and emergency changes. Expect false positives from scheduled HR onboarding batches, time zone mismatches in logs, and break-glass procedures that are documented but rarely exercised.

Creation followed by group membership

Correlate an account creation event with a privileged group addition for the same account within a short window, such as minutes. The logic joins Process Creation or directory change events on the account name, which matters because T1136 is often paired with privilege grants to keep access. Tune the window and the list of privileged groups to your own tiering model. Expect false positives from identity governance tools and role-based provisioning that create and assign roles in one transaction.

Creation by non-administrative identities

Flag account creation where the acting identity is a standard user, a service account, or an identity that has never created accounts before. Compare the actor against a known list of provisioning administrators and service principals. Tune the baseline over a period that covers your normal onboarding cycles. Expect false positives from help desk tools running under delegated service accounts and from directory sync connectors, so document each of these as an approved actor before alerting.

New accounts on IaaS consoles

Alert on user or access key creation in cloud control planes, and on new identities created outside infrastructure-as-code pipelines. The logic filters cloud audit logs for identity creation events and checks whether the change came from the approved pipeline role. Tune by listing which accounts are allowed to create identities in each subscription or project. Expect false positives from infrastructure-as-code runs that create service identities, and from application onboarding automation that the security team has not yet reviewed.

New local users on Linux and macOS

Alert when a new local user is created on a Linux or macOS host, especially one with a UID in the human range, a login shell, or membership in an administrative group. The logic reads host logs for user creation commands and checks changes to the account database files. Tune the threshold by host role, since build servers and jump hosts behave differently from workstations. Expect false positives from configuration management tools such as Ansible, Puppet, Chef and Salt, plus image build pipelines, so match against their known execution identities.

How to validate that the create account detection fires

This sequence proves that a create account detection fires for an approved, controlled account creation in an isolated range, and that the telemetry it depends on arrives with the fields analysts need. It ends with a detection register entry that records what was tested, what was seen and which gaps remain open.

Agree scope and rules of engagement
The detection owner, the range operator and the system owner agree in writing which platforms, identity stores and tenants are in scope, which accounts may be created, who may run the activity, and how the exercise will be stopped and cleaned up. Production identity systems stay out of scope. The step is complete when the signed rules of engagement name a single contact for halting the test and a rollback owner for every created account.
Prepare a test identity in the isolated range
Build the target environment in the cyber range with its own directory, domain or cloud tenant, and create a clearly named test identity used only for this exercise. Record the naming convention, expected privilege level and expiry in the test plan so that it cannot be confused with a real user. The step is complete when the range inventory lists the test identity and the range shows no route to production identity services.
Create the account through approved administrative means
An authorized administrator creates the test account using the sanctioned administrative interface or provisioning workflow that the organization normally uses, rather than an ad hoc method. The operator logs the time, the actor, the source system and the intended account name in the exercise log. The step is complete when the account exists in the range directory and the exercise log matches the change record.
Confirm the telemetry arrives in the platform
The detection engineer checks that the events expected for account creation reach the log platform from each source in scope, including identity provider, directory, operating system and cloud audit logs. Missing sources are logged as gaps before any alert review. The step is complete when each in-scope source shows the creation event in the SIEM search, or a documented reason why it does not.
Check whether the alert fires and when
The analyst reviews the alert queue for the detection rule mapped to the relevant data components, and records whether it fired, the rule version, and the time from account creation to alert creation. Timing is compared with the detection team's own expectation, and any lag is traced to ingestion, parsing or rule scheduling. The step is complete when the alert record or a documented non-firing result is saved with its timestamps.
Record which fields the event captured
The detection engineer compares the raw event with the fields the rule and the triage process depend on, such as the account name, the creating actor, the target system, the source host and the outcome. Fields that are missing, empty or normalized differently are listed with the parser or agent involved. The step is complete when a field-by-field comparison is attached to the exercise record.
Log results in the detection register and close gaps
Each result is entered in the detection register with the ATT&CK technique and sub-technique, the ATT&CK version targeted, the data components used, the rule identifier, the pass or fail outcome and the owner of each open gap. Gaps are assigned to a fix, such as a logging change, a parser update or a rule tuning, and the range is rerun to confirm the fix. The step is complete when every failed check has a named owner and a retest date agreed with that owner.

Preventive controls that limit who can create accounts

Account creation is hard to stop once an adversary holds privileged access, so the preventive work happens before that point. The cards below cover the two ATT&CK mitigations mapped to T1136 Create account, plus the related controls that shape who is allowed to create accounts and how that activity is recorded.

Privileged account management

Privileged Account Management (M1026) is the mitigation ATT&CK maps to T1136. In practice it means restricting account creation rights in Active Directory, cloud identity providers and Linux or macOS directory services to a small, named set of administrators, and reviewing that membership on a fixed schedule. An assessor will expect a current list of who holds these rights, the approval record for each grant, and evidence that rights are removed when roles change. Confirm with your identity team which directory groups carry account creation rights in each environment.

Multi-factor authentication for administrators

Multi-factor Authentication is the second mitigation mapped to T1136. It limits the damage from a stolen password, because an adversary who has only a credential cannot complete a privileged login to create an account. Scope matters: check that MFA covers the administrative consoles, remote management paths and cloud tenant admin roles, not only end-user sign-in. Assessors typically ask for the enforcement policy, the list of accounts exempted from it, and the reason for each exemption.

Separate administrative accounts

Administrators who create accounts should use a dedicated privileged identity, separate from the one they use for email and browsing. This keeps everyday phishing or malware on a user session from reaching the rights needed for T1136. Ask for a register of admin identities, the naming convention that marks them, and confirmation that these accounts are excluded from general mailbox and web access.

Audit of account creation events

Audit (M1047) is mapped to related Persistence techniques in ATT&CK, and it supports the preventive controls above by confirming they work. Enable logging of account creation and group membership changes on domain controllers, identity providers and privileged servers, then forward those events to a central store. Confirm with your platform team that the audit policy is set in each environment and that logs cannot be altered by the accounts being monitored.

User account management controls

User Account Management (M1018) is also mapped to related Persistence techniques. Its practical scope is the lifecycle of every account: a documented request and approval step, a standard for who may be granted an account, and a process that disables accounts when people leave or change roles. Assessors usually sample a set of recently created accounts and ask for the approval record behind each one. Confirm the fit of this mitigation for your environment before relying on it for T1136.

Triage steps when a new account alert fires

The first decision when a new account alert fires for T1136 Create account is whether the account was authorized, and you can answer that from records before you touch the host. Pull the change record or ticket that should justify the creation, then confirm the identity owner: the person or team named for the account, its intended role, and its expected lifetime. Next, identify the creator identity recorded in the event, whether that is a local administrator on a Windows or Linux host, a cloud IAM principal on an IaaS tenant, or a directory administrator. Check whether that creator was working on the change at the time, and whether the creation came from an expected automation pipeline or an interactive session. Finally, review recent logons for the new account. An account with no owner, no ticket and a logon from an unexpected source is a strong reason to escalate rather than wait.

If the account is not explained by a change, contain it before deeper analysis. Disabling the account is usually the least disruptive first step because it blocks new authentication while keeping the object and its attributes available for investigation. Review its group memberships at the same time, especially privileged groups such as local Administrators, sudo or wheel membership, cloud owner or admin roles, and directory groups that grant access to other systems. Remove the account from privileged groups only after you have recorded those memberships, and confirm with the identity team whether any existing sessions or tokens need revocation. Preserve evidence before you clean up: export the creation and group change events from your log platform, snapshot the host or cloud resource where practical, and retain relevant audit trails in write-once storage with a documented chain of custody. Confirm with your own retention policy and your incident response runbook how long these artifacts must be kept.

Escalate to the incident response lead and, where regulated data may be involved, to your legal and compliance contacts when any of these hold: the creator identity cannot be confirmed, the account is in a privileged group, the account logged on successfully, the creation coincides with changes to other accounts or security settings, or the same creator appears on several hosts or tenants. Agree these criteria in advance and record them in the runbook so that analysts on shift apply the same thresholds. After containment, document the decision path in the case record, including who approved the disablement, what was preserved and when. Any reclassification of the event as a confirmed incident should trigger a review of the detection logic itself, so that the alert's false positive and false negative rates are tracked against the ATT&CK version your rule targets.

Rehearsing T1136 detection and response in a private cyber range

Build the range with a small Active Directory domain, a domain controller, a Windows member server and a workstation, all forwarding Security event logs and Sysmon telemetry to the same Wazuh or Security Onion stack used in production. The purple team plans injects that create an account through the normal local and directory paths, then records the expected Process Creation, Command Execution and directory object change events so responders can confirm each one arrives. Scope the injects in writing with the range owner before the exercise begins.

Range topology: A domain controller, one member server and one workstation, with log forwarding matched to production agent versions and policies.
Injects: Account creation through a local administration path and a directory path, run at a planned time and logged with a unique exercise identifier.
Good detection: A Sigma-based alert fires within the expected window, carries the host, the actor and the new account name, and is enriched with asset owner and group membership.
Good response: The on-call analyst triages the alert within the agreed process, confirms or closes it, and documents the decision in the case record.
Good response (containment): The responder disables the test account through the agreed change path and verifies that the action is reflected in the directory.

Check that the time from inject to alert, and from alert to triage decision, matches the targets your organization has agreed to, and that gaps in event collection are logged as findings.

Questions SOC leads ask about detecting create account

How do I separate provisioning automation from attacker-created accounts?

Start by building an inventory of the legitimate sources that create accounts: identity provisioning connectors, HR-driven joiner workflows, configuration management, and cloud infrastructure pipelines. Each one should run under a named service identity with a known host, a known time pattern, and an expected naming convention. Alert on account creation that falls outside that baseline, such as creation by an interactive user, from an unexpected host, or outside a change window. Use Process Creation and Command Execution telemetry to see which process and parent created the account, and treat an allowlist as a living document that your change process updates. Confirm with your identity team which provisioning paths exist before you write a single rule, because undocumented scripts are the most common source of false positives.

How should I handle T1136 sub-technique coverage across platforms?

Treat each sub-technique as a separate coverage line, mapped to the platform where it actually occurs: local accounts on Windows and Linux or macOS, domain accounts in directory services, and cloud accounts in IaaS and SaaS control planes. Each line needs its own data source. Windows coverage typically depends on Process Creation and directory audit events, Linux and macOS on command execution and account database file changes, and cloud coverage on the provider's audit logs. Record, for every platform, whether you collect the telemetry, whether it reaches your SIEM, and whether a rule has been tested against it. A gap in any single column is the finding to fix first. Confirm the exact sub-technique IDs and data components against the ATT&CK version you target.

How often should I re-map detections to new ATT&CK versions?

Re-map on a fixed schedule and also after any release that touches your techniques. MITRE publishes ATT&CK updates on a recurring basis, and releases can rename, deprecate or revoke techniques and change data components, as the v18 change to detection strategies and analytics showed. Pin every rule and coverage record to the ATT&CK version it targets, then diff the STIX bundle for that version against your current one each time you upgrade. Review the Persistence techniques and their sub-techniques first, since T1136 links to several data components that other tactics also depend on. Agree the cadence with your detection engineering owner and record it in your change management process.

How can I test T1136 detections without affecting production?

Run the tests in a private cyber range or an isolated staging tenant that mirrors your identity provider, directory, Linux and macOS fleet, and cloud accounts closely enough that the audit events have the same shape. Use a dedicated test identity and a naming prefix that your production rules can recognize and exclude only in the test environment. Plan each exercise as a written scenario with a start time, expected events, and a rollback step that removes every test account. Confirm that the same log fields reach your SIEM in the staging path as in production, because a rule that only fires in the lab proves little. Ask your implementation partner to document the test plan and evidence so the results can be repeated after each rule change.

How do I tell whether a missed detection is a telemetry gap or a rule problem?

Work backward from the event. First confirm the account creation occurred, using the host or platform audit record itself rather than the SIEM. Then check whether that event was generated at all, which depends on audit policy, logging agent status, and the cloud provider's audit configuration. If the event exists at the source but not in the SIEM, the problem is collection or parsing. If the event reaches the SIEM but the rule does not match, the problem is the rule logic, field mapping, or a normalization change. Keep a short test matrix that records, for each platform and sub-technique, which of these three stages failed. In most environments, missing audit policy is the first thing to check, and you should confirm the current settings with each platform owner.

What should I ask a partner before we scope T1136 detection work?

Ask for a written scope that names the platforms in use, the SIEM and agents involved, the ATT&CK version targeted, and the sub-techniques covered. Ask how the partner will build the provisioning allowlist with your identity and platform owners, how it will test in a private cyber range before production, and what evidence it will hand over, such as rule definitions, test results, and a coverage record. Ask who owns ongoing tuning after handover and how re-mapping to new ATT&CK versions will be handled. DeployOpen plans and implements open-source detection stacks inside your own environment and runs the cyber range exercises, but it does not issue audit reports or certifications, so ask how the evidence will support your independent assessor.

Official ATT&CK sources for T1136 and Persistence

The sources below are the authoritative starting points for mapping T1136 Create account to detections. Check the tactic page for scope, the release notes for changes between versions, and the STIX bundle for the exact data component and mitigation links your rules depend on.

Persistence tactic page

The TA0003 page defines the Persistence tactic as the adversary trying to maintain its foothold, and lists the techniques that share it, including T1136. Use it to confirm which techniques and sub-techniques belong to the tactic before you scope a detection project. Check the technique list against the version your rules target, because a technique can belong to more than one tactic and the list can change between releases.

ATT&CK updates page

The updates page is the running log of ATT&CK releases, including renamed, deprecated or revoked techniques. For T1136, watch for changes to its three sub-techniques, to the data components referenced by its detection strategies, and to the mitigations it maps to. Record the ATT&CK version in every detection rule so that a later release does not silently break your mapping.

ATT&CK v18 release notes

The October 2025 release notes describe the move from technique-level detections to detection strategies with DET IDs and analytics, along with the update to data components and the deprecation of data sources. This matters for T1136 because account creation rules built on older data source names must be re-mapped to the data components the current analytics reference, such as Process Creation and Command Execution.

ATT&CK v19 release notes

The April 2026 release notes cover the changes that followed v18. Read them alongside the v18 notes to see which detection strategies, data components or mitigations changed after your baseline. Confirm whether any T1136 sub-technique (Local, Domain or Cloud Account) received new analytics or mapping changes before you certify a rule set against the newer version.

Enterprise-attack 20.0 STIX bundle

The STIX 2.1 bundle is the machine-readable source for the relationships your tooling needs: which techniques share the Persistence tactic, which data components each detection strategy references, and which mitigations such as Privileged Account Management and Multi-factor Authentication map to T1136. Load it into a local parser and generate your coverage matrix from it, rather than copying mappings from web pages by hand.

How DeployOpen builds and rehearses create account detections

DeployOpen approaches T1136 Create account as an implementation and testing engagement inside your own environment. We scope the written detection coverage for Windows, IaaS, Linux and macOS, build the open-source pipeline, and rehearse the detections in a private cyber range before handover.

How we scope

Confirm which platforms and sub-techniques of T1136 are in the written scope, including local, domain and cloud account creation.
Inventory the telemetry you already collect, such as process creation, command execution and file modification, and flag gaps.
Record the ATT&CK version the detection mappings target, so later releases can be compared against a fixed baseline.

How we build

Write detection logic for account creation events in Sigma and map it to the data components named in the ATT&CK detection strategies.
Deploy and tune the collection and alerting path in your Wazuh or Security Onion stack, within your own infrastructure.
Document the allowlists for approved provisioning tools and service accounts so that legitimate account creation does not flood the queue.

How we hand over

Deliver a written test plan that describes each simulated account creation scenario, expected alerts and pass criteria.
Provide runbooks for triage, account disablement and review of the Privileged Account Management and User Account Management controls.
Hand over detection rules, configuration and evidence in a form your own security team can maintain and version.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing for T1136 detections are available as a retainer.
Confirm with us how rule updates are handled when a new ATT&CK release renames, deprecates or revokes a mapped technique.

T1136 Create account