Detecting and Mitigating SSH Authorized Keys Abuse (T1098.004)

A single line added to a text file can give an attacker a permanent way in. MITRE ATT&CK tracks this as SSH Authorized Keys (T1098.004), a sub-technique of Account Manipulation. It maps to persistence and privilege escalation and applies to ESXi, IaaS, Linux, macOS and Network Devices.

How attackers use it

MITRE explains that Linux distributions, macOS and ESXi hypervisors commonly use key based authentication for SSH. The authorized_keys file lists the public keys that may log in to the account it belongs to. It is usually found at .ssh/authorized_keys in the user's home directory, or on ESXi under /etc/ssh/keys-USERNAME/authorized_keys. The SSH config file, usually /etc/ssh/sshd_config, controls related settings such as PubkeyAuthentication and PermitRootLogin, and MITRE notes these may be edited to enable key authentication or root login.

Adversaries may edit authorized_keys directly with scripts or shell commands to add their own public keys. In cloud environments they may modify the file for a particular virtual machine through the command line or REST API. MITRE's examples are the Google Cloud CLI add-metadata command, and, in Azure, a PATCH request to the API. Anyone holding the matching private key can then log in as that existing user.

If the key lands on a higher privileged user, or on a VM with different permissions from the requester, this can also be privilege escalation.

The key survives password resets, which is why it is a favorite persistence method.

How to detect it

MITRE's strategy (DET0126) lists:

• Changes to ~/.ssh/authorized_keys through a shell, text editor, echo or redirected output.
• Insertion of public keys with bash, zsh or editor tools, correlated with suspicious process ancestry.
• Abuse of cloud metadata APIs or CLI to push SSH public keys to the authorized_keys of virtual machines.
• Direct modification of the ESXi keys files, or enabling SSH in sshd_config to support public key authentication.
• On routers and switches, use of commands such as ip ssh pubkey-chain to bind SSH keys to privileged accounts.

Practical sources: file integrity monitoring or auditd rules on authorized_keys files, cloud audit logs for instance metadata changes, and configuration change logging on network devices. A baseline helps: record the expected keys for each privileged account and diff regularly.

How to reduce the risk

MITRE lists three mitigations:

1. Disable SSH where it is not needed, or restrict SSH access for specific users and groups in /etc/ssh/sshd_config. Setting PermitRootLogin to no prevents root login over SSH (Disable or Remove Feature or Program).
2. Restrict access to the authorized_keys file (Restrict File and Directory Permissions).
3. In cloud environments, make sure only users who explicitly need to update instance metadata or configuration can do so (User Account Management).

Check your own environment

• Do you know whose keys are in every privileged account's authorized_keys?
• Which cloud identities may change instance metadata or SSH key settings?
• Is root login over SSH disabled?
• Are authorized_keys changes monitored?

On Linux, read-only checks:

sshd -T | grep -i -E 'permitrootlogin|pubkeyauthentication'
ls -l /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys

Use sudo if needed to read other users' directories. Review the comment and fingerprint of each key with ssh-keygen -lf FILE, and match each to a person.

Try it yourself

Spotting an unexpected change against a known baseline is the heart of monitoring. This demo shows continuous monitoring flagging change over time.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK, T1098.004 SSH Authorized Keys: https://attack.mitre.org/techniques/T1098/004/