SSH Authorized Key File Activity Detected via Defend for Containers

This rule detects the creation or modification of an authorized_keys file inside a container. 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). Unexpected and unauthorized SSH usage inside a container can be an indicator of compromise and should be investigated.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/05/12"
  3integration = ["cloud_defend"]
  4maturity = "production"
  5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
  6min_stack_version = "9.3.0"
  7updated_date = "2026/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the creation or modification of an authorized_keys file inside a container. The Secure Shell (SSH)
 13authorized_keys file specifies which users are allowed to log into a server using public key authentication. Adversaries
 14may modify it to maintain persistence on a victim host by adding their own public key(s). Unexpected and unauthorized SSH
 15usage inside a container can be an indicator of compromise and should be investigated.
 16"""
 17from = "now-6m"
 18index = ["logs-cloud_defend.file*"]
 19interval = "5m"
 20language = "eql"
 21license = "Elastic License v2"
 22name = "SSH Authorized Key File Activity Detected via Defend for Containers"
 23note = """## Setup
 24
 25## Triage and analysis
 26
 27> **Disclaimer**:
 28> 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.
 29
 30### Investigating SSH Authorized Key File Activity Detected via Defend for Containers
 31
 32In containerized environments, SSH keys facilitate secure access, but adversaries can exploit this by altering the authorized_keys file to gain unauthorized access. This detection rule identifies suspicious changes to SSH authorized_keys files within containers, signaling potential persistence tactics. By monitoring file modifications, it helps detect unauthorized SSH usage, a common indicator of compromise.
 33
 34### Possible investigation steps
 35
 36- Review the container ID associated with the alert to identify the specific container where the modification occurred.
 37- Examine the timestamp of the event to determine when the file change or creation took place and correlate it with any known activities or changes in the environment.
 38- Investigate the user account or process that made the modification to the authorized_keys file to assess if it was an authorized action.
 39- Check for any recent SSH connections to the container, especially those using public key authentication, to identify potential unauthorized access.
 40- Analyze the contents of the modified authorized_keys file to identify any suspicious or unauthorized keys.
 41- Review the container's logs and any related network activity around the time of the modification for signs of compromise or lateral movement attempts.
 42
 43### False positive analysis
 44
 45- Routine updates or deployments within containers may modify SSH configuration files, leading to false positives. To manage this, create exceptions for known update processes or deployment scripts that regularly alter these files.
 46- Automated configuration management tools like Ansible or Puppet might change SSH files as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process IDs or user accounts.
 47- Development or testing environments often see frequent changes to SSH keys for legitimate reasons. Consider excluding these environments from the rule or setting up a separate, less sensitive monitoring profile for them.
 48- Scheduled maintenance tasks that involve SSH key rotation can trigger alerts. Document these tasks and schedule exceptions during their execution windows to prevent unnecessary alerts.
 49- Container orchestration systems might modify SSH configurations as part of scaling or updating services. Recognize these patterns and adjust the rule to ignore changes made by these systems.
 50
 51### Response and remediation
 52
 53- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
 54- Revoke any unauthorized SSH keys found in the authorized_keys file to cut off the adversary's access.
 55- Conduct a thorough review of all SSH configuration files within the container to ensure no additional unauthorized modifications have been made.
 56- Restore the container from a known good backup if available, ensuring that the backup does not contain the unauthorized changes.
 57- Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future.
 58- Escalate the incident to the security operations team for further investigation and to determine if other containers or systems have been compromised.
 59- Update detection and alerting mechanisms to include additional indicators of compromise related to SSH key manipulation and unauthorized access attempts."""
 60risk_score = 47
 61rule_id = "f7769104-e8f9-4931-94a2-68fc04eadec3"
 62severity = "medium"
 63tags = [
 64    "Data Source: Elastic Defend for Containers",
 65    "Domain: Container",
 66    "OS: Linux",
 67    "Use Case: Threat Detection",
 68    "Tactic: Persistence",
 69    "Tactic: Lateral Movement",
 70    "Resources: Investigation Guide",
 71]
 72timestamp_override = "event.ingested"
 73type = "eql"
 74query = '''
 75file where host.os.type == "linux" and event.type in ("change", "creation") and
 76file.name in ("authorized_keys", "authorized_keys2") and
 77process.interactive == true and container.id like "*"
 78'''
 79
 80[[rule.threat]]
 81framework = "MITRE ATT&CK"
 82
 83[[rule.threat.technique]]
 84id = "T1098"
 85name = "Account Manipulation"
 86reference = "https://attack.mitre.org/techniques/T1098/"
 87
 88[[rule.threat.technique.subtechnique]]
 89id = "T1098.004"
 90name = "SSH Authorized Keys"
 91reference = "https://attack.mitre.org/techniques/T1098/004/"
 92
 93[rule.threat.tactic]
 94id = "TA0003"
 95name = "Persistence"
 96reference = "https://attack.mitre.org/tactics/TA0003/"
 97
 98[[rule.threat]]
 99framework = "MITRE ATT&CK"
100
101[[rule.threat.technique]]
102id = "T1021"
103name = "Remote Services"
104reference = "https://attack.mitre.org/techniques/T1021/"
105
106[[rule.threat.technique.subtechnique]]
107id = "T1021.004"
108name = "SSH"
109reference = "https://attack.mitre.org/techniques/T1021/004/"
110
111[[rule.threat.technique]]
112id = "T1563"
113name = "Remote Service Session Hijacking"
114reference = "https://attack.mitre.org/techniques/T1563/"
115
116[[rule.threat.technique.subtechnique]]
117id = "T1563.001"
118name = "SSH Hijacking"
119reference = "https://attack.mitre.org/techniques/T1563/001/"
120
121[rule.threat.tactic]
122id = "TA0008"
123name = "Lateral Movement"
124reference = "https://attack.mitre.org/tactics/TA0008/"

Setup

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 Key File Activity Detected via Defend for Containers

In containerized environments, SSH keys facilitate secure access, but adversaries can exploit this by altering the authorized_keys file to gain unauthorized access. This detection rule identifies suspicious changes to SSH authorized_keys files within containers, signaling potential persistence tactics. By monitoring file modifications, it helps detect unauthorized SSH usage, a common indicator of compromise.

Possible investigation steps

  • Review the container ID associated with the alert to identify the specific container where the modification occurred.
  • Examine the timestamp of the event to determine when the file change or creation took place and correlate it with any known activities or changes in the environment.
  • Investigate the user account or process that made the modification to the authorized_keys file to assess if it was an authorized action.
  • Check for any recent SSH connections to the container, especially those using public key authentication, to identify potential unauthorized access.
  • Analyze the contents of the modified authorized_keys file to identify any suspicious or unauthorized keys.
  • Review the container's logs and any related network activity around the time of the modification for signs of compromise or lateral movement attempts.

False positive analysis

  • Routine updates or deployments within containers may modify SSH configuration files, leading to false positives. To manage this, create exceptions for known update processes or deployment scripts that regularly alter these files.
  • Automated configuration management tools like Ansible or Puppet might change SSH files as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process IDs or user accounts.
  • Development or testing environments often see frequent changes to SSH keys for legitimate reasons. Consider excluding these environments from the rule or setting up a separate, less sensitive monitoring profile for them.
  • Scheduled maintenance tasks that involve SSH key rotation can trigger alerts. Document these tasks and schedule exceptions during their execution windows to prevent unnecessary alerts.
  • Container orchestration systems might modify SSH configurations as part of scaling or updating services. Recognize these patterns and adjust the rule to ignore changes made by these systems.

Response and remediation

  • Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
  • Revoke any unauthorized SSH keys found in the authorized_keys file to cut off the adversary's access.
  • Conduct a thorough review of all SSH configuration files within the container to ensure no additional unauthorized modifications have been made.
  • Restore the container from a known good backup if available, ensuring that the backup does not contain the unauthorized changes.
  • Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future.
  • Escalate the incident to the security operations team for further investigation and to determine if other containers or systems have been compromised.
  • Update detection and alerting mechanisms to include additional indicators of compromise related to SSH key manipulation and unauthorized access attempts.

Related rules

to-top