SSM Session Started to EC2 Instance

  1[metadata]
  2creation_date = "2024/04/16"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2024/07/23"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the first occurrence of an AWS resource establishing a session via SSM to an EC2 instance. Adversaries may
 11use AWS Systems Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used
 12to gain access to the instance and perform actions such as privilege escalation. This rule helps detect the first
 13occurrence of this activity for a given AWS resource.
 14"""
 15false_positives = ["Legitimate use of AWS Systems Manager to establish a session to an EC2 instance."]
 16from = "now-60m"
 17index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 18interval = "10m"
 19language = "kuery"
 20license = "Elastic License v2"
 21name = "SSM Session Started to EC2 Instance"
 22note = """## Triage and Analysis
 23
 24### Investigating SSM Session Started to EC2 Instance
 25
 26This rule detects the first instance of an AWS resource initiating an SSM session to an EC2 instance, which could be indicative of legitimate administrative activities or potential malicious actions like command execution or lateral movement.
 27
 28#### Possible Investigation Steps
 29
 30- **Examine the Session Start Event**: Review the AWS CloudTrail log for the event.
 31    - Look for the `StartSession` action and verify details such as the `user_identity.arn`, `event.action`, and the target EC2 instance (`aws.cloudtrail.flattened.request_parameters`).
 32- **Verify User Identity and Role**: Check the user’s ARN and access key ID (`aws.cloudtrail.user_identity.access_key_id`).
 33    - Cross-reference this with IAM to verify if the user had the necessary permissions and if their role typically requires initiating SSM sessions.
 34- **Assess Geographic and IP Context**: Analyze the source IP (`source.ip`) and geographic location (`source.geo`) from which the session was initiated.
 35    - Determine if these are consistent with typical user locations or if they raise suspicions of compromise or misuse.
 36- **Review Session Details**: Examine details like the session ID and stream URL (`aws.cloudtrail.flattened.response_elements`) to understand the scope and nature of the session.
 37    - Check if any commands executed during the session were unauthorized or out of ordinary practices.
 38- **Correlate with Other Security Events**: Look for other related security events around the time of the session start to identify any pattern or broader attack vector that may involve this user or EC2 instance.
 39
 40### False Positive Analysis
 41
 42- **Legitimate Administrative Activities**: Confirm whether the SSM session was initiated for valid administrative purposes such as system maintenance, patching, or configuration updates. Verify with the respective teams or personnel.
 43
 44### Response and Remediation
 45
 46- **Immediate Session Review**: If the session initiation seems suspicious, review all actions taken during the session.
 47    - If possible, terminate the session to prevent any potential harm.
 48- **Validate and Reinforce Security Policies**: Ensure that policies around SSM session initiation are strict and adhere to the principle of least privilege.
 49    - Update IAM policies if necessary to tighten controls.
 50- **Incident Response Activation**: If malicious intent or actions are confirmed, activate the incident response protocol.
 51    - This includes containment of the threat, eradication of the adversary’s presence, recovery of affected systems, and a thorough investigation.
 52- **Enhance Monitoring and Alerts**: Improve monitoring of SSM sessions, particularly focusing on sessions that involve sensitive or critical EC2 instances.
 53    - Adjust alerting mechanisms to flag unusual session initiations promptly.
 54
 55### Additional Information
 56
 57For more in-depth understanding of managing SSM sessions and security best practices, refer to the [AWS Systems Manager documentation](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html). Additionally, consider the security implications and best practices outlined in [AWS SSM privilege escalation techniques](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc).
 58
 59"""
 60references = [
 61    "https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html",
 62    "https://hackingthe.cloud/aws/post_exploitation/intercept_ssm_communications/",
 63]
 64risk_score = 47
 65rule_id = "804a7ac8-fc00-11ee-924b-f661ea17fbce"
 66severity = "medium"
 67tags = [
 68    "Domain: Cloud",
 69    "Data Source: AWS",
 70    "Data Source: Amazon Web Services",
 71    "Data Source: AWS SSM",
 72    "Use Case: Threat Detection",
 73    "Tactic: Lateral Movement",
 74]
 75timestamp_override = "event.ingested"
 76type = "new_terms"
 77
 78query = '''
 79event.dataset:"aws.cloudtrail" and event.provider:"ssm.amazonaws.com"
 80    and event.action:"StartSession" and event.outcome:"success"
 81'''
 82
 83
 84[[rule.threat]]
 85framework = "MITRE ATT&CK"
 86[[rule.threat.technique]]
 87id = "T1021"
 88name = "Remote Services"
 89reference = "https://attack.mitre.org/techniques/T1021/"
 90[[rule.threat.technique.subtechnique]]
 91id = "T1021.007"
 92name = "Cloud Services"
 93reference = "https://attack.mitre.org/techniques/T1021/007/"
 94
 95
 96
 97[rule.threat.tactic]
 98id = "TA0008"
 99name = "Lateral Movement"
100reference = "https://attack.mitre.org/tactics/TA0008/"
101
102[rule.new_terms]
103field = "new_terms_fields"
104value = ["aws.cloudtrail.user_identity.arn"]
105[[rule.new_terms.history_window_start]]
106field = "history_window_start"
107value = "now-10d"