security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[Rule Tuning] Add Investigation Guides to AWS Rules (#4249)

Browse Source 
* adding investigation guides for existing AWS rules

* removing 'AWS EC2 Instance Interaction with IAM Service' rule tuning

* adding back newline

* adjusted mitre att&ck mapping

* adjusted query and rule name

* updating date
This commit is contained in:
Terrance DeJesus
2024-11-06 12:29:14 -05:00
committed by GitHub
parent c602042954
commit 1cc160fe2e
4 changed files with 237 additions and 124 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml
+53 -1
View File
@@ -2,7 +2,7 @@
creation_date = "2024/08/26"
integration = ["aws"]
maturity = "production"
updated_date = "2024/11/04"
updated_date = "2024/11/05"
[rule]
author = ["Elastic"]
@@ -12,10 +12,61 @@ window. This could indicate a potential threat actor attempting to discover the
regions using compromised credentials or a compromised instance. Adversaries may use this information to identify
potential targets for further exploitation or to gain a better understanding of the target's infrastructure.
"""
false_positives = [
"""
Legitimate use of the `DescribeInstances` API call by an AWS resource that requires information about instances in
multiple regions.
""",
"Scheduled tasks or scripts that require information about instances in multiple regions.",
]
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "AWS EC2 Multi-Region DescribeInstances API Calls"
note = """## Triage and Analysis
### Investigating AWS EC2 Multi-Region DescribeInstances API Calls
This rule detects instances where a single AWS resource makes `DescribeInstances` API calls in over 10 regions within a 30-second window. This could indicate an adversary using compromised credentials or an exploited resource to enumerate AWS infrastructure across multiple regions. Attackers often leverage multi-region enumeration to assess the overall cloud environment and find potential targets for further exploitation.
#### Possible Investigation Steps
- **Identify the Resource and Actor**:
- **Actor ARN**: Check `aws.cloudtrail.user_identity.arn` to determine the exact identity performing the enumeration. Validate if the user is expected to perform region-wide `DescribeInstances` actions across multiple regions or if it seems unusual.
- **Account and Role Details**: Examine `cloud.account.id` and `aws.cloudtrail.user_identity.session_context.session_issuer` for information about the AWS account and specific role associated with the action.
- **Analyze API Call Patterns**:
- **Frequency and Scope**: Review `cloud.region` field and confirm if this specific resource commonly performs `DescribeInstances` calls across multiple regions.
- **Time Window Context**: Compare the timing of the API calls within the `target_time_window` to determine if this burst pattern aligns with expected system usage or is potentially malicious.
- **Check User Agent and Tooling**:
- **Source and User Agent**: Verify `user_agent.original` to determine if the request was made through expected tooling (e.g., AWS CLI or SDK) or a third-party tool that might indicate non-standard access.
- **Source IP Address**: Look into `source.address` to identify the origin of the calls. Unusual IP addresses, especially those outside expected ranges, may indicate compromised access.
- **Evaluate for Potential Reconnaissance Behavior**:
- **Account and Region Enumeration**: Adversaries may use region-wide `DescribeInstances` requests to discover resources within an account across different regions. Confirm if this access aligns with operational practices or represents excessive access.
- **Permissions and Roles**: Investigate the permissions associated with the user role. Excessive permissions on a compromised role may allow broader enumeration, which should be restricted.
- **Review Related CloudTrail Events**:
- **Additional Describe or List Actions**: Identify any associated `Describe` or `List` API calls that may indicate further enumeration of other AWS services within the same timeframe.
- **Potential Preceding Events**: Look for preceding login or access events from the same actor, as these may indicate potential credential compromise or unauthorized escalation of privileges.
### False Positive Analysis
- **Expected Enumeration**: Certain administrative or automation scripts may conduct broad `DescribeInstances` API calls for inventory purposes. Review usage patterns or consult relevant teams to validate the purpose.
- **Automated Cloud Management**: Some automated services may perform regional checks for compliance or backup operations. If this rule is triggered repeatedly by a known service, consider whitelisting or tuning accordingly.
### Response and Remediation
- **Review IAM Policies and Role Permissions**: Limit the permissions of roles associated with this resource, restricting unnecessary multi-region enumeration access.
- **Enforce Least Privilege Access**: Ensure that permissions for DescribeInstances are tightly controlled and restricted to specific roles or accounts that require multi-region access.
- **Increase Monitoring and Alerts**: Set up additional monitoring on this role or account for further signs of unauthorized activity or lateral movement attempts.
- **Access Review**: Conduct a review of users and entities with `DescribeInstances` permissions, especially for multi-region capabilities, and ensure these permissions are necessary for their functions.
### Additional Information
For further information on AWS `DescribeInstances` permissions and best practices, refer to the [AWS DescribeInstances API documentation](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html).
"""
references = [
"https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/",
"https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html",
@@ -27,6 +78,7 @@ tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: AWS EC2",
"Resources: Investigation Guide",
"Use Case: Threat Detection",
"Tactic: Discovery",
]
rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml
+123
View File
@@ -0,0 +1,123 @@
[metadata]
creation_date = "2020/07/06"
integration = ["aws"]
maturity = "production"
updated_date = "2024/11/05"
[rule]
author = ["Elastic"]
description = """
Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as `RunShellScript`,
`RunPowerShellScript` or custom documents. While legitimate users may employ these commands for management tasks, they
can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells
for further access to compromised instances. This is a [New
Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that looks for
the first instance of this behavior by the `aws.cloudtrail.user_identity.arn` field in the last 7 days.
"""
false_positives = [
"""
Verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
Suspicious commands from unfamiliar users or hosts should be investigated. If known behavior is causing false
positives, it can be exempted from the rule.
""",
]
from = "now-9m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS SSM `SendCommand` Execution by Rare User"
note = """## Triage and Analysis
### Investigating AWS SSM `SendCommand` Execution by Rare User
This 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.
#### Possible Investigation Steps
- **Identify the Target Instance**:
- **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.
- **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.
- **Review User Context**:
- **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.
- **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.
- **Analyze Command Parameters**:
- **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.
- **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.
- **Check User Agent and Source IP**:
- **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.
- **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.
- **Evaluate for Persistence Indicators**:
- **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.
- **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.
- **Correlate with Other CloudTrail Events**:
- **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation.
- **Monitor Data Access or Modification**: Correlate with `S3` access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities.
### False Positive Analysis
- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows.
- **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.
### Response and Remediation
- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access.
- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration.
- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary.
- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place.
### Additional Information
For 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.
"""
references = ["https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html"]
risk_score = 21
rule_id = "37b211e8-4e2f-440f-86d8-06cc8f158cfa"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS SSM",
"Use Case: Log Auditing",
"Use Case: Threat Detection",
"Tactic: Execution",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.dataset: "aws.cloudtrail"
and event.provider: "ssm.amazonaws.com"
and event.action: "SendCommand"
and event.outcome: "success"
and not aws.cloudtrail.user_identity.arn: *AWSServiceRoleForAmazonSSM/StateManagerService*
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1651"
name = "Cloud Administration Command"
reference = "https://attack.mitre.org/techniques/T1651/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"
rules/integrations/aws/initial_access_via_system_manager.toml
-114
View File
@@ -1,114 +0,0 @@
[metadata]
creation_date = "2020/07/06"
integration = ["aws"]
maturity = "production"
updated_date = "2024/05/21"
[rule]
author = ["Elastic"]
description = """
Identifies the execution of commands and scripts via System Manager. Execution methods such as RunShellScript,
RunPowerShellScript, and alike can be abused by an authenticated attacker to install a backdoor or to interact with a
compromised instance via reverse-shell using system only commands.
"""
false_positives = [
"""
Verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
Suspicious commands from unfamiliar users or hosts should be investigated. If known behavior is causing false
positives, it can be exempted from the rule.
""",
]
from = "now-60m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "AWS Execution via System Manager"
note = """## Triage and analysis
### Investigating AWS Execution via System Manager
Amazon EC2 Systems Manager is a management service designed to help users automatically collect software inventory, apply operating system patches, create system images, and configure Windows and Linux operating systems.
This rule looks for the execution of commands and scripts using System Manager. Note that the actual contents of these scripts and commands are not included in the event, so analysts must gain visibility using an host-level security product.
#### Possible investigation steps
- Identify the user account that performed the action and whether it should perform this kind of action.
- Investigate other alerts associated with the user account during the past 48 hours.
- Validate that the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
- Investigate the commands or scripts using host-level visibility.
- Considering the source IP address and geolocation of the user who issued the command:
- Do they look normal for the calling user?
- If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
- If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.
- Contact the account owner and confirm whether they are aware of this activity.
- Check if this operation was approved and performed according to the organization's change management policy.
- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
### False positive analysis
- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Disable or limit the account during the investigation and response.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
- Identify the account role in the cloud environment.
- Assess the criticality of affected services and servers.
- Work with your IT team to identify and minimize the impact on users.
- Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
- Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
- Consider enabling multi-factor authentication for users.
- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
- Take the actions needed to return affected systems, data, or services to their normal operational levels.
- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
## Setup
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html"]
risk_score = 21
rule_id = "37b211e8-4e2f-440f-86d8-06cc8f158cfa"
severity = "low"
tags = [
"Domain: Cloud",
"Data Source: AWS",
"Data Source: Amazon Web Services",
"Data Source: AWS SSM",
"Use Case: Log Auditing",
"Tactic: Initial Access",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:ssm.amazonaws.com and event.action:SendCommand and event.outcome:success
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[rule.threat.technique.subtechnique]]
id = "T1566.002"
name = "Spearphishing Link"
reference = "https://attack.mitre.org/techniques/T1566/002/"
[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
+61 -9
View File
@@ -2,7 +2,7 @@
creation_date = "2021/05/05"
integration = ["aws"]
maturity = "production"
updated_date = "2024/05/21"
updated_date = "2024/11/05"
[rule]
author = ["Elastic", "Austin Songer"]
@@ -18,15 +18,58 @@ false_positives = [
should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-30m"
from = "now-9m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "AWS Security Group Configuration Change Detection"
note = """## Setup
name = "AWS EC2 Security Group Configuration Change"
note = """
### Investigating AWS EC2 Security Group Configuration Change
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.
#### Possible Investigation Steps
1. **Identify the Modified Security Group**:
- **Security Group ID**: Check the `aws.cloudtrail.flattened.request_parameters.groupId` field to identify the specific security group affected.
- **Rule Changes**: Review `aws.cloudtrail.flattened.response_elements.securityGroupRuleSet` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications.
2. **Review User Context**:
- **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account.
- **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account.
3. **Analyze the Configuration Change**:
- **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts.
- **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open.
4. **Check User Agent and Source IP**:
- **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual.
- **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access.
5. **Evaluate for Persistence Indicators**:
- **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access.
- **Permissions Review**: Confirm that the user’s IAM policies are configured to limit changes to security groups only as necessary.
6. **Correlate with Other CloudTrail Events**:
- **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access.
- **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities.
### False Positive Analysis
- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities.
- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments.
### Response and Remediation
- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment.
- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access.
- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity.
- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access.
### Additional Information
For more details on managing AWS Security Groups and best practices, refer to the [AWS EC2 Security Groups Documentation](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html) and AWS security best practices.
"""
references = ["https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html"]
risk_score = 21
rule_id = "29052c19-ff3e-42fd-8363-7be14d7c5469"
@@ -37,15 +80,24 @@ tags = [
"Data Source: Amazon Web Services",
"Data Source: AWS EC2",
"Use Case: Network Security Monitoring",
"Resources: Investigation Guide",
"Tactic: Persistence",
"Tactic: Defense Evasion"
]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(AuthorizeSecurityGroupEgress or
CreateSecurityGroup or ModifyInstanceAttribute or ModifySecurityGroupRules or RevokeSecurityGroupEgress or
RevokeSecurityGroupIngress) and event.outcome:success
event.dataset: "aws.cloudtrail"
and event.provider: "ec2.amazonaws.com"
and event.action:(
"AuthorizeSecurityGroupEgress" or
"CreateSecurityGroup" or
"ModifyInstanceAttribute" or
"ModifySecurityGroupRules" or
"RevokeSecurityGroupEgress" or
"RevokeSecurityGroupIngress")
and event.outcome: "success"
'''