Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0319: Detection Strategy for T1136.003 - Cloud Account Creation across IaaS, IdP, SaaS, Office

This detection strategy is about finding unauthorized cloud account creation associated with ATT&CK T1136.003, Cloud Account. The business significance is...

EnterpriseDET0319Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This detection strategy is about finding unauthorized cloud account creation associated with ATT&CK T1136.003, Cloud Account. The business significance is that a newly created account in an IaaS, SaaS, Office Suite, or Identity Provider environment can become a durable way for an adversary to keep access without relying on malware or remote access tools. For leaders, this makes account-creation visibility a core identity and cloud resilience control, not just an audit-log detail.

Executive priority

Prioritize confirmation that cloud and identity teams can answer: who created each account, from where, under what privilege, and whether the creation was expected. This matters for business continuity and incident decision-making because unauthorized accounts can preserve access after password resets or endpoint containment. It also supports compliance evidence around identity governance, privileged access management, and administrative change monitoring. Because the supplied detection strategy has no official MITRE detection text, organizations should treat this as a validation requirement rather than an assurance of existing coverage.

Technical view

The detection strategy object itself does not specify platforms, tactics, description, or detection logic. Its relationship indicates it detects T1136.003, Cloud Account, which is a persistence technique across IaaS, SaaS, Office Suite, and Identity Provider environments. SOC and detection teams should validate monitoring for account creation events across those control planes, especially creations performed by privileged roles, service principals, automation accounts, or recently changed administrators. IR teams should include newly created cloud identities in persistence scoping, including whether the account has assigned roles, group memberships, application access, mailbox or office-suite access, API keys, or federated identity paths.

Likely telemetry

  • Cloud identity provider audit logs for user, admin, service, or application account creation
  • IaaS IAM audit logs showing new users, roles, access keys, or identity objects
  • SaaS and Office Suite administrative audit logs for account creation and privilege assignment
  • Administrative role and group membership change logs following account creation
  • Authentication logs for first use, unusual source locations, or API-driven access by newly created accounts

Detection direction

  • Validate that account creation events are collected from every relevant IaaS, SaaS, Office Suite, and Identity Provider tenant, not only the primary directory.
  • Correlate new account creation with the creator identity, creator privilege level, source IP/location, user agent or API client, and any immediate role or group assignments.
  • Tune for high-risk patterns such as creation by rarely used admin accounts, creation outside normal provisioning workflows, creation followed by privileged assignment, or rapid first login/API use.
  • Account for false positives from HR onboarding, automated provisioning, break-glass procedures, and managed service administration by requiring change-ticket or identity-governance context.
  • Review blind spots around service accounts, guest/external accounts, workload identities, shadow tenants, and logs with short retention periods.

Mitigation priorities

  • Establish governed account provisioning workflows with approval, ownership, and audit evidence for cloud and SaaS identities.
  • Limit who can create accounts and assign privileged roles; separate routine provisioning from privileged administration where possible.
  • Require logging and retention for administrative identity events across IaaS, SaaS, Office Suite, and Identity Provider environments.
  • Regularly reconcile newly created accounts against HR, ticketing, and identity-governance records.
  • During incidents, disable or review recently created accounts and associated role assignments as part of persistence eradication.
Analyst notes and limits

The ATT&CK object is a detection strategy, DET0319, related to T1136.003 Cloud Account. The supplied object does not include official description or detection text, so this take is based on the relationship context and the related technique metadata: persistence across IaaS, SaaS, Office Suite, and Identity Provider platforms.

This summary does not assert active exploitation, actor use, specific vendor coverage, or guaranteed detection. Local tenant architecture, log availability, retention, identity-governance process, and administrative workflow evidence are required to determine actual coverage and risk.

Official MITRE ATT&CK definition

Detection Strategy for T1136.003 - Cloud Account Creation across IaaS, IdP, SaaS, Office

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1136.003 Cloud Account Sub-technique This object detects Cloud Account.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
7eb241af19aed205...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 7eb241af19ae…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0319
    Open source URL
Source and licensing

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.