AWS SSM SendCommand Execution by Rare User

  1[metadata]
  2creation_date = "2020/07/06"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2024/11/05"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as `RunShellScript`,
 11`RunPowerShellScript` or custom documents. While legitimate users may employ these commands for management tasks, they
 12can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells
 13for further access to compromised instances. This is a [New
 14Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that looks for
 15the first instance of this behavior by the `aws.cloudtrail.user_identity.arn` field in the last 7 days.
 16"""
 17false_positives = [
 18    """
 19    Verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
 20    Suspicious commands from unfamiliar users or hosts should be investigated. If known behavior is causing false
 21    positives, it can be exempted from the rule.
 22    """,
 23]
 24from = "now-9m"
 25index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "AWS SSM `SendCommand` Execution by Rare User"
 29note = """## Triage and Analysis
 30
 31### Investigating AWS SSM `SendCommand` Execution by Rare User
 32
 33This rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells.
 34
 35#### Possible Investigation Steps
 36
 37- **Identify the Target Instance**:
 38  - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.targets` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM.
 39  - **Document Used**: Check the `aws.cloudtrail.flattened.request_parameters.documentName` field, which specifies the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions.
 40
 41- **Review User Context**:
 42  - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access.
 43  - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior.
 44
 45- **Analyze Command Parameters**:
 46  - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities.
 47  - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack.
 48
 49- **Check User Agent and Source IP**:
 50  - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually.
 51  - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries.
 52
 53- **Evaluate for Persistence Indicators**:
 54  - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access.
 55  - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions.
 56
 57- **Correlate with Other CloudTrail Events**:
 58  - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation.
 59  - **Monitor Data Access or Modification**: Correlate with `S3` access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities.
 60
 61### False Positive Analysis
 62
 63- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows.
 64- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances.
 65
 66### Response and Remediation
 67
 68- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access.
 69- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration.
 70- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary.
 71- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place.
 72
 73### Additional Information
 74
 75For further details on managing AWS SSM and security best practices for EC2 instances, refer to the [AWS Systems Manager Documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html) and AWS best practices.
 76"""
 77references = ["https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html"]
 78risk_score = 21
 79rule_id = "37b211e8-4e2f-440f-86d8-06cc8f158cfa"
 80severity = "low"
 81tags = [
 82    "Domain: Cloud",
 83    "Data Source: AWS",
 84    "Data Source: Amazon Web Services",
 85    "Data Source: AWS SSM",
 86    "Use Case: Log Auditing",
 87    "Use Case: Threat Detection",
 88    "Tactic: Execution",
 89    "Resources: Investigation Guide",
 90]
 91timestamp_override = "event.ingested"
 92type = "new_terms"
 93
 94query = '''
 95event.dataset: "aws.cloudtrail"
 96    and event.provider: "ssm.amazonaws.com"
 97    and event.action: "SendCommand"
 98    and event.outcome: "success"
 99    and not aws.cloudtrail.user_identity.arn: *AWSServiceRoleForAmazonSSM/StateManagerService*
100'''
101
102
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105[[rule.threat.technique]]
106id = "T1651"
107name = "Cloud Administration Command"
108reference = "https://attack.mitre.org/techniques/T1651/"
109
110
111[rule.threat.tactic]
112id = "TA0002"
113name = "Execution"
114reference = "https://attack.mitre.org/tactics/TA0002/"
115
116[rule.new_terms]
117field = "new_terms_fields"
118value = ["aws.cloudtrail.user_identity.arn"]
119[[rule.new_terms.history_window_start]]
120field = "history_window_start"
121value = "now-7d"