SSH Authorized Keys File Modified Inside a Container

This rule detects the creation or modification of an authorized_keys or sshd_config 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"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects the creation or modification of an authorized_keys or sshd_config file inside a container. The Secure
 11Shell (SSH) authorized_keys file specifies which users are allowed to log into a server using public key authentication.
 12Adversaries may modify it to maintain persistence on a victim host by adding their own public key(s). Unexpected and
 13unauthorized SSH usage inside a container can be an indicator of compromise and should be investigated.
 14"""
 15from = "now-6m"
 16index = ["logs-cloud_defend*"]
 17interval = "5m"
 18language = "eql"
 19license = "Elastic License v2"
 20name = "SSH Authorized Keys File Modified Inside a Container"
 21risk_score = 73
 22rule_id = "f7769104-e8f9-4931-94a2-68fc04eadec3"
 23severity = "high"
 24tags = [
 25    "Data Source: Elastic Defend for Containers",
 26    "Domain: Container",
 27    "OS: Linux",
 28    "Use Case: Threat Detection",
 29    "Tactic: Persistence",
 30    "Tactic: Lateral Movement",
 31    "Resources: Investigation Guide",
 32]
 33timestamp_override = "event.ingested"
 34type = "eql"
 35
 36query = '''
 37file where container.id:"*" and
 38  event.type in ("change", "creation") and file.name: ("authorized_keys", "authorized_keys2", "sshd_config")
 39'''
 40note = """## Triage and analysis
 41
 42> **Disclaimer**:
 43> 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.
 44
 45### Investigating SSH Authorized Keys File Modified Inside a Container
 46
 47In 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 configuration files within containers, signaling potential persistence tactics. By monitoring file modifications, it helps detect unauthorized SSH usage, a common indicator of compromise.
 48
 49### Possible investigation steps
 50
 51- Review the container ID associated with the alert to identify the specific container where the modification occurred.
 52- 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.
 53- Investigate the user account or process that made the modification to the authorized_keys or sshd_config file to assess if it was an authorized action.
 54- Check for any recent SSH connections to the container, especially those using public key authentication, to identify potential unauthorized access.
 55- Analyze the contents of the modified authorized_keys or sshd_config file to identify any suspicious or unauthorized keys or configurations.
 56- Review the container's logs and any related network activity around the time of the modification for signs of compromise or lateral movement attempts.
 57
 58### False positive analysis
 59
 60- 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.
 61- 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.
 62- 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.
 63- 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.
 64- 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.
 65
 66### Response and remediation
 67
 68- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment.
 69- Revoke any unauthorized SSH keys found in the authorized_keys file to cut off the adversary's access.
 70- Conduct a thorough review of all SSH configuration files within the container to ensure no additional unauthorized modifications have been made.
 71- Restore the container from a known good backup if available, ensuring that the backup does not contain the unauthorized changes.
 72- Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future.
 73- Escalate the incident to the security operations team for further investigation and to determine if other containers or systems have been compromised.
 74- Update detection and alerting mechanisms to include additional indicators of compromise related to SSH key manipulation and unauthorized access attempts."""
 75
 76
 77[[rule.threat]]
 78framework = "MITRE ATT&CK"
 79[[rule.threat.technique]]
 80id = "T1098"
 81name = "Account Manipulation"
 82reference = "https://attack.mitre.org/techniques/T1098/"
 83[[rule.threat.technique.subtechnique]]
 84id = "T1098.004"
 85name = "SSH Authorized Keys"
 86reference = "https://attack.mitre.org/techniques/T1098/004/"
 87
 88
 89
 90[rule.threat.tactic]
 91id = "TA0003"
 92name = "Persistence"
 93reference = "https://attack.mitre.org/tactics/TA0003/"
 94[[rule.threat]]
 95framework = "MITRE ATT&CK"
 96[[rule.threat.technique]]
 97id = "T1021"
 98name = "Remote Services"
 99reference = "https://attack.mitre.org/techniques/T1021/"
100[[rule.threat.technique.subtechnique]]
101id = "T1021.004"
102name = "SSH"
103reference = "https://attack.mitre.org/techniques/T1021/004/"
104
105
106[[rule.threat.technique]]
107id = "T1563"
108name = "Remote Service Session Hijacking"
109reference = "https://attack.mitre.org/techniques/T1563/"
110[[rule.threat.technique.subtechnique]]
111id = "T1563.001"
112name = "SSH Hijacking"
113reference = "https://attack.mitre.org/techniques/T1563/001/"
114
115
116
117[rule.threat.tactic]
118id = "TA0008"
119name = "Lateral Movement"
120reference = "https://attack.mitre.org/tactics/TA0008/"

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 Modified Inside a Container

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 configuration 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 or sshd_config 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 or sshd_config file to identify any suspicious or unauthorized keys or configurations.
  • 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