AN1372: Analytic 1372
Correlates control-plane API actions disabling cloud-native monitoring or sensor agents (CloudTrail, GuardDuty, Security Hub, Defender, monitoring agents), role abuse preceding disablement, or instance agent uninstall events
Analyst context for executives and security teams
AN1372 is a cloud detection analytic focused on a high-value defensive question: can the organization see when cloud monitoring, security services, or sensor agents are being disabled? For executives and security leaders, this matters because loss of cloud visibility can delay incident response, weaken audit evidence, and reduce confidence in business continuity decisions during a cloud security event.
Executive priority
Treat this as a control-assurance analytic for IaaS environments. Leaders should ask whether disabling CloudTrail, GuardDuty, Security Hub, Defender, monitoring agents, or instance agents creates an immediate alert, whether the action can be tied to the responsible role or identity, and whether response teams have enough evidence to distinguish approved administration from suspicious visibility reduction.
Technical view
SOC, cloud security, and IR teams should validate correlation across cloud control-plane API activity, identity or role activity preceding disablement, and instance-level agent uninstall events. Because the object provides no ATT&CK tactic and no official detection logic, implementation should be locally engineered around audit logs and endpoint or workload telemetry that record service disablement, configuration changes, and agent removal in IaaS environments.
Likely telemetry
- Cloud control-plane API audit logs for monitoring and security service disablement
- Identity and access activity showing role use or role abuse preceding disablement
- Configuration-change events for cloud-native monitoring or security services
- Instance or workload telemetry showing sensor or monitoring agent uninstall events
- Administrative change records or tickets to validate approved maintenance
Detection direction
- Confirm that disabling or modifying cloud-native monitoring and security services is logged and alertable.
- Correlate disablement events with the identity, role, session, and recent privileged actions that preceded them.
- Tune for authorized maintenance to reduce false positives, but require evidence such as change tickets or approved automation.
- Look for blind spots where instance-level agent removal is not visible in cloud control-plane logs alone.
- Validate coverage separately for each IaaS environment and security service in use, since the ATT&CK object does not provide vendor-specific logic.
Mitigation priorities
- Restrict who can disable cloud logging, monitoring, security services, or sensor agents.
- Require change control and approval for visibility-impacting actions.
- Preserve independent audit logging for control-plane events where possible.
- Review privileged roles that can alter monitoring or security services.
- Test incident response procedures for scenarios where cloud visibility is intentionally or accidentally reduced.
Analyst notes and limits
This analytic is most useful as a resilience and assurance check: if monitoring can be disabled without prompt detection, investigation quality and audit defensibility may degrade. The supplied relationship context is empty, so no specific ATT&CK technique, tactic, adversary behavior, or campaign context should be inferred.
The official object provides a description but no official detection logic, no tactic, no relationships, and only the IaaS platform scope. Local cloud architecture, enabled services, identity model, logging configuration, and change-management data are required to turn this into a reliable production analytic.
Analytic 1372
Correlates control-plane API actions disabling cloud-native monitoring or sensor agents (CloudTrail, GuardDuty, Security Hub, Defender, monitoring agents), role abuse preceding disablement, or instance agent uninstall events
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 | 1.1 | Current bundle | 259b290ed8c1… |
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 AN1372Open 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.