AN0353: Analytic 0353
Direct modification of /etc/ssh/keys-
Analyst context for executives and security teams
This analytic matters because it points to persistence-enabling changes on ESXi hosts: modifying SSH authorized keys for a user or enabling SSH public key authentication through sshd_config. For security leaders, the key issue is not just the file change itself, but whether the organization can prove that administrative access paths on virtualization infrastructure are monitored, approved, and recoverable.
Executive priority
Treat this as a control-validation item for critical virtualization infrastructure. ESXi hosts often support important business services, so unauthorized SSH access configuration changes can complicate incident response, recovery, and audit defensibility. Leaders should ask whether ESXi SSH configuration changes are formally governed, logged, reviewed, and tied to change management evidence.
Technical view
The supplied ATT&CK analytic is for the ESXi platform and describes direct modification of /etc/ssh/keys-<user>/authorized_keys or enabling SSH in sshd_config to support public key authentication. Because ATT&CK provides no official detection logic or related techniques for this object, SOC and IR teams should validate whether they can observe and investigate file-level changes to these SSH-related paths, configuration changes enabling SSH/public key authentication, and the administrative account context associated with those changes.
Likely telemetry
- ESXi host configuration change records where available
- File integrity or file change monitoring for SSH key and SSH daemon configuration paths
- Administrative authentication and session logs for ESXi hosts
- Change management records for approved SSH or public key authentication changes
- Centralized logging from virtualization management and host management planes
Detection direction
- Validate that ESXi hosts generate or forward enough evidence to identify changes to authorized_keys and sshd_config.
- Compare observed SSH configuration changes against approved maintenance or break-glass workflows to reduce false positives from legitimate administration.
- Tune alerts around unauthorized, unexpected, or out-of-window modifications rather than relying only on the existence of SSH configuration changes.
- Check for blind spots where ESXi host logs are not centralized, file integrity monitoring is absent, or virtualization administrators can make local changes without independent audit evidence.
- Because no official ATT&CK detection text is supplied, detection engineering should document local assumptions, log sources, and test results.
Mitigation priorities
- Define and enforce an approved process for enabling SSH and public key authentication on ESXi hosts.
- Restrict administrative access to ESXi hosts and review who can modify SSH configuration or user key material.
- Use configuration baselines and periodic validation to identify drift in SSH-related settings.
- Ensure critical ESXi host logs and configuration-change evidence are retained centrally for incident response and compliance review.
- Integrate virtualization access changes with change management and privileged access review processes.
Analyst notes and limits
This Glexia take is based only on the supplied MITRE analytic object AN0353. The object identifies ESXi as the platform and describes SSH authorized key or sshd_config modification behavior, but it does not provide tactics, detection logic, mitigations, or relationship context. Local architecture, logging configuration, and administrative workflows determine how material this behavior is in a specific environment.
No official detection content, ATT&CK tactics, related techniques, adversary relationships, or external reporting were supplied. This assessment should not be interpreted as evidence of active exploitation, attribution, or confirmed detection coverage.
Analytic 0353
Direct modification of /etc/ssh/keys-
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 | 0bc8ff8a71f9… |
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 AN0353Open 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.