SSH Authorized Keys
Where this stands
One published detection covers this technique. Every one is unverified — no rule on Siemphony has been executed against real telemetry.
What the technique is
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). 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. 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. […]
Read it on attack.mitre.orgWhat MITRE says you would watch
- AN0350
Adversary attempts to gain persistence by modifying ~/.ssh/authorized_keys via shell, text editor, echo or redirected output.
- AN0351
Insertion of public keys into authorized_keys using bash/zsh or editor tools, correlated with suspicious process ancestry.
- AN0352
Abuse of cloud metadata APIs or CLI to push SSH public keys to authorized_keys of virtual machines.
Technique names and descriptions © MITRE ATT&CK®, CC BY 4.0. Not endorsed by MITRE.