* [New Rule] Web Server Unusual User Agent Request
* [New Rule] Web Server Suspicious User Agent Request Spike
* Update reconnaissance_web_server_unusual_user_agents.toml
* Update reconnaissance_web_server_unusual_user_agents.toml
* ++
* ++
* Rename rule for suspicious user agent requests
* fixing from indices formatting
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
Co-authored-by: terrancedejesus <terrance.dejesus@elastic.co>
* [New] Alerts in Different ATT&CK Tactics by Host
Using ES|QL and alerts risk score to identify top risky hosts based on presence of multiple alert touching at least 4 unique tactics in a 24h time Window.
* Update multiple_alerts_risky_host_esql.toml
* Update multiple_alerts_risky_host_esql.toml
* Update multiple_alerts_risky_host_esql.toml
* Update multiple_alerts_risky_host_esql.toml
* Update multiple_alerts_risky_host_esql.toml
* Update non-ecs-schema.json
* ++
* Update multiple_alerts_edr_elastic_defend_by_host.toml
---------
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
Both these rules are have low volume in telemetry as expected, this is quite rare behavior. No major changes to the rule logic itself.
AWS IAM Roles Anywhere Profile Creation
- updated description and investigation guide
- reduced execution window
- added highlighted fields
AWS IAM Roles Anywhere Trust Anchor Created with External CA
- changed rule type to EQL to use `stringContains` instead of leading wildcard
- uses `event.type` as event category override field
- reduced execution window
- updated description and investigation guide
- added highlighted fields
This rule is performing as expected in telemetry, no query changes needed.
- reduced execution window
- updated description and investigation guide
- updated tags
- added highlighted fields
Noticed some false positives in alert telemetry leading to high alert volume. For all 3 rules I've added `source.ip:*` and excluded `user_agent.original: AWS Internal` to reduce noise from internal AWS services and backend API calls made on a user's behalf. These rules will instead stay focused on direct SDK/CLI triggered API calls.
- reduced execution window
- updated description, false positive and investigation guide sections
- added highlighted fields
- udpated tags and MITRE mapping
This rule is quite loud in telemetry. However over 80% of alerts come from a single cluster, which seems to have a lot of role usage and operation-type IAM Users which assume other roles constantly. This makes me think the majority of these alerts may be from multiple role sessions retrieving secrets, rather than a single user retrieving multiple secrets rapidly. I've looked at the prod telemetry data we have access to and found a few instances where a single secret is accessed multiple times or certain AWS services retrieve multple secrets rapidly. All of these instances have been accounted for in the tunings here.
- query has been changed to remove `GetBatchSecretValue` from the query since this API call actually calls the `GetSecretValue` for each of the secrets it's retrieving. So we only need to look for `GetSecretValue`
- I've added the AWS services found in prod data that contribute to rapid secret retrieval
- Changed the threshold parameters to look for a single `user.id` retrieving more than 20 unique secret values (`aws.cloudtrail.request_parameters`)
- updated the description and investigation guide
- reduced execution window
* [Rule Tuning] AWS IAM API Calls via Temporary Session Tokens
Came across some false positives as I was rule testing.
Temporary credentials are also created for AWS Internal operations and when an AWS service operates on your behalf. These both should be excluded from results. I saw this in my own testing, in prod data and in our alert telemetry. These cases can be excluded by looking for `source.ip:*` as this field is not populated for those internal AWS operations.
NOTE: Another false positive instance has been highlighted in the investigation guide. A legitimate AWS console login session is given temporary (ASIA) credentials which are populated for all the operations performed during that session. The only way to distinguish between these events and other temporary session token events, like those granted via AssumeRole or GetSessionToken, is with a field populated as `sessionCredentialFromConsole: true`. Right now our Integration does not map this field and it can only be found in `event.original`. I am putting in an Integration request to populate this field, which we could then use to further reduce false positives for rules like this.
- updated description , false positives, and investigation guide
- added `source.ip:*` to query
* excluding AWS Internal user agent
excluding AWS Internal user agent
#### Deprecate RDS DB Instance/Cluster lifecycle detections
`CreateDBInstance`, `CreateDBCluster`, `StopDBInstance`, `StopDBCluster`. These events occur frequently in normal workflows and do not reflect known attacker techniques. They are simply RDS lifecycle operations, with no real impact from an attacker-target perspective. These actions don't have a meaningful benefit for an attacker or cause a meaningful impact for a target. Threat activity around RDS is typically centered around snapshot sharing, export, and public exposure, which is already covered by other rules. There is also a theoretical case to be made for detecting destructive actions against RDS resources like `instance|cluster|snapshot Deletion`, this is covered by other rules. Removing these creation and stoppage rules reduces noise and keeps the AWS ruleset more aligned with real threat surfaces rather than infrastructure management.
#### Deprecate Outdated DBSecurityGroup API rules
`CreateDBSecurityGroup` and `DeleteDBSecurityGroup` were only used by RDS deployments on EC2-Classic, which AWS has fully retired. Modern RDS uses VPC Security Groups, making these APIs obsolete. These rules can no longer trigger and provide no threat-detection value.
Network-permission manipulation is fully covered by our existing VPC Security Group rule - "AWS EC2 Security Group Configuration Change".
Completing Deprecation Process for this rule. It has now been included in our ruleset with `Deprecated -` prefix for 2 release cycles and should now be moved to our `_deprecated` folder.
* [New] SOCKS Traffic from an Unusual Process
This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the
source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems
or act as an intermediary for network communications to a command and control server to avoid direct connections to their
infrastructure.
* Update command_and_control_socks_fortigate_endpoint.toml
* Update command_and_control_socks_fortigate_endpoint.toml
* Update rules/cross-platform/command_and_control_socks_fortigate_endpoint.toml
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update command_and_control_socks_fortigate_endpoint.toml
* add fortinet schema and manif
* Update rules/cross-platform/command_and_control_socks_fortigate_endpoint.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/cross-platform/command_and_control_socks_fortigate_endpoint.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update pyproject.toml
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
ElastiCache cache security groups are only used with EC2-Classic deployments.
AWS officially retired EC2-Classic and no longer supports launching ElastiCache
clusters in EC2-Classic networking environments.
All modern ElastiCache deployments run in a VPC and rely on standard EC2
security groups (ec2.amazonaws.com APIs) rather than CacheSecurityGroup APIs
(elasticache.amazonaws.com).
This behavior is covered by this existing rule:
- https://github.com/elastic/detection-rules/blob/fe642a879a412db71492f5d776e1e3338a531266/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
These rules no longer match any behavior in supported AWS
environments and so should be deprecated. This PR:
- Marks both rules with `Deprecated - ` title to start deprecation process
- Updates rule description to clarify that they are only relevant for historical
EC2-Classic log analysis.
- Recommends relying on the existing EC2 security group rule for network-control
changes impacting ElastiCache in VPC-based deployments.
I've tested this scenario by creating an Elasticache cluster, creating, and modifying security group rules. Below is a screenshot verifying that the activity is indeed captured by the normal EC2/VPC security group rule. There were no alerts triggered for the "Elasticache Security Group" Rules
This rule is working as expected, only instances of this alert in telemetry is for testing environments.
- uses `iam` instead of `any` for eql query
- added highlighted fields
* [Rule Tuning] AWS EC2 Instance Console Login via Assumed Role
No hits in telemetry for this rule yet. Which is good as it is extremely rare and high-risk behavior for an EC2 instance to exhibit any console login behavior.
- used `event.type` as event_category_override field to remove use of `any` in query
- updated description and investigation guide
- updated tags
- updated Mitre mapping
- added highlighted fields
* normalized Sign-In tag
normalized Sign-In tag
* fixing Mitre mapping
* Update rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [Rule Tuning] AWS IAM SAML Provider Updated
Rule is performing well in telemetry, low volume as expected. The only obvious false positives are from AWS SSO service so that internal behavior has been excluded from the rule.
- added AWS SSO exclusion to query
- updated description and IG
- added highlighted fields
* Update rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
### AWS IAM Virtual MFA Device Registration Attempt with Session Token
- rule change kql to eql so that I could use startsWith function instead of wildcard for the `ASIA*`, temporary session determination.
- there is a known false positive for rules like this. When you login to the AWS console, a temporary session token is created in the back-end so in cloudtrail the token id looks the same (`ASIA*`) as temporary session tokens created by actions like `GetSessionToken` or `AssumeRole`, which is what this rule meant to capture. Our current data source does now allow us to distinguigh between these type of events. However, cloudtrail does provide a field `sessionCredentialFromConsole:true` that I am putting in a request for Integrations to include. This would allow us to exclude Console login sessions from rules like this that look for temporary token abuse.
- reduced execution window
- updated description, FP and IG
- update MITRE mapping
- added highlighted fields
AWS IAM Deactivation of MFA Device
- removed `DeleteVirtualMFADevice` from the scope of this rule. When Deleting an MFA device you must deactivate it first if it is associated with a user. You can also Create an MFA device and then Delete it without it being activated for a particular user. By capturing both Deactivation and Deletion events we have duplicate alerts for the same activity (This duplication of events is seen in telemetry.) We also capture benign instances where un-used MFA devices are deleted (which is a clean-up best practice). By reducing the scope to only `DeactivateMFADevice` actions, we capture the most threat-centric behavior which should be investigated.
- reduced execution window
- updated Description, FP and IG
- added highlighted fields
This rule is extremely loud in telemetry with no meaningful way to reduce false positives. The behavior it's capturing is common behavior, however can be used for threat hunting, investigation and further correlation with other detection rules. I'm moving this to a BBR rule with a few changes:
- removed IAMUser specification in the query. Temporary sessions can be created by both IAM Users and the Root Account. This rule should capture both instances.
- reduced execution window
- name change to AWS GetSessionToken Usage as this captured behavior is not indicative of abuse
- added highlighted fields
- updated description, FP and IG
Ruben Groenewoud