DET0402: Detection Strategy for Cloud Service Discovery
This detection strategy is intended to help identify Cloud Service Discovery behavior: an actor enumerating cloud services after gaining access. For leader...
Analyst context for executives and security teams
This detection strategy is intended to help identify Cloud Service Discovery behavior: an actor enumerating cloud services after gaining access. For leaders, the practical issue is that discovery often tells an intruder what business systems, identities, security tools, CI/CD services, and cloud resources exist, which can shape later intrusion decisions. Because the detection-strategy object itself has no official description, detection logic, tactics, or platforms, teams should treat it as a pointer to validating coverage for the related ATT&CK technique T1526 across IaaS, identity provider, Office Suite, and SaaS environments.
Executive priority
Prioritize this as a cloud and identity visibility question: can the organization prove it sees unusual enumeration of cloud services, tenants, subscriptions, security services, and SaaS capabilities after account access? This matters for incident triage, audit evidence, cloud governance, and resilience because weak discovery monitoring can delay recognition that an identity or cloud session is being used to map the environment. Budget and control decisions should focus first on logging coverage and review processes across the cloud and SaaS services that matter most to critical operations.
Technical view
SOC and detection teams should validate coverage against the related technique, Cloud Service Discovery (T1526), rather than relying on this detection-strategy object for ready-made analytics. Confirm whether administrative, API, audit, and identity activity logs capture service-listing or resource-enumeration behavior in the related platform areas: IaaS, identity provider, Office Suite, and SaaS. Detection engineering should baseline normal administrative discovery activity, then look for unusual enumeration by newly authenticated users, unexpected roles, unfamiliar source locations, atypical automation patterns, or activity occurring near other suspicious identity or cloud events. Incident responders should preserve cloud audit and identity logs early, because discovery activity may be the first evidence that access was used to map the environment.
Likely telemetry
- Cloud provider audit/API activity logs for service listing, resource listing, and configuration discovery events
- Identity provider sign-in, token, role, and administrative audit logs
- SaaS and Office Suite audit logs showing tenant, application, mailbox, workspace, or service enumeration
- Cloud security service logs where available, including evidence of queries against security tooling or posture services
- Administrative console activity and command/API usage metadata
Detection direction
- Map local telemetry to ATT&CK T1526 Cloud Service Discovery because this object does not provide official detection text.
- Validate that logs are enabled, retained, and searchable across IaaS, identity provider, Office Suite, and SaaS environments relevant to the business.
- Tune detections to separate expected administrator inventory activity from unusual enumeration by standard users, service accounts, newly privileged accounts, or accounts with abnormal access context.
- Correlate discovery-like cloud activity with identity events such as new sign-ins, privilege changes, unusual sessions, or access from unfamiliar infrastructure.
- Check blind spots around SaaS audit licensing, cloud log retention, disabled audit categories, unmanaged tenants, and third-party integrations that can enumerate services through APIs.
Mitigation priorities
- First, ensure audit logging and retention are enabled for critical cloud, identity, Office Suite, and SaaS services.
- Apply least-privilege access so users and service accounts cannot broadly enumerate services beyond business need.
- Review administrative roles, service accounts, and automation permissions that can perform broad cloud or SaaS discovery.
- Require strong identity controls for cloud and SaaS access, including appropriate conditional access or equivalent policy enforcement where used locally.
- Document expected inventory, compliance, and management tooling so SOC teams can distinguish authorized enumeration from suspicious discovery.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy named Detection Strategy for Cloud Service Discovery and has a relationship indicating it detects T1526 Cloud Service Discovery. The related technique is in the discovery tactic and lists IaaS, Identity Provider, Office Suite, and SaaS as platforms. The business value is in validating whether cloud and identity telemetry can show service enumeration after access, especially where SaaS and cloud administration are material to operations.
The detection-strategy object has no official description, no official detection guidance, no tactics, and no platforms specified on the object itself. Recommendations above are conservative and derived from the relationship to T1526 and its supplied context. Local cloud providers, SaaS products, logging configuration, licensing, retention, and normal administrative behavior must be reviewed before asserting detection coverage.
Detection Strategy for Cloud Service Discovery
No official description is available in the imported ATT&CK source object.
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.
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1526 | Cloud Service Discovery | This object detects Cloud Service Discovery. |
All related ATT&CK context
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.0 | Current bundle | 67b22ce0f17f… |
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]
mitre-attack DET0402Open 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.