MITRE ATT&CK® Technique

T1098.004: SSH Authorized Keys

Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions, macOS, and ESXi hypervisors commonly use key-based authentication to secure the authentication process of SSH sessions for remote management. The authorized_keys file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured. This file is usually found in the user's home directory under <user-home>/.ssh/authorized_keys (or, on ESXi, `/etc/ssh/keys-/authorized_keys`).[1] Users may edit the system’s SSH config file to modify the directives `PubkeyAuthentication` and `RSAAuthentication` to the value `yes` to ensure public key and RSA authentication are enabled, as well as modify the directive `PermitRootLogin` to the value `yes` to enable root authentication via SSH.[2] The SSH config file is usually located under /etc/ssh/sshd_config.

Adversaries may modify SSH authorized_keys files directly with scripts or shell commands to add their own adversary-supplied public keys. In cloud environments, adversaries may be able to modify the SSH authorized_keys file of a particular virtual machine via the command line interface or rest API. For example, by using the Google Cloud CLI’s “add-metadata” command an adversary may add SSH keys to a user account.[3][4] Similarly, in Azure, an adversary may update the authorized_keys file of a virtual machine via a PATCH request to the API.[5] This ensures that an adversary possessing the corresponding private key may log in as an existing user via SSH.[6][7] It may also lead to privilege escalation where the virtual machine or instance has distinct permissions from the requesting user.

Where authorized_keys files are modified via cloud APIs or command line interfaces, an adversary may achieve privilege escalation on the target virtual machine if they add a key to a higher-privileged user.

SSH keys can also be added to accounts on network devices, such as with the `ip ssh pubkey-chain` Network Device CLI command.[8]

EnterpriseT1098.004Sub-techniqueObject v1.4 Modified May 12, 2026, 15:12 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

SSH authorized_keys changes matter because they can turn a normal remote administration mechanism into durable access for an intruder. If an unauthorized public key is added to a user, root, ESXi, cloud VM, or network device account, the holder of the matching private key may be able to return without knowing the account password. For leaders, the business issue is not just SSH hygiene; it is whether critical Linux, macOS, ESXi, IaaS, and network-device administration paths have accountable change control and evidence.

Executive priority

Prioritize this where SSH is used for administration of critical servers, hypervisors, cloud instances, or network infrastructure. This technique sits under Account Manipulation and supports persistence and privilege escalation, so it affects incident containment decisions: rotating passwords alone may not remove access if unauthorized keys remain. Executives should ask whether authorized_keys and SSH configuration changes are monitored, whether cloud API paths that update VM keys are governed, and whether privileged accounts have clear ownership, lifecycle controls, and audit evidence.

Technical view

SOC, detection engineering, and IR teams should validate coverage for unauthorized modification of authorized_keys files and SSH configuration across the supplied platforms: Linux, macOS, ESXi, IaaS, and network devices. Key paths and settings called out by ATT&CK include user home .ssh/authorized_keys, ESXi /etc/ssh/keys-<username>/authorized_keys, and /etc/ssh/sshd_config directives such as PubkeyAuthentication, RSAAuthentication, and PermitRootLogin. In cloud environments, also review audit trails for VM metadata or API update paths that can add SSH keys. On network devices, review configuration changes that add SSH public keys. Treat this as account manipulation: confirm which account was changed, who or what made the change, whether the key is approved, and whether the target account has higher privileges than the requester.

Likely telemetry

File integrity or endpoint telemetry for authorized_keys and sshd_config creation, modification, ownership, and permission changes
Linux, macOS, and ESXi authentication logs showing SSH logins, user context, source addresses, and key-based authentication where available
Process or shell command telemetry showing local edits to SSH key or SSH daemon configuration files
Cloud control-plane audit logs for VM metadata changes, instance update actions, CLI activity, and REST API requests that can add or modify SSH keys
Network device configuration logs or command accounting for SSH public-key configuration changes

Detection direction

Because no official ATT&CK detection text is supplied for this object, validate local detection logic against the related detection strategy DET0126: Detection Strategy for SSH Key Injection in Authorized Keys, if available in the defensive content library.
Baseline approved SSH keys for privileged and service accounts; alert on new, replaced, or unexpected keys, especially for root, administrative users, ESXi users, cloud VM users, and network-device accounts.
Correlate file changes with authenticated administrator activity, change tickets, cloud API caller identity, and subsequent SSH logins. A file change alone may be administrative maintenance; a key addition followed by unusual remote access is higher priority.
Include cloud control-plane paths, not only host file monitoring. ATT&CK explicitly notes that cloud CLI or REST API changes can update VM authorized_keys.
Include ESXi and network devices in scope where SSH is enabled; these are common blind spots if detection is focused only on Linux servers.

