* [Rule Tuning] AWS Access Token Used from Multiple Addresses
Summary
Tuning changes to reduce noise and improve fidelity for the AWS Access Token Used from Multiple Addresses rule. After several tuning this rule is still producing ~2000 alerts/day
- Added aws.cloudtrail.session_credential_from_console exclusion to filter out legitimate console login sessions
- Added Esql.event_provider_count_distinct > 1 condition requiring activity across multiple AWS services to reduce single-service noise
- Changed interval from 5m to 30m to reduce alert frequency
- Updated query time window from 30 minutes to 32 minutes to align with the from setting
- Added min_stack_version = "9.2.0" for the new console credential field (AWS integration 4.6.0+)
Rational
- Console login sessions generate temporary credentials that can appear from multiple IPs during VPN/network transitions
- Requiring activity across multiple AWS service providers increases confidence that the token is being used for broader reconnaissance rather than normal single-service operations
- Longer interval reduces duplicate alerting per access token while still catching the behavior within the 32-minute aggregation window
* Apply suggestions from code review
* Update rules/integrations/aws/initial_access_iam_session_token_used_from_multiple_addresses.toml
* Update initial_access_iam_session_token_used_from_multiple_addresses.toml
* [New] Suspicious Execution from VS Code Extension
Detects suspicious process execution launched from a VS Code extension context (parent command line contains
.vscode/extensions). Malicious extensions can run on startup and drop or execute payloads (e.g. RATs like
ScreenConnect, script interpreters, or download utilities). This covers both script/LOLBin children and
recently created executables from non-Program Files paths, as seen in campaigns such as the fake Clawdbot
extension that installed ScreenConnect RAT.
* Update initial_access_suspicious_execution_from_vscode_extension.toml
* Update initial_access_suspicious_execution_from_vscode_extension.toml
* ++
* Update initial_access_suspicious_execution_from_vscode_extension.toml
* Update initial_access_suspicious_execution_from_vscode_extension.toml
* Update initial_access_suspicious_execution_from_vscode_extension.toml
* Update initial_access_suspicious_execution_from_vscode_extension.toml
* Update initial_access_suspicious_execution_from_vscode_extension.toml
* [Rule Tuning] AWS STS Role Assumption by User
Removed AssumedRole from the `aws.cloudtrail.user_identity.type` filter to eliminate redundancy with the AWS STS Role Chaining rule. The AWS STS Role Chaining rule already covers AssumedRole identity types assuming other roles. This change ensures each rule has distinct coverage without overlapping alerts.
- Changed query filter from `aws.cloudtrail.user_identity.type: ("AssumedRole" or "IAMUser")` to `aws.cloudtrail.user_identity.type: "IAMUser"`
- Updated description to clarify the rule focuses on user-initiated role assumptions
- Minor formatting fixes to investigation guide headings
* reducing new_terms fields
reducing new_terms fields to only use "aws.cloudtrail.user_identity.arn" since we do not have to account for roles, this field is unique for IAMUsers
* [Rule Tuningw] Add Console Session Filtering to AWS Temporary Credential Detection Rules
Added `aws.cloudtrail.session_credential_from_console` field filtering to 2 rules to reduce false positives from legitimate console login sessions. Console logins automatically issue temporary "ASIA" credentials, which previously triggered alerts for rules monitoring session token abuse.
- Updated false positives sections to reflect automatic console session filtering
- Updated investigation guides to note that alerts indicate non-console temporary credential usage
- min_stack_version = "9.2.0" because this field was introduced in AWS Integration version 4.6.0. 9.2.0 is the earliest major stack version supported.
Impact
- Significantly reduces false positives from legitimate AWS Management Console usage
- Improves rule fidelity by focusing detection on programmatic abuse of temporary credentials (CLI, SDK, stolen credentials)
* update boolean field value for aws.cloudtrail.session_credential_from_console
update boolean field value for aws.cloudtrail.session_credential_from_console
* removing filebeat compatibility
removing filebeat compatibility
* [New Rule] Okta User Authentication via Proxy Followed by Security Alert
Fixes#5751
* adjusted to EQL
* fixed syntax
* Update rules/integrations/okta/initial_access_first_occurrence_user_session_started_via_proxy.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* removed defense evasion; adjusted maxspan to 30m
* removed Okta tag
* adding Okta back as integration tag
---------
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* [New] FortiGate SSL VPN Login Followed by SIEM Alert by User
Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior.
* Update initial_access_fortigate_ssl_vpn_login_followed_by_siem_alert.toml
* Update initial_access_fortigate_ssl_vpn_login_followed_by_siem_alert.toml
* Update initial_access_fortigate_ssl_vpn_login_followed_by_siem_alert.toml
* [Rule Tuning] Kernel Module Load via Built-in Utility
* Apply suggestion from @eric-forte-elastic
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* Refine process.args conditions for modprobe
* Refactor notes and references in kernel module load rule
Removed detailed notes and investigation steps related to kernel module loading via insmod utility. Updated note section and added a reference link.
* Update persistence_insmod_kernel_module_load.toml
* Update persistence_insmod_kernel_module_load.toml
* Update kernel module load rule for clarity and tactics
---------
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* [New] Correlated Alerts on Similar User Identities
This rule correlates alerts from multiple integrations and event categories that involve different user.name values which
may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers
(e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person.
* Update multiple_alerts_llm_by_user_entity.toml
* Update multiple_alerts_llm_by_user_entity.toml
* Update multiple_alerts_llm_by_user_entity.toml
* Update multiple_alerts_llm_by_user_entity.toml
* Update rules/cross-platform/multiple_alerts_llm_by_user_entity.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update multiple_alerts_llm_by_user_entity.toml
* Apply suggestion from @terrancedejesus
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Update multiple_alerts_llm_by_user_entity.toml
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
Tuning based on telemetry from recent rule version 9. There are many false positives for what look like typical S3 storage object names like `BillingInformation`, `InstanceInformation` created by AWS Service accounts. I'm excluding AWS service account types from the rule for now which eliminated ~97% of the false positives over last 30 days. leaving only 66 which is acceptable for this rule and should be addressed via local exclusions.
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* [New] Multiple Rare Elastic Defend Behavior Rules by Host
Identifies hosts that triggered multiple distinct Elastic Defend behavior rules, while reducing false positives by
considering only behavior rules that appear on a single host globally (via INLINE STATS). Hosts with two or more
such rare behavior rules are more likely to be compromised and warrant prioritized triage.
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
---------
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* [Tuning] High Order Rules fine tuning
- Exclude High Order Rules as input by other HORs to avoid recursive alerting.
- Adjusted the rule name for one rule.
- FTS Detection rule using ES|QL - moved the `Esql.rule_name_values = VALUES(kibana.alert.rule.name)` to preserve the original alert name (it get confused with the HOR alert name).
* Update impact_alert_from_a_process_with_cpu_spike.toml
* Update command_and_control_socks_fortigate_endpoint.toml
* Update lateral_movement_multi_alerts_new_srcip.toml
* ++
* Update impact_alerts_on_host_with_cpu_spike.toml
* Update multiple_alerts_by_host_ip_and_source_ip.toml
* Update multiple_alerts_from_different_modules_by_user.toml
* [New Rule] AWS SSM Inventory Reconnaissance by Rare User
This rule detects the first time a user or role accesses AWS Systems Manager (SSM) inventory APIs or runs the AWS-GatherSoftwareInventory job. SSM Inventory provides detailed information about managed EC2 instances including installed software, patch compliance, network configurations, and command execution history. Threat actors, including Scattered Spider (LUCR-3), have been observed leveraging these APIs to enumerate targets for lateral movement while blending in with legitimate AWS operations. The rule uses a New Terms approach on cloud.account.id and user.name to identify when users access these reconnaissance APIs for the first time.
No existing rules specifically detect SSM inventory reconnaissance activity. This fills a gap in detecting cloud infrastructure discovery techniques used for target enumeration prior to lateral movement.
| API | Purpose |
|-----|---------|
| `GetInventory` | Query inventory data (installed software, OS details) |
| `GetInventorySchema` | Discover available inventory types |
| `ListInventoryEntries` | Get specific instance inventory |
| `DescribeInstancePatches` | Find patch compliance/vulnerabilities |
| `ListCommands` | View SSM command execution history |
| `CreateAssociation` | Trigger AWS-GatherSoftwareInventory job |
* Apply suggestions from code review
* [New Rule] AWS Sensitive IAM Operations Performed via CloudShell
This rule detects sensitive AWS IAM operations performed via CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the console without requiring local tooling. When attackers gain access to a compromised console session, CloudShell enables them to perform privileged operations such as creating users, access keys, roles, or attaching policies—leaving no artifacts on their local system. This behavior is documented in the Permiso blog on LUCR-3 (Scattered Spider) and the CISA Scattered Spider advisory, where threat actors leveraged CloudShell for post-compromise credential harvesting and privilege escalation.
No existing rules specifically detect CloudShell as the origin for sensitive IAM operations. This fills a gap by identifying high-risk actions from this browser-based execution context.
* adding iam provider
* primary tactic change
* updating highlighted fields
* removed bold from IG
* Apply suggestions from code review
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New Rules] AWS IAM new identity federation provider rules
AWS IAM SAML Provider Created and AWS IAM OIDC Provider Created by Rare User detect the creation of new identity federation providers in AWS IAM. SAML and OIDC providers establish trust relationships with external identity providers, enabling federated access to AWS resources. Adversaries who gain administrative access may create rogue providers to establish persistent access that survives credential rotation, allowing them to assume roles using tokens from an IdP they control. These rules map to MITRE ATT&CK T1484.002 (Trust Modification), which is referenced in the CISA Scattered Spider advisory (AA23-320A) under the Privilege Escalation tactic.
Existing Related Coverage: We already detect `UpdateSAMLProvider` via privilege_escalation_iam_saml_provider_updated.toml. These new rules close the gap by detecting the creation of federation providers, the initial step required to establish rogue trust relationships.
* Update rules/integrations/aws/persistence_iam_oidc_provider_created.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update rules/integrations/aws/persistence_iam_oidc_provider_created.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Apply suggestion from @imays11
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [Tuning] Adds host metadata to the setup requirements
Rules requiring host.ip and that are compatible with Elastic Defend integration can be impacting by windows].advanced.set_extended_host_information if set to the default value (false), host.ip won't be populated from 8.18+ (only host.name and host.os and host.id).
Related SDH https://github.com/elastic/sdh-endpoint/issues/722
* ++
* Update rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update lateral_movement_ml_spike_in_rdp_processes.toml
* Apply suggestion from @Mikaayenson
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Terrance DeJesus