T1136.003Not expressible in Sigma

Cloud Account

PersistenceIaaS, SaaS, Office Suite, Identity Provider

Where this stands

No Sigma rule can address this — the telemetry MITRE names has no Sigma logsource behind it.

None of MITRE's analytics for this technique name a log source that maps to a Sigma logsource — they describe abstract data ("Process::None"), API-hook telemetry, or prose channels with no reliable field names behind them.

What the technique is

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. 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. In GCP, service accounts can also be linked to specific resources, as well as be impersonated by other accounts for Temporary Elevated Cloud Access. While AWS has no specific concept of service accounts, resources can be directly granted permission to assume roles. 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.

Read it on attack.mitre.org

What MITRE says you would watch

AN0899
Adversaries create user accounts via identity provider APIs or admin portals (e.g., Azure AD, Okta). These accounts may be assigned elevated privileges or used in chained authentication. Detection monitors Add User activity from suspicious IPs or automation sources, followed by role/permission escalation.
AN0900
Adversaries use cloud API, CLI, or console to create IAM users or roles. Initial CreateUser is followed by policy/role attachment. Detection monitors temporal chains involving IAM:CreateUser, AttachUserPolicy, and credential generation, especially from automation or foreign IP ranges.
AN0901
Adversaries create SaaS accounts via admin dashboards or integrations (e.g., Zoom, Salesforce, Slack). Monitor lifecycle.create or account provisioning events from non-standard sources or times.