Mitigation priorities

Apply User Account Management: maintain ownership, approval, lifecycle review, and removal processes for SSH-capable accounts and keys, especially privileged accounts.
Restrict File and Directory Permissions: ensure SSH key files and SSH configuration are writable only by appropriate users or administrators, and review ownership and permission drift.
Disable or Remove Feature or Program where appropriate: disable SSH or key-based/root SSH access where it is not required for business operations, particularly on exposed or high-value systems.
For cloud VMs, govern who can update instance metadata or VM configuration that affects SSH access, and require reviewable administrative paths for key changes.
For incident containment, remove unauthorized keys, review SSH configuration changes, validate cloud/API changes, and then assess whether the affected account or VM privileges enabled broader access.

Analyst notes and limits

ATT&CK relationships show this behavior as a sub-technique of Account Manipulation and associate it with persistence and privilege escalation. The relationship set also includes observed use by multiple groups, software entries, and a campaign, which supports defensive prioritization but should not be interpreted as attribution in a local incident without additional evidence.

The supplied ATT&CK object does not provide an official detection description, and the relationship context provides only the name of DET0126 rather than its full analytic content. This take therefore focuses on validation areas and telemetry classes derived from the official description, platforms, tactics, mitigations, and relationships. Actual priority depends on where SSH, ESXi, cloud VM key management, and network-device SSH keys are used in the local environment.

Official MITRE ATT&CK definition

SSH Authorized Keys

SSH keys can also be added to accounts on network devices, such as with the `ip ssh pubkey-chain` Network Device CLI command.[8]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1098	Account Manipulation	This object subtechnique of Account Manipulation.

Associated objects

Groups, software, and campaigns

G1006: Earth Lusca

Earth Lusca is a suspected China-based cyber espionage group that has been active since at least April 2019. Earth Lusca has targeted organizations in Australia, China, Hong Kong, Mongolia, Nepal, the Philippines, Taiwan, Thailand, Vietnam, the United Arab Emirates, Nigeria, Germany, France, and the United States. Targets included government institutions, news media outlets, gambling companies, educational institutions, COVID-19 research organizations, telecommunications companies, religious movements banned in China, and cryptocurrency trading platforms; security researchers assess some Earth Lusca operations may be financially motivated.[1]

Earth Lusca has used malware commonly used by other Chinese threat groups, including APT41 and the Winnti Group cluster, however security researchers assess Earth Lusca's techniques and infrastructure are separate.[1]

G1045: Salt Typhoon

Salt Typhoon is a People's Republic of China (PRC) state-backed actor that has been active since at least 2019 and responsible for numerous compromises of network infrastructure at major U.S. telecommunication and internet service providers (ISP).[1][2]

G0139: TeamTNT

TeamTNT is a threat group that has primarily targeted cloud and containerized environments. The group as been active since at least October 2019 and has mainly focused its efforts on leveraging cloud and container resources to deploy cryptocurrency miners in victim environments.[1][2][3][4][5][6][7][8][9]

S0468: Skidmap

Skidmap is a kernel-mode rootkit used for cryptocurrency mining.[1]

Linux

S0658: XCSSET

XCSSET is a modular macOS malware family delivered through infected Xcode projects and executed when the project is compiled. Active since August 2020, it has been observed installing backdoors, spoofed browsers, collecting data, and encrypting user files. It is composed of SHC-compiled shell scripts and run-only AppleScripts, often hiding in apps that mimic system tools (such as Xcode, Mail, or Notes) or use familiar icons (like Launchpad) to avoid detection.[1][2][3]

macOS

S0482: Bundlore

Bundlore is adware written for macOS that has been in use since at least 2015. Though categorized as adware, Bundlore has many features associated with more traditional backdoors.[1]

macOS

C0061: Operation Digital Eye

Operation Digital Eye was conducted in June and July of 2024 by suspected People's Republic of China (PRC)-nexus threat actors targeting business-to-business IT service providers in Southern Europe. Operation Digital Eye activity included the use of Visual Studio Code tunnels for command and control (C2) and custom lateral movement capabilities. Overlaps in tooling between Digital Eye and previous China-nexus campaigns, Operation Soft Cell and Operation Tainted Love, indicate the potential use of shared vendors or digital quartermasters.[1]

Relationship explorer

All related ATT&CK context

uses · Group G1006: Earth Lusca Enterprise uses · Malware S0468: Skidmap Enterprise mitigates · Mitigation M1018: User Account Management Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise uses · Group G1045: Salt Typhoon Enterprise uses · Malware S0658: XCSSET Enterprise uses · Malware S0482: Bundlore Enterprise subtechnique of · Technique T1098: Account Manipulation Enterprise mitigates · Mitigation M1042: Disable or Remove Feature or Program Enterprise detects · Detection Strategy DET0126: Detection Strategy for SSH Key Injection in Authorized Keys Enterprise uses · Campaign C0061: Operation Digital Eye Enterprise uses · Group G0139: TeamTNT Enterprise

