DC0090: Cloud Service Disable
This data component refers to monitoring actions that deactivate or stop a cloud service in a cloud control plane. Examples include disabling essential logging services like AWS CloudTrail (`StopLogging` API call), Microsoft Azure Monitor Logs, or Google Cloud's Operations Suite (formerly Stackdriver). Disabling such services can hinder visibility into adversary activities within the cloud environment. Examples:
- AWS CloudTrail StopLogging: This action stops logging of API activity for a particular trail, effectively reducing the monitoring and visibility of AWS resources and activities. - Microsoft Azure Monitor Logs: Disabling these logs hinders the organization’s ability to detect anomalous activities and trace malicious actions. - Google Cloud Logging: Disabling cloud logging removes visibility into resource activity, preventing monitoring of service access or configuration changes. - SaaS Applications: Stopping logging removes visibility into user activities, such as email access or file downloads, enabling undetected malicious behavior.
Analyst context for executives and security teams
Cloud Service Disable is a visibility-risk data component: it focuses on evidence that a cloud control-plane service, especially logging or monitoring, has been stopped or deactivated. For executives and security leaders, this matters because loss of cloud logging can turn a manageable incident into an investigation with missing facts, weaker audit evidence, and slower containment decisions.
Executive priority
Treat disablement of cloud logging and monitoring as a resilience and governance issue, not only a SOC alert. Leaders should ask whether essential cloud and SaaS activity logs are protected from unauthorized shutdown, whether disablement creates a business-impacting evidence gap, and whether incident response and compliance processes can prove who changed logging, when, and why.
Technical view
SOC, detection, and IR teams should validate that control-plane events showing deactivation or stopping of cloud services are collected and reviewed. MITRE examples include AWS CloudTrail StopLogging, Azure Monitor Logs disablement, Google Cloud Logging disablement, and SaaS logging being stopped. Since ATT&CK provides no detection text, local detection engineering should focus on administrative actions that reduce monitoring coverage, especially changes to logging, audit, and operations telemetry services.
Likely telemetry
- Cloud control-plane audit events for service stop, disable, or deactivation actions
- Logging service configuration-change records
- Administrative identity activity associated with monitoring or logging changes
- Cloud or SaaS audit logs showing changes to audit, monitoring, or operations logging settings
- Change-management records or approvals for intentional logging disablement
Detection direction
- Validate that events for disabling or stopping logging services are themselves captured somewhere resilient enough to survive the change.
- Tune detections around high-risk administrative actions that reduce visibility, while accounting for approved maintenance or cost-management changes.
- Correlate logging-disable events with the identity, role, source, time window, and related configuration changes to distinguish authorized administration from suspicious visibility reduction.
- Identify blind spots where SaaS or cloud service logging can be disabled without central SOC visibility or without independent audit evidence.
Mitigation priorities
- Prioritize least-privilege access for roles that can stop, disable, or reconfigure logging and monitoring services.
- Require documented approval and change control for intentional logging disablement.
- Protect audit and monitoring configurations with separation of duties and periodic review.
- Ensure incident response plans account for possible gaps in cloud or SaaS logs when logging has been disabled.
- Use compliance evidence reviews to confirm that required cloud and SaaS logging remained enabled over the relevant period.
Analyst notes and limits
This object is a data component, not a technique, and no ATT&CK tactics, platforms, relationships, or detection guidance were supplied. The strongest defensive value is to use it as a coverage checklist item for cloud and SaaS visibility controls.
The supplied ATT&CK fields do not provide relationship context, specific detection logic, affected platforms beyond examples in the description, or evidence of active exploitation. Local cloud architecture, identity model, logging configuration, and change-management records are required to assess actual risk and coverage.
Cloud Service Disable
This data component refers to monitoring actions that deactivate or stop a cloud service in a cloud control plane. Examples include disabling essential logging services like AWS CloudTrail (`StopLogging` API call), Microsoft Azure Monitor Logs, or Google Cloud's Operations Suite (formerly Stackdriver). Disabling such services can hinder visibility into adversary activities within the cloud environment. Examples:
- AWS CloudTrail StopLogging: This action stops logging of API activity for a particular trail, effectively reducing the monitoring and visibility of AWS resources and activities. - Microsoft Azure Monitor Logs: Disabling these logs hinders the organization’s ability to detect anomalous activities and trace malicious actions. - Google Cloud Logging: Disabling cloud logging removes visibility into resource activity, preventing monitoring of service access or configuration changes. - SaaS Applications: Stopping logging removes visibility into user activities, such as email access or file downloads, enabling undetected malicious behavior.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.0 | Current bundle | 0142886811c8… |
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 DC0090Open 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.