AN0545: Analytic 0545
Detects API calls to cloud secrets/MFA configurations where MFA enforcement policies are disabled or bypassed.
Analyst context for executives and security teams
This analytic matters because changes or API activity around cloud secrets and MFA enforcement can weaken two core business controls: privileged access protection and protection of sensitive credentials. For executives and security leaders, the practical question is whether the organization can prove that cloud MFA and secrets-related policy changes are visible, reviewed, and investigated before they become an incident response problem.
Executive priority
Prioritize this as a cloud identity and access governance validation item for IaaS environments. The business value is strongest for resilience, audit evidence, and incident decision-making: leaders should ask whether cloud API activity that disables or bypasses MFA enforcement for secrets-related configurations is logged, retained, alerted on, and tied to an accountable change process.
Technical view
SOC, cloud security, and IR teams should validate visibility into IaaS API calls involving cloud secrets and MFA configuration enforcement. Because the ATT&CK object provides no detailed detection logic, teams should focus on confirming the relevant API event sources, identifying policy-change events that disable or bypass MFA enforcement, and distinguishing authorized administrative changes from suspicious or unapproved activity.
Likely telemetry
- IaaS cloud control-plane API logs
- Cloud identity and access management audit logs
- Secrets-management configuration and access logs
- MFA policy configuration change records
- Administrative change-management or ticketing evidence for approved exceptions
Detection direction
- Validate that API calls affecting cloud secrets and MFA enforcement policies are collected and searchable.
- Alert or review events where MFA enforcement is disabled, bypassed, or materially weakened for secrets-related configurations.
- Tune detections against approved administrative maintenance to reduce false positives while preserving visibility into emergency or out-of-band changes.
- Correlate policy-change events with actor identity, source location, role used, time of change, and change-approval evidence.
- Treat missing telemetry as a coverage gap because the official analytic does not provide detection logic or compensating signals.
Mitigation priorities
- Maintain MFA enforcement for privileged and secrets-related cloud operations wherever applicable.
- Restrict who can modify secrets and MFA enforcement configurations using least privilege.
- Require change approval and documentation for MFA enforcement exceptions or policy weakening.
- Retain cloud API and IAM audit logs long enough to support investigations and compliance evidence.
- Periodically review cloud secrets and MFA policy configurations for drift from approved baselines.
Analyst notes and limits
This is a detection analytic object, not a technique or procedure. Its decision value is in validating cloud control-plane visibility around secrets and MFA enforcement changes in IaaS environments. With no supplied relationships or tactic mapping, analysts should avoid inferring attacker stage, actor behavior, or specific cloud provider implementation details.
The official object supplies only a brief description, IaaS platform scope, and an external reference. No detection logic, data component list, relationships, tactics, or mitigations were provided, so local cloud architecture and logging evidence are required to operationalize it.
Analytic 0545
Detects API calls to cloud secrets/MFA configurations where MFA enforcement policies are disabled or bypassed.
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 | f8da0516b82c… |
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 AN0545Open 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.