AN0350: Analytic 0350
Adversary attempts to gain persistence by modifying ~/.ssh/authorized_keys via shell, text editor, echo or redirected output.
Analyst context for executives and security teams
This analytic is about a common Linux persistence risk: an attacker adding or changing SSH authorized keys for a user account so they can return without using the original access path. For leaders, the practical issue is whether the organization can prove who is allowed to use key-based SSH access and whether changes to that trust file are visible quickly enough for incident response.
Executive priority
Prioritize this where Linux servers support critical operations, administration, cloud workloads, or regulated systems. The business decision is not just “detect a file change,” but whether identity governance, server hardening, and SOC telemetry can validate that SSH trust relationships are expected, approved, and auditable. This is especially relevant for continuity and incident decision-making because unauthorized key persistence can survive password resets if key access is not reviewed.
Technical view
Validate monitoring for Linux modifications to user-level SSH authorized_keys files, especially ~/.ssh/authorized_keys, when changes are made through shells, text editors, echo-style writes, or redirected output. Because the official object provides no detection logic, teams should build local detection around file integrity events, process/file write correlations, and account context. Triage should distinguish normal administrator key management from unexpected writes by unusual users, interactive shells, automation accounts, or processes outside approved configuration workflows.
Likely telemetry
- Linux file integrity or endpoint telemetry for writes, creates, permission changes, and ownership changes involving ~/.ssh/authorized_keys
- Process execution telemetry showing shells, text editors, or command-line output redirection associated with SSH key file modification
- User/account context for the owning account and the process performing the modification
- SSH authentication and session logs to correlate subsequent key-based access after a change
- Change management or configuration management records for approved SSH key updates
Detection direction
- Confirm telemetry captures user-home SSH key file changes on Linux systems, not only system-level SSH configuration changes.
- Correlate file modification events with the responsible process and user to separate approved administration from suspicious persistence behavior.
- Tune for environment-specific baselines such as configuration management, break-glass administration, and developer workflows that legitimately update authorized_keys.
- Review blind spots on ephemeral hosts, cloud images, containers with persistent volumes, and systems where home directories are not covered by file integrity monitoring.
- Because no official detection is supplied, treat this analytic as a validation target rather than a complete detection rule.
Mitigation priorities
- Maintain approved processes for SSH key provisioning, rotation, and removal, including ownership by IAM or server administration teams.
- Restrict who can modify user SSH trust files and enforce least privilege on Linux administrative access.
- Use configuration or file integrity controls to detect and, where appropriate, revert unauthorized authorized_keys changes.
- Include SSH key review in incident response playbooks, especially after suspected Linux account compromise.
- Retain sufficient endpoint, authentication, and change-control evidence to support audit and post-incident reconstruction.
Analyst notes and limits
The object is a detection analytic for Linux and describes adversary persistence through modification of ~/.ssh/authorized_keys. No ATT&CK tactic field, relationship context, or official detection logic was supplied, so this take focuses on defensive validation and evidence requirements rather than a specific rule or confirmed coverage.
This summary is limited to the supplied ATT&CK fields and external reference. It does not assert active exploitation, attribution, prevalence, impact, or guaranteed detection. Local system roles, approved SSH key workflows, and available telemetry are required to determine severity and tune detections.
Analytic 0350
Adversary attempts to gain persistence by modifying ~/.ssh/authorized_keys via shell, text editor, echo or redirected output.
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 | 0ff6045dcad2… |
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 AN0350Open 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.