Mitigations

Mitigation direction

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

M1022: Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions:

- Remove unnecessary write permissions on sensitive files and directories. - Use file ownership and groups to control access for specific roles.

Example (Windows): Right-click the shared folder → Properties → Security tab → Adjust permissions for NTFS ACLs.

Harden File Shares:

- Disable anonymous access to shared folders. - Enforce NTFS permissions for shared folders on Windows.

Example: Set permissions to restrict write access to critical files, such as system executables (e.g., `/bin` or `/sbin` on Linux). Use tools like `chown` and `chmod` to assign file ownership and limit access.

On Linux, apply: `chmod 750 /etc/sensitive.conf` `chown root:admin /etc/sensitive.conf`

File Integrity Monitoring (FIM):

- Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access:

- Enable auditing to track permission changes or unauthorized access attempts. - Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories:

- Configure permissions to prevent unauthorized writes to directories like `C:\ProgramData\Microsoft\Windows\Start Menu`.

Example: Restrict write access to critical directories like `/etc/`, `/usr/local/`, and Windows directories such as `C:\Windows\System32`.

- On Windows, use icacls to modify permissions: `icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F` - On Linux, monitor permissions using tools like `lsattr` or `auditd`.

M1042: Disable or Remove Feature or Program

Disable or remove unnecessary and potentially vulnerable software, features, or services to reduce the attack surface and prevent abuse by adversaries. This involves identifying software or features that are no longer needed or that could be exploited and ensuring they are either removed or properly disabled. This mitigation can be implemented through the following measures:

Remove Legacy Software:

- Use Case: Disable or remove older versions of software that no longer receive updates or security patches (e.g., legacy Java, Adobe Flash). - Implementation: A company removes Flash Player from all employee systems after it has reached its end-of-life date.

Disable Unused Features:

- Use Case: Turn off unnecessary operating system features like SMBv1, Telnet, or RDP if they are not required. - Implementation: Disable SMBv1 in a Windows environment to mitigate vulnerabilities like EternalBlue.

Control Applications Installed by Users:

- Use Case: Prevent users from installing unauthorized software via group policies or other management tools. - Implementation: Block user installations of unauthorized file-sharing applications (e.g., BitTorrent clients) in an enterprise environment.

Remove Unnecessary Services:

- Use Case: Identify and disable unnecessary default services running on endpoints, servers, or network devices. - Implementation: Disable unused administrative shares (e.g., C$, ADMIN$) on workstations.

Restrict Add-ons and Plugins:

- Use Case: Remove or disable browser plugins and add-ons that are not needed for business purposes. - Implementation: Disable Java and ActiveX plugins in web browsers to prevent drive-by attacks.

Change history

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 .

ATT&CK release: 19.1
Object version: 1.4
Created: Jun 24, 2020, 12:42 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 5e3e4693324052bd...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.4	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`5e3e46933240…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
SSH Authorized Keys

ssh.com. (n.d.). Authorized_keys File in SSH. Retrieved June 24, 2020.
Open source URL
[2]
Broadcom ESXi SSH

Broadcom. (2024, December 12). Allowing SSH access to VMware vSphere ESXi/ESX hosts with public/private key authentication. Retrieved March 26, 2025.
Open source URL
[3]
Google Cloud Add Metadata

Google Cloud. (2022, March 31). gcloud compute instances add-metadata. Retrieved April 1, 2022.
Open source URL
[4]
Google Cloud Privilege Escalation

Chris Moberly. (2020, February 12). Tutorial on privilege escalation and post exploitation tactics in Google Cloud Platform environments. Retrieved April 1, 2022.
Open source URL
[5]
Azure Update Virtual Machines

Microsoft. (n.d.). Virtual Machines - Update. Retrieved April 1, 2022.
Open source URL
[6]
Venafi SSH Key Abuse

Blachman, Y. (2020, April 22). Growing Abuse of SSH Keys: Commodity Malware Campaigns Now Equipped with SSH Capabilities. Retrieved June 24, 2020.
Open source URL
[7]
Cybereason Linux Exim Worm

Cybereason Nocturnus. (2019, June 13). New Pervasive Worm Exploiting Linux Exim Server Vulnerability. Retrieved June 24, 2020.
Open source URL
[8]
cisco_ip_ssh_pubkey_ch_cmd

Cisco. (2021, August 23). ip ssh pubkey-chain. Retrieved July 13, 2022.
Open source URL
[9]
mitre-attack T1098.004
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use