T1136.003: Cloud Account
Adversaries may create a cloud account to maintain access to victim systems. With a sufficient level of access, such accounts may be used to establish secondary credentialed access that does not require persistent remote access tools to be deployed on the system.[1][2][3][4][5]
In addition to user accounts, cloud accounts may be associated with services. Cloud providers handle the concept of service accounts in different ways. In Azure, service accounts include service principals and managed identities, which can be linked to various resources such as OAuth applications, serverless functions, and virtual machines in order to grant those resources permissions to perform various activities in the environment.[6] In GCP, service accounts can also be linked to specific resources, as well as be impersonated by other accounts for Temporary Elevated Cloud Access.[7] While AWS has no specific concept of service accounts, resources can be directly granted permission to assume roles.[8][9]
Adversaries may create accounts that only have access to specific cloud services, which can reduce the chance of detection.
Once an adversary has created a cloud account, they can then manipulate that account to ensure persistence and allow access to additional resources - for example, by adding Additional Cloud Credentials or assigning Additional Cloud Roles.
Analyst context for executives and security teams
Cloud Account is a persistence technique where an adversary with enough access creates a new user, admin, service account, service principal, managed identity, or role-linked cloud identity so they can return without relying on malware or remote access tools. For leaders, the practical issue is identity resilience: if account creation is not tightly governed and logged across IaaS, SaaS, Office Suite, and identity providers, an intrusion can become a durable access problem that survives endpoint cleanup.
Executive priority
Prioritize this as a cloud and identity control validation item. The key business question is whether the organization can prove who is allowed to create cloud accounts, service principals, managed identities, and role-assumable resources; whether those creations are reviewed quickly; and whether privileged account management, MFA, and segmentation controls reduce the blast radius. This matters for incident response scoping, audit evidence, and cloud/SaaS continuity because unauthorized accounts can provide secondary credentialed access into critical services.
Technical view
ATT&CK places this sub-technique under Create Account for the persistence tactic, on IaaS, SaaS, Office Suite, and Identity Provider platforms. SOC and IR teams should validate visibility into account and service-account creation across cloud identity planes, including AWS IAM users and role usage patterns, GCP Cloud Identity users and service accounts, and Microsoft Entra ID users, service principals, and managed identities. The related detection strategy DET0319 indicates detection should be approached across IaaS, IdP, SaaS, and Office environments rather than a single control point. Also watch for follow-on relationships described by ATT&CK: newly created accounts may later receive Additional Cloud Credentials or Additional Cloud Roles.
Likely telemetry
- Cloud identity audit logs for user creation, deletion, and modification events
- Administrative role assignment and privileged account management logs
- Service principal, managed identity, service account, and resource-linked identity creation records
- IaaS IAM logs for IAM user creation and role-assumption-capable resources
- SaaS and Office Suite admin activity logs
Detection direction
- Inventory all places where accounts can be created: IaaS, SaaS, Office Suite, and the identity provider. Coverage gaps often appear where service accounts, service principals, managed identities, or role-assumable resources are treated as infrastructure changes rather than identity changes.
- Alert or review on new cloud accounts, especially privileged accounts, accounts with narrow service-specific access that may evade broad admin-focused monitoring, and accounts created outside expected administrative workflows.
- Correlate new account creation with subsequent credential additions, role assignments, MFA changes, or resource bindings, because ATT&CK notes that created cloud accounts may be manipulated for additional access.
- Tune false positives around legitimate onboarding, automation, and infrastructure deployment pipelines by requiring linkage to approved change records, expected creators, and expected naming or ownership metadata.
- During incident response, include recently created cloud users, service accounts, service principals, managed identities, and role-linked resources in persistence sweeps; endpoint remediation alone is insufficient for this behavior.
Mitigation priorities
- Apply privileged account management: restrict who can create users, administrators, service accounts, service principals, managed identities, and role-assumable resources; enforce least privilege and accountability through logging and auditing.
- Require MFA where applicable, especially for administrative and newly created interactive accounts, while separately governing non-interactive service identities through least privilege and ownership review.
- Use network segmentation and access-control boundaries to limit what newly created or compromised identities can reach, especially for critical cloud resources and management planes.
- Establish routine review of newly created identities and their roles, credentials, and resource links across cloud and SaaS estates.
- Maintain auditable approval workflows for account creation so security teams can distinguish authorized administration from suspicious persistence.
Analyst notes and limits
This object is most useful as an identity and cloud persistence control test. The presence of related groups APT29 and LAPSUS$, and related software AADInternals, supports defensive awareness that the behavior is represented in ATT&CK usage relationships, but it should not be used by itself to claim current activity in any environment. Local risk depends on who can create accounts, how service identities are governed, and whether audit logs are centralized and retained.
MITRE provides no official detection text for this object in the supplied fields. Detection guidance here is derived from the object description, platforms, tactic, external references, and the related DET0319 detection strategy name. Environment-specific validation is required for each cloud provider, SaaS platform, identity provider, and logging configuration.
Cloud Account
Adversaries may create a cloud account to maintain access to victim systems. With a sufficient level of access, such accounts may be used to establish secondary credentialed access that does not require persistent remote access tools to be deployed on the system.[1][2][3][4][5]
In addition to user accounts, cloud accounts may be associated with services. Cloud providers handle the concept of service accounts in different ways. In Azure, service accounts include service principals and managed identities, which can be linked to various resources such as OAuth applications, serverless functions, and virtual machines in order to grant those resources permissions to perform various activities in the environment.[6] In GCP, service accounts can also be linked to specific resources, as well as be impersonated by other accounts for Temporary Elevated Cloud Access.[7] While AWS has no specific concept of service accounts, resources can be directly granted permission to assume roles.[8][9]
Adversaries may create accounts that only have access to specific cloud services, which can reduce the chance of detection.
Once an adversary has created a cloud account, they can then manipulate that account to ensure persistence and allow access to additional resources - for example, by adding Additional Cloud Credentials or assigning Additional Cloud Roles.
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 | Create Account | This object subtechnique of Create Account. |
Groups, software, and campaigns
G0016: APT29
APT29 is threat group that has been attributed to Russia's Foreign Intelligence Service (SVR).[1][2] They have operated since at least 2008, often targeting government networks in Europe and NATO member countries, research institutes, and think tanks. APT29 reportedly compromised the Democratic National Committee starting in the summer of 2015.[3][4][5][6]
In April 2021, the US and UK governments attributed the SolarWinds Compromise to the SVR; public statements included citations to APT29, Cozy Bear, and The Dukes.[7][8] Industry reporting also referred to the actors involved in this campaign as UNC2452, NOBELIUM, StellarParticle, Dark Halo, and SolarStorm.[9][10][11][12][13][14]
G1004: LAPSUS$
LAPSUS$ is cyber criminal threat group that has been active since at least mid-2021. LAPSUS$ specializes in large-scale social engineering and extortion operations, including destructive attacks without the use of ransomware. The group has targeted organizations globally, including in the government, manufacturing, higher education, energy, healthcare, technology, telecommunications, and media sectors.[1][2][3]
S0677: AADInternals
AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure Active Directory. The tool is publicly available on GitHub.[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 | 1.6 | Current bundle | 0df3eea96493… |
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]
Microsoft O365 Admin Roles
Ako-Adjei, K., Dickhaus, M., Baumgartner, P., Faigel, D., et. al.. (2019, October 8). About admin roles. Retrieved October 18, 2019.
Open source URL -
[2]
Microsoft Support O365 Add Another Admin, October 2019
Microsoft. (n.d.). Add Another Admin. Retrieved October 18, 2019.
Open source URL -
[3]
AWS Create IAM User
AWS. (n.d.). Creating an IAM User in Your AWS Account. Retrieved January 29, 2020.
Open source URL -
[4]
GCP Create Cloud Identity Users
Google. (n.d.). Create Cloud Identity user accounts. Retrieved January 29, 2020.
Open source URL -
[5]
Microsoft Azure AD Users
Microsoft. (2019, November 11). Add or delete users using Azure Active Directory. Retrieved January 30, 2020.
Open source URL -
[6]
Microsoft Entra ID Service Principals
Microsoft. (2023, December 15). Application and service principal objects in Microsoft Entra ID. Retrieved February 28, 2024.
Open source URL -
[7]
GCP Service Accounts
Google. (n.d.). Service Accounts Overview. Retrieved February 28, 2024.
Open source URL -
[8]
AWS Instance Profiles
AWS. (n.d.). Using instance profiles. Retrieved February 28, 2024.
Open source URL -
[9]
AWS Lambda Execution Role
AWS. (n.d.). Lambda execution role. Retrieved February 28, 2024.
Open source URL -
[10]
mitre-attack T1136.003Open 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.