* [New Rule] AWS EC2 Serial Console Access Enabled
Detects when an adversary enables the EC2 Serial Console feature at the AWS account level. This technique was documented by Permiso in their LUCR-3 Scattered Spider research as a defense evasion method that provides out-of-band access to EC2 instances, completely bypassing network-based security monitoring, VPCs, and security groups. Enabling serial console access is extremely rare in production environments, making this a high-signal detection with minimal false positive risk. I've tested this query against alert and prod telemetry and found rare instances.
Existing Related Coverage: We already detect `SendSerialConsoleSSHPublicKey` via lateral_movement_ec2_instance_connect_ssh_public_key_uploaded.toml, which catches the usage of serial console. This new rule closes the gap by detecting the enablement of serial console access, the prerequisite step that must occur before an attacker can leverage this out-of-band channel.
* raising severity and risk score
* [Rule Tuning] Potential AWS S3 Bucket Ransomware Note Uploaded
This rule was very loud in telemetry since it's last tuning. ~8,938 alerts in last 24 hours. All false positives due to regex pattern matches for file names like `enc` as part of /filetransfertmsadherence/ and absence/; `lock` as part of citations-blocks/.
I've reworked this rule based on more research into common ransom note file name keywords and replaced the list here with the most common keywords. For `file` (the most common) and `back`, I was still seeing false positives so decided to alert on a combination of either or these 2 words in conjunction with any of the other words from the list. I also changed the regex to be case-insensitive.
With this new query, I see only true positive results within the last year all from known testing events.
I changed the toml file name so the rule looks new but it is just tuned.
I've updated the description and investigation guide, and added the study I used as a reference: https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002
Test data is in our stack, script for executing is here:
Screenshot of new working query in our test stack
* Apply suggestions from code review
* removing redundany regex pattern
* Updated kubernetes.audit.requestObject.spec.containers.image type of text to Keyword
* [New Rules] Misc. K8s RBAC Abuse Rules
* --
* Update non-ecs-schema
* Update to make unit tests happy
* Mitre mapping updates
* Fix query logic for service account role bindings
* Fix formatting in persistence_service_account_bound_to_clusterrole rule
* Updated kubernetes.audit.requestObject.spec.containers.image type of text to Keyword
* [Rule Tuning] Dormant & Deprecated Rule Clean-Up
* [Rule Tuning] Dormant & Deprecated Rule Clean-Up
* Few more deprecations
* ++
* Update unit test syntax fix
* Update bad bytes
* ++
* [Rule Tunings] AWS removal of target.entity.id and actor.entity.id fields
Related Issue : - https://github.com/elastic/security-team/issues/14019
`target.entity.id` and `related.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
* update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
* updated_dates
* [Rule Tunings] AWS remove target.entity.id and actor.entity.id fields
adding min_stack to rules using the field `entity.target.id`, we determined AWS version 4.7.0 is compatible with Kibana versions '^8.19.4 || ^9.1.4'. We reverted the initial PR and this one adds the min_stack_version.
Original PR: - https://github.com/elastic/detection-rules/pull/5563
______
### Issue Link
- https://github.com/elastic/ia-trade-team/issues/781
## Summary - What I changed
`target.entity.id` and `actor.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
<img width="1622" height="1488" alt="image" src="https://github.com/user-attachments/assets/024fbdb2-c0e4-4785-9735-5285218e4fa9" />
## Rules with Query Changes
**AWS IAM Customer-Managed Policy Attached to Role by Rare User
AWS IAM Assume Role Policy Update**
Both of these rules relied on `target.entity.id` as a new terms field, this field has been replaced with `entity.target.id` field which is populating the same value for the event.actions these rules trigger on, as shown in the screenshot below.
<img width="1600" height="445" alt="Screenshot 2026-01-15 at 12 13 17 PM" src="https://github.com/user-attachments/assets/27e482fe-2a09-4dfb-8337-2e5070422183" />
## How To Test
- recent test data is in our stack for the 2 rules that have changes to their new terms values.
- test scripts for each:
- [trigger_privilege_escalation_iam_customer_managed_policy_attached_to_role.py](https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/IAM/trigger_privilege_escalation_iam_customer_managed_policy_attached_to_role.py)
- [trigger_privilege_escalation_update_assume_role_policy.py](https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/IAM/trigger_privilege_escalation_update_assume_role_policy.py)
* [Rule Tunings] AWS removal of target.entity.id and actor.entity.id fields
Related Issue : - https://github.com/elastic/security-team/issues/14019
`target.entity.id` and `related.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
* update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
* updated_dates
Completing the Deprecation process for these rules as they have been shipped at least 2 release cycles with "Deprecated - " prefix.
All have the following metadata changes
maturity = "deprecated"
updated_date = "2026/01/16"
deprecation_date = "2026/01/16"
- Removing the genAI disclaimer for the AWS ruleset Investigation guides which were all manually modified during the most recent audit.
- Removing any numbering in the investigation guides to maintain better consistency across guides
- Fixed any spacing inconsistencies
* [Rule Tuning] AWS Service Quotas Multi-Region GetServiceQuota Requests
This rule is alerting as expected with very few instances in telemetry (only have data from 1 cluster).
- added more fields for context in the query.
- added metadata fields to query
- reduced execution window
- added highlighted fields
#### screenshot of working query with additional context
* Update rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
This rule is triggering as expected with moderate telemetry volume (high spikes for what looks like expected cleanup jobs) in specific cluster. No changes needed to the rule query.
- updated description, FP and IG
- reduced execution window
- updated highlighted fields
### AWS Config Resource Deletion
- added exclusions for services that perform Config modifications by design, reducing noise by 97% over the last 30 days.
- added success criteria to query as well
- increased severity to medium as this alert should be triaged
- updated description, false positive and investigation guide sections
- reduced execution window
- updated MITRE
- updated tags
- added highlighted fields
### AWS Configuration Recorder Stopped
no major query changes needed for this rule, performing as expected in telemetry with low volume as this is more rare activity.
- updated description, false positive and investigation guide sections
- reduced execution window
- updated MITRE
- updated tags
- added highlighted fields
* [Rule Tunings] AWS Lambda Rules
#### AWS Lambda Layer Added to Existing Function
This rule was missing alerts for the `UpdateFunctionConfiguration` action due to a missing wildcard.
- added missing wildcard to query
- reduced execution window
- updated description, FP and IG sections
- added highlighted fields
#### AWS Lambda Function Policy Updated to Allow Public Invocation
- changed this query to use EQL instead of KQL to optimize wildcard usage
- uses `event.type` as `event_category_override`
- reduced execution window
- updated description, FP and IG sections
- added highlighted fields
* Update rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
There was a mistake in the query for this rule. It was looking for `event.provider: eventbridge.amazonaws.com` instead of `events.amazonaws.com`. So we have no existing telemetry for this rule. However, I have tested the behavior properly and ensured the new query does alert as expected. I will monitor this rule in telemetry moving forward to gauge it's performance.
- query change `event.provider: events.amazonaws.com`
- reduced execution window
- updated description, FP and IG sections
- updated tags
- added highlighted fields
* [Rule Tuning] AWS CLI with Kali Linux Fingerprint Identified
This rule is performing well in telemetry as expected. I changed this to EQL to avoid the multiple wildcards needed with KQL.
- changed rule type to EQL
- reduced execution window
- updated description, false positive and investigation guide
Script for testing this rule:
Manually perform any action against our AWS account using Kali Linux distribution
#### Screenshot showing working EQL query, still captures the BitPanda behavior this rule was initially designed around.
* add highlighted fields
add highlighted fields
* Update initial_access_kali_user_agent_detected_with_aws_cli.toml
I reduced the history window for new terms rules that were either:
- `now-14 days`
- showing slow performance metrics
There are still several AWS rules with a `now-10d` window but they are not showing any performance issues so I'd like to leave them as is for now.
First Time Seen AWS Secret Value Accessed in Secrets Manager
- removed `BatchGetSecretValue` API call since this calls `GetSecretValue`
- removed the user_agent exclusions from this one, too easy to bypass.
AWS EC2 User Data Retrieval for EC2 Instance
- excluded more benign AWS services from telemetry
AWS IAM Assume Role Policy Update
- removed use of cloudformation exclusion, this should be captured as well
shashank-elastic