AN0352: Analytic 0352
Abuse of cloud metadata APIs or CLI to push SSH public keys to authorized_keys of virtual machines.
Analyst context for executives and security teams
AN0352 describes a cloud/IaaS behavior where cloud metadata APIs or CLI mechanisms are abused to place SSH public keys into a virtual machine’s authorized_keys file. For leaders, the practical risk is unauthorized or poorly governed administrative access to cloud-hosted systems, which can affect incident containment, identity assurance, and operational resilience if SSH access paths are not logged, reviewed, and controlled.
Executive priority
Treat this as a cloud access governance and incident readiness issue. Security leaders should ask whether teams can prove who is allowed to modify VM SSH access, whether metadata and CLI-based key changes are logged, and whether SOC/IR playbooks distinguish approved automation from suspicious access changes. The priority is strongest in IaaS environments where SSH remains a privileged management path.
Technical view
The supplied object is a detection analytic for IaaS, but MITRE provides no official detection logic and no relationship context. SOC and detection engineering teams should validate visibility around cloud API or CLI actions that modify VM SSH key material and host-side changes to authorized_keys. IR teams should be able to correlate a key insertion event with the actor, source identity, cloud role or permission path, affected VM, and subsequent SSH activity.
Likely telemetry
- Cloud control-plane audit logs for API or CLI actions affecting VM metadata or SSH key configuration
- Identity and access logs for the cloud principal performing the change
- Host filesystem or endpoint telemetry showing authorized_keys modification
- SSH authentication logs from affected virtual machines
- Change-management or automation records for expected key rotation and provisioning activity
Detection direction
- Baseline legitimate automation that provisions or rotates SSH keys so alerts can focus on unexpected principals, unusual timing, unusual source locations, or unapproved target VMs.
- Correlate control-plane key changes with host-side authorized_keys writes and subsequent SSH logins to reduce ambiguity.
- Validate whether cloud audit logging is enabled for metadata or VM configuration changes; this is a likely blind spot if only network or host logs are monitored.
- Review false positives from provisioning pipelines, configuration management, break-glass access, and administrator maintenance activity.
- Because no official MITRE detection is provided, local detections should be tested against the organization’s actual IaaS logging, IAM model, and SSH administration process.
Mitigation priorities
- Limit who can modify VM metadata or SSH key configuration through cloud IAM and least-privilege access controls.
- Require approved change workflows for SSH key provisioning, rotation, and emergency access.
- Monitor and review privileged cloud API or CLI use that can affect VM access paths.
- Harden VM access practices by minimizing unmanaged SSH keys and regularly auditing authorized_keys contents where applicable.
- Ensure incident response procedures include rapid validation and removal of unauthorized SSH keys from affected virtual machines.
Analyst notes and limits
This take is based only on the supplied ATT&CK analytic fields. The object identifies the behavior and IaaS platform, but does not specify tactics, mapped techniques, detections, mitigations, or relationships. The most useful operational interpretation is therefore centered on cloud control-plane visibility, IAM governance, and host-level SSH access validation.
MITRE supplied no official detection text and no relationship context for this analytic. The assessment should not be read as evidence of active exploitation, attribution, impact, or existing detection coverage. Local cloud provider features, logging configuration, VM image standards, and SSH management practices are required to determine real exposure and coverage.
Analytic 0352
Abuse of cloud metadata APIs or CLI to push SSH public keys to authorized_keys of virtual machines.
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 | ab676f0dcc40… |
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 AN0352Open 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.