SSH Key Generated via ssh-keygen

This rule identifies the creation of SSH keys using the ssh-keygen tool, which is the standard utility for generating SSH keys. Users often create SSH keys for authentication with remote services. However, threat actors can exploit this tool to move laterally across a network or maintain persistence by generating unauthorized SSH keys, granting them SSH access to systems.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/05/31"
  3integration = ["endpoint", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule identifies the creation of SSH keys using the ssh-keygen tool, which is the standard utility for generating
 13SSH keys. Users often create SSH keys for authentication with remote services. However, threat actors can exploit this
 14tool to move laterally across a network or maintain persistence by generating unauthorized SSH keys, granting them SSH
 15access to systems.
 16"""
 17from = "now-9m"
 18index = ["logs-endpoint.events.file*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 19language = "eql"
 20license = "Elastic License v2"
 21name = "SSH Key Generated via ssh-keygen"
 22references = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"]
 23risk_score = 21
 24rule_id = "7df3cb8b-5c0c-4228-b772-bb6cd619053c"
 25severity = "low"
 26tags = [
 27    "Domain: Endpoint",
 28    "OS: Linux",
 29    "Use Case: Threat Detection",
 30    "Tactic: Lateral Movement",
 31    "Tactic: Persistence",
 32    "Data Source: Elastic Endgame",
 33    "Data Source: Elastic Defend",
 34    "Data Source: SentinelOne",
 35    "Resources: Investigation Guide",
 36]
 37timestamp_override = "event.ingested"
 38type = "eql"
 39
 40query = '''
 41file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and
 42process.executable == "/usr/bin/ssh-keygen" and file.path : ("/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*") and
 43not file.name : "known_hosts.*"
 44'''
 45note = """## Triage and analysis
 46
 47> **Disclaimer**:
 48> 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.
 49
 50### Investigating SSH Key Generated via ssh-keygen
 51
 52SSH keys, created using the ssh-keygen tool, are essential for secure authentication in Linux environments. While typically used for legitimate access to remote systems, adversaries can exploit this by generating unauthorized keys, enabling lateral movement or persistence. The detection rule identifies suspicious key creation by monitoring specific directories and actions, helping to flag potential misuse by threat actors.
 53
 54### Possible investigation steps
 55
 56- Review the alert details to identify the specific file path and name where the SSH key was created, focusing on directories like "/home/*/.ssh/*", "/root/.ssh/*", and "/etc/ssh/*".
 57- Check the user account associated with the SSH key creation event to determine if the action aligns with expected behavior for that user.
 58- Investigate the process execution context by examining the process tree and parent processes of "/usr/bin/ssh-keygen" to identify any potentially suspicious activity leading to the key generation.
 59- Analyze recent login and access logs for the user and system involved to detect any unusual or unauthorized access patterns.
 60- Correlate the event with other security alerts or logs to identify if there are signs of lateral movement or persistence tactics being employed by a threat actor.
 61- Verify the legitimacy of the SSH key by consulting with the system owner or user to confirm if the key creation was authorized and necessary.
 62
 63### False positive analysis
 64
 65- Routine administrative tasks may trigger the rule when system administrators generate SSH keys for legitimate purposes. To manage this, create exceptions for specific user accounts or directories known to be used by trusted administrators.
 66- Automated scripts or configuration management tools that regularly generate SSH keys for system provisioning or maintenance can cause false positives. Identify these scripts and exclude their associated processes or file paths from the rule.
 67- Development environments where developers frequently create SSH keys for testing or deployment purposes might be flagged. Consider excluding directories or user accounts associated with these environments to reduce noise.
 68- Backup or recovery processes that involve SSH key generation can also trigger alerts. Review these processes and exclude relevant file paths or processes to prevent unnecessary alerts.
 69- Security tools or monitoring solutions that simulate SSH key generation for testing or validation purposes may be mistakenly flagged. Identify these tools and add exceptions for their activities to avoid false positives.
 70
 71### Response and remediation
 72
 73- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
 74- Revoke any unauthorized SSH keys found in the monitored directories (/home/*/.ssh/*, /root/.ssh/*, /etc/ssh/*) to cut off access for threat actors.
 75- Conduct a thorough review of user accounts and SSH key pairs on the affected system to identify and remove any unauthorized accounts or keys.
 76- Reset passwords and regenerate SSH keys for legitimate users to ensure that compromised credentials are not reused.
 77- Monitor network traffic and system logs for any signs of further unauthorized access attempts or suspicious activity related to SSH.
 78- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
 79- Implement additional monitoring and alerting for SSH key generation activities across the network to enhance detection of similar threats in the future."""
 80
 81
 82[[rule.threat]]
 83framework = "MITRE ATT&CK"
 84[[rule.threat.technique]]
 85id = "T1098"
 86name = "Account Manipulation"
 87reference = "https://attack.mitre.org/techniques/T1098/"
 88[[rule.threat.technique.subtechnique]]
 89id = "T1098.004"
 90name = "SSH Authorized Keys"
 91reference = "https://attack.mitre.org/techniques/T1098/004/"
 92
 93
 94
 95[rule.threat.tactic]
 96id = "TA0003"
 97name = "Persistence"
 98reference = "https://attack.mitre.org/tactics/TA0003/"
 99[[rule.threat]]
100framework = "MITRE ATT&CK"
101[[rule.threat.technique]]
102id = "T1021"
103name = "Remote Services"
104reference = "https://attack.mitre.org/techniques/T1021/"
105[[rule.threat.technique.subtechnique]]
106id = "T1021.004"
107name = "SSH"
108reference = "https://attack.mitre.org/techniques/T1021/004/"
109
110
111[[rule.threat.technique]]
112id = "T1563"
113name = "Remote Service Session Hijacking"
114reference = "https://attack.mitre.org/techniques/T1563/"
115[[rule.threat.technique.subtechnique]]
116id = "T1563.001"
117name = "SSH Hijacking"
118reference = "https://attack.mitre.org/techniques/T1563/001/"
119
120
121
122[rule.threat.tactic]
123id = "TA0008"
124name = "Lateral Movement"
125reference = "https://attack.mitre.org/tactics/TA0008/"
...
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 keys, created using the ssh-keygen tool, are essential for secure authentication in Linux environments. While typically used for legitimate access to remote systems, adversaries can exploit this by generating unauthorized keys, enabling lateral movement or persistence. The detection rule identifies suspicious key creation by monitoring specific directories and actions, helping to flag potential misuse by threat actors.

  • Review the alert details to identify the specific file path and name where the SSH key was created, focusing on directories like "/home//.ssh/", "/root/.ssh/", and "/etc/ssh/".
  • Check the user account associated with the SSH key creation event to determine if the action aligns with expected behavior for that user.
  • Investigate the process execution context by examining the process tree and parent processes of "/usr/bin/ssh-keygen" to identify any potentially suspicious activity leading to the key generation.
  • Analyze recent login and access logs for the user and system involved to detect any unusual or unauthorized access patterns.
  • Correlate the event with other security alerts or logs to identify if there are signs of lateral movement or persistence tactics being employed by a threat actor.
  • Verify the legitimacy of the SSH key by consulting with the system owner or user to confirm if the key creation was authorized and necessary.
  • Routine administrative tasks may trigger the rule when system administrators generate SSH keys for legitimate purposes. To manage this, create exceptions for specific user accounts or directories known to be used by trusted administrators.
  • Automated scripts or configuration management tools that regularly generate SSH keys for system provisioning or maintenance can cause false positives. Identify these scripts and exclude their associated processes or file paths from the rule.
  • Development environments where developers frequently create SSH keys for testing or deployment purposes might be flagged. Consider excluding directories or user accounts associated with these environments to reduce noise.
  • Backup or recovery processes that involve SSH key generation can also trigger alerts. Review these processes and exclude relevant file paths or processes to prevent unnecessary alerts.
  • Security tools or monitoring solutions that simulate SSH key generation for testing or validation purposes may be mistakenly flagged. Identify these tools and add exceptions for their activities to avoid false positives.
  • Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
  • Revoke any unauthorized SSH keys found in the monitored directories (/home//.ssh/, /root/.ssh/, /etc/ssh/) to cut off access for threat actors.
  • Conduct a thorough review of user accounts and SSH key pairs on the affected system to identify and remove any unauthorized accounts or keys.
  • Reset passwords and regenerate SSH keys for legitimate users to ensure that compromised credentials are not reused.
  • Monitor network traffic and system logs for any signs of further unauthorized access attempts or suspicious activity related to SSH.
  • Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
  • Implement additional monitoring and alerting for SSH key generation activities across the network to enhance detection of similar threats in the future.

References

Related rules

to-top