SSH Authorized Keys File Modification

The Secure Shell (SSH) authorized_keys file specifies which users are allowed to log into a server using public key authentication. Adversaries may modify it to maintain persistence on a victim host by adding their own public key(s).

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/12/22"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10The Secure Shell (SSH) authorized_keys file specifies which users are allowed to log into a server using public key
 11authentication. Adversaries may modify it to maintain persistence on a victim host by adding their own public key(s).
 12"""
 13from = "now-9m"
 14index = ["auditbeat-*", "logs-endpoint.events.*"]
 15language = "kuery"
 16license = "Elastic License v2"
 17name = "SSH Authorized Keys File Modification"
 18risk_score = 47
 19rule_id = "2215b8bd-1759-4ffa-8ab8-55c8e6b32e7f"
 20severity = "medium"
 21tags = [
 22    "Domain: Endpoint",
 23    "OS: Linux",
 24    "OS: macOS",
 25    "Use Case: Threat Detection",
 26    "Tactic: Lateral Movement",
 27    "Tactic: Persistence",
 28    "Data Source: Elastic Defend",
 29    "Resources: Investigation Guide",
 30]
 31timestamp_override = "event.ingested"
 32type = "new_terms"
 33
 34query = '''
 35event.category:file and event.type:(change or creation) and
 36 file.name:("authorized_keys" or "authorized_keys2" or "/etc/ssh/sshd_config" or "/root/.ssh") and
 37 not process.executable:
 38             (/Library/Developer/CommandLineTools/usr/bin/git or
 39              /usr/local/Cellar/maven/*/libexec/bin/mvn or
 40              /Library/Java/JavaVirtualMachines/jdk*.jdk/Contents/Home/bin/java or
 41              /usr/bin/vim or
 42              /usr/local/Cellar/coreutils/*/bin/gcat or
 43              /usr/bin/bsdtar or
 44              /usr/bin/nautilus or
 45              /usr/bin/scp or
 46              /usr/bin/touch or
 47              /var/lib/docker/* or
 48              /usr/bin/google_guest_agent or
 49              /opt/jc/bin/jumpcloud-agent or
 50              /opt/puppetlabs/puppet/bin/puppet or
 51              /usr/bin/chef-client
 52)
 53'''
 54note = """## Triage and analysis
 55
 56> **Disclaimer**:
 57> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 58
 59### Investigating SSH Authorized Keys File Modification
 60
 61SSH authorized_keys files are crucial for secure, password-less authentication, allowing users to log into servers using public keys. Adversaries exploit this by adding their keys, ensuring persistent access. The detection rule identifies unauthorized changes to these files, excluding benign processes, to flag potential threats, focusing on persistence and lateral movement tactics.
 62
 63### Possible investigation steps
 64
 65- Review the alert details to identify the specific file that was modified, focusing on "authorized_keys", "authorized_keys2", "/etc/ssh/sshd_config", or "/root/.ssh".
 66- Examine the process that triggered the alert by checking the process executable path to ensure it is not one of the benign processes listed in the exclusion criteria.
 67- Investigate the user account associated with the modification to determine if it is a legitimate user or potentially compromised.
 68- Check the timestamp of the file modification to correlate with any known user activity or scheduled tasks that might explain the change.
 69- Analyze recent login attempts and SSH connections to the server to identify any suspicious activity or unauthorized access.
 70- Review the contents of the modified authorized_keys file to identify any unfamiliar or unauthorized public keys that have been added.
 71- If unauthorized keys are found, remove them and consider resetting credentials or keys for affected accounts to prevent further unauthorized access.
 72
 73### False positive analysis
 74
 75- Development tools like git and maven may modify SSH authorized_keys files during legitimate operations. To prevent these from triggering alerts, add their paths to the exclusion list in the detection rule.
 76- System utilities such as vim and touch are often used by administrators to manually update authorized_keys files. Consider excluding these processes if they are part of regular maintenance activities.
 77- Automation tools like puppet and chef-client might update SSH configurations as part of their deployment scripts. Verify these changes are expected and exclude these processes if they are part of routine operations.
 78- Docker-related processes may alter SSH configurations when containers are being managed. If these changes are part of standard container operations, include the relevant paths in the exclusion list.
 79- Google Guest Agent and JumpCloud Agent might modify SSH settings as part of their management tasks. Confirm these actions are legitimate and exclude these processes if they align with normal system management activities.
 80
 81### Response and remediation
 82
 83- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
 84- Review the SSH authorized_keys file and remove any unauthorized or suspicious public keys that have been added.
 85- Change the passwords for all user accounts on the affected host to prevent adversaries from regaining access using compromised credentials.
 86- Conduct a thorough review of user accounts and permissions on the affected host to identify and disable any unauthorized accounts or privilege escalations.
 87- Restore the affected system from a known good backup if unauthorized changes are extensive or if the integrity of the system is in question.
 88- Implement additional monitoring on the affected host and network to detect any further unauthorized access attempts or suspicious activities.
 89- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected."""
 90
 91
 92[[rule.threat]]
 93framework = "MITRE ATT&CK"
 94[[rule.threat.technique]]
 95id = "T1098"
 96name = "Account Manipulation"
 97reference = "https://attack.mitre.org/techniques/T1098/"
 98[[rule.threat.technique.subtechnique]]
 99id = "T1098.004"
100name = "SSH Authorized Keys"
101reference = "https://attack.mitre.org/techniques/T1098/004/"
102
103
104
105[rule.threat.tactic]
106id = "TA0003"
107name = "Persistence"
108reference = "https://attack.mitre.org/tactics/TA0003/"
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111[[rule.threat.technique]]
112id = "T1021"
113name = "Remote Services"
114reference = "https://attack.mitre.org/techniques/T1021/"
115[[rule.threat.technique.subtechnique]]
116id = "T1021.004"
117name = "SSH"
118reference = "https://attack.mitre.org/techniques/T1021/004/"
119
120
121[[rule.threat.technique]]
122id = "T1563"
123name = "Remote Service Session Hijacking"
124reference = "https://attack.mitre.org/techniques/T1563/"
125[[rule.threat.technique.subtechnique]]
126id = "T1563.001"
127name = "SSH Hijacking"
128reference = "https://attack.mitre.org/techniques/T1563/001/"
129
130
131
132[rule.threat.tactic]
133id = "TA0008"
134name = "Lateral Movement"
135reference = "https://attack.mitre.org/tactics/TA0008/"
136
137[rule.new_terms]
138field = "new_terms_fields"
139value = ["host.id", "process.executable"]
140[[rule.new_terms.history_window_start]]
141field = "history_window_start"
142value = "now-10d"
...
toml

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

SSH authorized_keys files are crucial for secure, password-less authentication, allowing users to log into servers using public keys. Adversaries exploit this by adding their keys, ensuring persistent access. The detection rule identifies unauthorized changes to these files, excluding benign processes, to flag potential threats, focusing on persistence and lateral movement tactics.

  • Review the alert details to identify the specific file that was modified, focusing on "authorized_keys", "authorized_keys2", "/etc/ssh/sshd_config", or "/root/.ssh".
  • Examine the process that triggered the alert by checking the process executable path to ensure it is not one of the benign processes listed in the exclusion criteria.
  • Investigate the user account associated with the modification to determine if it is a legitimate user or potentially compromised.
  • Check the timestamp of the file modification to correlate with any known user activity or scheduled tasks that might explain the change.
  • Analyze recent login attempts and SSH connections to the server to identify any suspicious activity or unauthorized access.
  • Review the contents of the modified authorized_keys file to identify any unfamiliar or unauthorized public keys that have been added.
  • If unauthorized keys are found, remove them and consider resetting credentials or keys for affected accounts to prevent further unauthorized access.
  • Development tools like git and maven may modify SSH authorized_keys files during legitimate operations. To prevent these from triggering alerts, add their paths to the exclusion list in the detection rule.
  • System utilities such as vim and touch are often used by administrators to manually update authorized_keys files. Consider excluding these processes if they are part of regular maintenance activities.
  • Automation tools like puppet and chef-client might update SSH configurations as part of their deployment scripts. Verify these changes are expected and exclude these processes if they are part of routine operations.
  • Docker-related processes may alter SSH configurations when containers are being managed. If these changes are part of standard container operations, include the relevant paths in the exclusion list.
  • Google Guest Agent and JumpCloud Agent might modify SSH settings as part of their management tasks. Confirm these actions are legitimate and exclude these processes if they align with normal system management activities.
  • Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
  • Review the SSH authorized_keys file and remove any unauthorized or suspicious public keys that have been added.
  • Change the passwords for all user accounts on the affected host to prevent adversaries from regaining access using compromised credentials.
  • Conduct a thorough review of user accounts and permissions on the affected host to identify and disable any unauthorized accounts or privilege escalations.
  • Restore the affected system from a known good backup if unauthorized changes are extensive or if the integrity of the system is in question.
  • Implement additional monitoring on the affected host and network to detect any further unauthorized access attempts or suspicious activities.
  • Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected.

Related rules

to-top