T1136: Create Account
Adversaries may create an account to maintain access to victim systems.[1] With a sufficient level of access, creating such accounts may be used to establish secondary credentialed access that do not require persistent remote access tools to be deployed on the system.
Accounts may be created on the local system or within a domain or cloud tenant. In cloud environments, adversaries may create accounts that only have access to specific services, which can reduce the chance of detection.
Analyst context for executives and security teams
Create Account is a persistence technique: an adversary with enough access may add a local, domain, or cloud account so they can return through normal authentication instead of relying on malware or remote access tools. For leaders, the risk is that access can look like ordinary administration unless account creation is tightly governed, logged, and reviewed across endpoints, directories, cloud tenants, SaaS, identity providers, network devices, containers, and ESXi environments.
Executive priority
Prioritize this as an identity governance and incident readiness issue, not just an endpoint detection problem. Executives should ask whether the organization can prove who is allowed to create accounts, where account creation is logged, how quickly unauthorized accounts are found, and whether privileged account management and MFA are consistently enforced. The relationship to the 2016 Ukraine Electric Power Attack also makes this relevant for organizations with cyber-physical operations, where unauthorized persistent access can affect operational resilience.
Technical view
SOC, detection engineering, and IR teams should validate monitoring for account creation across the supported platforms and the three ATT&CK sub-technique areas: local accounts, domain accounts, and cloud accounts. Windows environments should include user creation auditing such as Microsoft event 4720 where applicable. Cloud and SaaS teams should verify audit coverage for new users, service-specific accounts, and identity-provider accounts. Because ATT&CK provides no official detection text for this technique, teams should use the related DET0583 detection strategy as a starting point and tune against approved joiner, admin, break-glass, service account, and automation workflows.
Likely telemetry
- Operating system account creation logs, including Windows user creation auditing such as event 4720 where enabled
- Directory service and domain account management logs
- Cloud tenant and identity provider audit logs for new users or accounts
- SaaS and office suite administrative audit logs
- Privileged account management and administrative activity logs
Detection direction
- Baseline legitimate account creation by source system, administrator, role, time window, and business process.
- Alert on account creation outside approved workflows, especially by unusual administrators or from unexpected platforms.
- Correlate new accounts with privilege assignment, MFA enrollment status, first login, and access to sensitive services where telemetry supports it.
- Separate tuning for local, domain, and cloud account creation; blind spots often occur when cloud/SaaS audit logs are not centralized with endpoint and directory logs.
- Account for false positives from onboarding, automation, emergency administration, and service account provisioning by requiring authorization evidence rather than suppressing broadly.
Mitigation priorities
- Start with privileged account management: restrict who can create accounts, apply least privilege/RBAC, and require accountability through logging and auditing.
- Enforce MFA for critical systems and services, especially administrative and newly created accounts where applicable.
- Harden operating system configurations to reduce unnecessary account creation paths and improve auditability.
- Use network segmentation to limit what a newly created account can reach if it is abused.
- Maintain periodic reviews for local, domain, cloud, SaaS, and service-specific accounts, including stale or low-visibility accounts.
Analyst notes and limits
This technique is broad and spans many enterprise platforms. Its material value is in validating identity control coverage across places where accounts can be created, not in looking for one universal indicator. Related ATT&CK context includes sub-techniques for Local Account, Domain Account, and Cloud Account, mitigations M1026, M1028, M1030, and M1032, and observed use relationships involving campaigns, groups, and software listed in the supplied object.
The official ATT&CK detection field is not provided, so detection guidance must be validated against local logging, IAM architecture, and approved provisioning workflows. Supplied relationships show that this technique has been used by named campaigns, groups, and software, but they do not establish current activity or exposure in any specific environment.
Create Account
Adversaries may create an account to maintain access to victim systems.[1] With a sufficient level of access, creating such accounts may be used to establish secondary credentialed access that do not require persistent remote access tools to be deployed on the system.
Accounts may be created on the local system or within a domain or cloud tenant. In cloud environments, adversaries may create accounts that only have access to specific services, which can reduce the chance of detection.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1136.003 | Cloud Account Sub-technique | Cloud Account subtechnique of this object. |
| Enterprise | T1136.001 | Local Account Sub-technique | Local Account subtechnique of this object. |
| Enterprise | T1136.002 | Domain Account Sub-technique | Domain Account subtechnique of this object. |
Groups, software, and campaigns
G0119: Indrik Spider
Indrik Spider is a Russia-based cybercriminal group that has been active since at least 2014. Indrik Spider initially started with the Dridex banking Trojan, and then by 2017 they began running ransomware operations using BitPaymer, WastedLocker, and Hades ransomware. Following U.S. sanctions and an indictment in 2019, Indrik Spider changed their tactics and diversified their toolset.[1][2][3]
G1015: Scattered Spider
Scattered Spider is a native English-speaking cybercriminal group active since at least 2022. [1] [2] The group initially targeted customer relationship management (CRM) providers, business process outsourcing (BPO) firms, and telecommunications and technology companies before expanding in 2023 to gaming, hospitality, retail, managed service provider (MSP), manufacturing, and financial sectors. [2] Scattered Spider relies heavily on social engineering, including impersonating IT and help-desk staff, to gain initial access, bypass multi-factor authentication (MFA), and compromise enterprise networks. The group has adapted its tooling to evade endpoint detection and response (EDR) defenses and used ransomware for financial gain. [3] [4] [5] Scattered Spider had expanded into hybrid cloud and identity environments, using help-desk impersonation and MFA bypass to obtain administrator access in Okta, AWS, and Office 365. [6]
G1045: Salt Typhoon
Salt Typhoon is a People's Republic of China (PRC) state-backed actor that has been active since at least 2019 and responsible for numerous compromises of network infrastructure at major U.S. telecommunication and internet service providers (ISP).[1][2]
S1199: LockBit 2.0
LockBit 2.0 is an affiliate-based Ransomware-as-a-Service (RaaS) that has been in use since at least June 2021 as the successor to LockBit Ransomware. LockBit 2.0 has versions capable of infecting Windows and VMware ESXi virtual machines, and has been observed targeting multiple industry verticals globally.[1][2]
C0025: 2016 Ukraine Electric Power Attack
2016 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used Industroyer malware to target and disrupt distribution substations within the Ukrainian power grid. This campaign was the second major public attack conducted against Ukraine by Sandworm Team.[1][2]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.6 | Current bundle | a215440e37f1… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Symantec WastedLocker June 2020
Symantec Threat Intelligence. (2020, June 25). WastedLocker: Symantec Identifies Wave of Attacks Against U.S. Organizations. Retrieved May 20, 2021.
Open source URL -
[2]
Microsoft User Creation Event
Lich, B., Miroshnikov, A. (2017, April 5). 4720(S): A user account was created. Retrieved June 30, 2017.
Open source URL -
[3]
mitre-attack T1136Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.