DC0069: Cloud Service Modification
Cloud service modification refers to changes made to the configuration, settings, or data of a cloud service. These modifications can include administrative changes such as enabling or disabling features, altering permissions, or deleting critical components. Monitoring these changes is critical to detect potential misconfigurations or malicious activity. Examples:
- AWS Cloud Service Modifications: A user disables AWS CloudTrail logging (StopLogging) or deletes a CloudWatch configuration rule (DeleteConfigRule). - Azure Cloud Service Modifications: Changes to Azure Role-Based Access Control (RBAC) roles, such as adding a new Contributor role to a sensitive resource. - Google Cloud Service Modifications: Deletion of a Google Cloud Storage bucket or disabling a Google Cloud Function. - Office 365 Cloud Service Modifications: Altering mailbox permissions or disabling auditing in Microsoft 365.
Analyst context for executives and security teams
Cloud Service Modification is a high-value audit and detection signal because it captures changes to cloud services that can weaken visibility, alter access, remove resources, or change business-critical configurations. For leaders, the practical issue is not just whether cloud services are monitored, but whether the organization can prove who changed what, when, and whether the change was authorized.
Executive priority
Prioritize this data component as evidence for cloud governance, incident decision-making, and audit readiness. Changes such as disabling logging, modifying RBAC roles, deleting configuration rules, removing storage, disabling functions, or altering mailbox permissions can affect resilience and investigation capability. Executives should ask whether sensitive cloud services have change monitoring, approval context, retention, and escalation paths before an incident requires those answers.
Technical view
SOC, detection, cloud security, and IR teams should validate that administrative and configuration changes are captured for relevant cloud services. The supplied ATT&CK examples include AWS CloudTrail StopLogging, AWS DeleteConfigRule, Azure RBAC role changes, Google Cloud Storage bucket deletion, Google Cloud Function disabling, and Microsoft 365 mailbox permission or auditing changes. Since ATT&CK provides no specific detection logic for this component, teams should map local cloud audit sources to high-risk service modification events and correlate them with identity, authorization, change-management, and asset criticality context.
Likely telemetry
- Cloud provider audit logs for administrative and configuration changes
- Identity and access management events tied to the actor making the change
- Cloud logging or monitoring configuration changes, including logging disabled or rules deleted
- Cloud resource lifecycle events such as deletion or disabling of services
- RBAC or permission change records for sensitive resources
Detection direction
- Confirm that audit logging remains enabled and monitored for cloud service configuration changes, especially changes that reduce logging, monitoring, or access control visibility.
- Create priority logic for modifications affecting sensitive resources, privileged roles, mailbox permissions, storage, serverless functions, and cloud monitoring controls.
- Correlate service modifications with the requesting identity, role, source context, affected resource, and approved change record to separate expected administration from suspicious activity.
- Tune for common false positives from planned maintenance, automated deployment pipelines, and infrastructure-as-code activity, while ensuring those activities are attributable and approved.
- Identify blind spots where cloud service changes are logged in provider-specific audit sources but are not forwarded to the SIEM, retained long enough for IR, or enriched with asset criticality.
Mitigation priorities
- Establish cloud change governance for sensitive services, including approval, accountability, and review of administrative modifications.
- Protect logging, monitoring, and audit configurations from unauthorized disablement or deletion through least privilege and separation of duties.
- Ensure critical cloud audit logs are centrally collected, retained, and protected from alteration.
- Review privileged roles and service permissions regularly, especially permissions that allow modifying audit, RBAC, mailbox, storage, or serverless configurations.
- Use compliance and incident response requirements to define which cloud service modification events must generate alerts, cases, or periodic evidence reports.
Analyst notes and limits
This data component is most useful as a coverage and evidence checkpoint: can the team reconstruct material cloud configuration changes and determine whether they were authorized? The official object provides examples across AWS, Azure, Google Cloud, and Office 365, but does not provide platform metadata, tactics, techniques, relationships, or detection analytics. Local cloud architecture and identity design are required to prioritize which modifications are most material.
No ATT&CK detection text, tactics, platforms, or relationships were supplied for this object. This take is therefore limited to the official description, examples, and external reference, and should not be interpreted as evidence of active exploitation, specific adversary behavior, or guaranteed detection coverage.
Cloud Service Modification
Cloud service modification refers to changes made to the configuration, settings, or data of a cloud service. These modifications can include administrative changes such as enabling or disabling features, altering permissions, or deleting critical components. Monitoring these changes is critical to detect potential misconfigurations or malicious activity. Examples:
- AWS Cloud Service Modifications: A user disables AWS CloudTrail logging (StopLogging) or deletes a CloudWatch configuration rule (DeleteConfigRule). - Azure Cloud Service Modifications: Changes to Azure Role-Based Access Control (RBAC) roles, such as adding a new Contributor role to a sensitive resource. - Google Cloud Service Modifications: Deletion of a Google Cloud Storage bucket or disabling a Google Cloud Function. - Office 365 Cloud Service Modifications: Altering mailbox permissions or disabling auditing in Microsoft 365.
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 | 5c790eb6480b… |
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 DC0069Open 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.