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"
Triage and analysis
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.
Investigating SSH Authorized Keys File Modification
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.
Possible investigation steps
- 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.
False positive analysis
- 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.
Response and remediation
- 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
- Bash Shell Profile Modification
- Modification of Standard Authentication Module or Configuration
- SSH Key Generated via ssh-keygen
- AWS SSM `SendCommand` with Run Shell Command Parameters
- At Job Created or Modified