DET0126: Detection Strategy for SSH Key Injection in Authorized Keys
This detection strategy matters because SSH authorized_keys changes can turn a normal remote administration mechanism into durable unauthorized access. For...
Analyst context for executives and security teams
This detection strategy matters because SSH authorized_keys changes can turn a normal remote administration mechanism into durable unauthorized access. For leaders, the practical question is whether the organization can prove who is allowed to add SSH keys, where those changes occur, and whether SOC or IR teams would notice suspicious key additions before they become a persistence or privilege-escalation problem.
Executive priority
Prioritize this as an identity and remote-access control validation item for environments that use SSH, especially the related ATT&CK technique scope of Linux, macOS, ESXi, and IaaS. The business value is auditability and containment readiness: teams should be able to distinguish approved administrative key management from unauthorized persistence, preserve evidence during incidents, and show that privileged remote access changes are monitored and governed.
Technical view
The supplied detection strategy object has no official detection text and no direct platform or tactic fields. Its relationship indicates it detects T1098.004, SSH Authorized Keys, associated with persistence and privilege escalation across ESXi, IaaS, Linux, and macOS. SOC and detection engineering teams should therefore validate monitoring around SSH authorized_keys file changes, account context, administrative change workflows, and subsequent SSH authentication activity. IR teams should be ready to review whether newly observed keys align with approved users, change tickets, automation, or configuration management.
Likely telemetry
- File integrity or endpoint telemetry for authorized_keys creation, modification, permission changes, and ownership changes
- Operating system audit logs covering user, file, and privilege context around SSH key file changes
- SSH authentication logs showing successful or failed key-based logins after key changes
- Identity and access management records for account ownership, privileged access approvals, and administrator activity
- Configuration management, change management, or automation logs that may explain legitimate key deployment
Detection direction
- Validate that monitoring covers authorized_keys paths for relevant user accounts, including privileged and service accounts, not only interactive end users.
- Correlate file changes with approved administrative activity to reduce false positives from normal provisioning, break-glass access, or configuration management.
- Look for timing relationships between key file modification and subsequent SSH logins, especially where the modifying account and authenticating account differ.
- Review coverage for related environments named by ATT&CK: Linux, macOS, ESXi, and IaaS. The detection object itself does not specify platforms, so local scoping is required.
- Tune detections to preserve context: username, host, file path, key material metadata where policy allows, process or tool responsible for the change, and remote login source.
Mitigation priorities
- Establish ownership and approval processes for SSH key creation, rotation, and removal.
- Restrict write access to SSH authorization files and privileged accounts to approved administrators and automation.
- Use configuration management or baseline comparison to identify unauthorized key drift.
- Ensure logging is enabled and retained for file changes, SSH authentication, privileged activity, and cloud/IaaS administrative actions where applicable.
- Include SSH key review in incident response playbooks, privileged access reviews, and compliance evidence collection.
Analyst notes and limits
This take is based on ATT&CK DET0126 and its relationship to T1098.004 SSH Authorized Keys. Because the official detection strategy description and detection text are not supplied, the guidance is framed as validation direction rather than a claim of specific MITRE-provided analytics.
The detection strategy object does not specify platforms, tactics, aliases, labels, official description, or official detection logic. Platform and tactic context comes only from the related ATT&CK technique. Local environment architecture, SSH usage, logging configuration, and administrative workflows are required to determine actual detection coverage and priority.
Detection Strategy for SSH Key Injection in Authorized Keys
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1098.004 | SSH Authorized Keys Sub-technique | This object detects SSH Authorized Keys. |
All related ATT&CK context
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 | 21d7b47020f4… |
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 DET0126Open 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.