AN1636: Analytic 1636
Detects exploitation of IaaS cloud security boundaries to evade defense controls. Defender perspective includes anomalous API calls that bypass audit logging, disable monitoring, or manipulate guardrails (e.g., CloudTrail tampering). Correlation highlights when exploitation attempts precede sudden absence of expected telemetry.
Analyst context for executives and security teams
This analytic matters because it focuses on attempts to weaken or bypass IaaS cloud security boundaries, especially actions that interfere with audit logging, monitoring, or guardrails. For executives and security leaders, the key risk is not just a suspicious cloud API call; it is the possibility that an incident becomes harder to investigate because expected telemetry suddenly disappears or becomes unreliable.
Executive priority
Treat this as a cloud resilience and assurance issue. Leaders should ask whether IaaS audit logging, monitoring, and guardrail controls are independently validated, whether the SOC can recognize loss of expected telemetry, and whether incident response plans account for cloud events where logging may have been tampered with or suppressed. This is also relevant to compliance evidence because gaps in audit trails can weaken investigation timelines and control attestations.
Technical view
The supplied ATT&CK object describes an IaaS-focused detection analytic for anomalous API calls that bypass audit logging, disable monitoring, or manipulate security guardrails, with special attention to cases where those actions precede a sudden absence of expected telemetry. SOC and detection teams should validate whether cloud control-plane activity, logging configuration changes, monitoring disablement, and guardrail modification events are collected and correlated with telemetry drop-offs. No tactic or relationship context is supplied, so implementation should be mapped to the organization’s own IaaS logging architecture and cloud control baseline.
Likely telemetry
- IaaS cloud control-plane API activity
- Audit logging configuration changes
- Monitoring or security service disablement events
- Guardrail or policy modification events
- Expected-versus-observed telemetry volume or heartbeat signals
Detection direction
- Correlate sensitive IaaS API calls with subsequent absence or reduction of expected audit or monitoring telemetry.
- Baseline normal logging, monitoring, and guardrail administration so legitimate maintenance can be distinguished from suspicious timing or scope.
- Tune for privileged cloud administrative actions affecting auditability, especially when followed by telemetry gaps.
- Validate that the SOC can alert on missing expected cloud logs, not only on explicit error or disablement events.
- Review false positives from planned configuration changes, security tooling migrations, or authorized maintenance windows.
Mitigation priorities
- Prioritize durable IaaS audit logging and monitoring coverage for cloud control-plane activity.
- Restrict and review permissions that can disable logging, monitoring, or guardrails.
- Establish change-control evidence for authorized modifications to cloud security controls.
- Use independent checks or health monitoring to confirm expected telemetry continues to arrive.
- Ensure incident response playbooks address suspected audit logging or monitoring tampering in IaaS environments.
Analyst notes and limits
The object is a detection analytic, not a technique or campaign report. It provides a clear defender perspective around IaaS security boundary exploitation and telemetry loss, but it does not provide a formal detection query, tactic mapping, adversary relationship, or platform detail beyond IaaS. Local cloud architecture and logging design will determine how this should be implemented.
Official detection content is not provided, and no relationships are supplied. This take therefore avoids claims about specific adversaries, active exploitation, guaranteed detection, or coverage beyond IaaS. Validation requires environment-specific evidence of collected API activity, monitoring state, guardrail changes, and expected telemetry continuity.
Analytic 1636
Detects exploitation of IaaS cloud security boundaries to evade defense controls. Defender perspective includes anomalous API calls that bypass audit logging, disable monitoring, or manipulate guardrails (e.g., CloudTrail tampering). Correlation highlights when exploitation attempts precede sudden absence of expected telemetry.
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.0 | Current bundle | a4d2d968bad7… |
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 AN1636Open 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.