* [New Rule][Rule Tuning] AWS Organizations/Account Discovery Coverage
In response to the supply chain attack highlighted in (Kudelski’s Trivy / TeamPCP analysis)[https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise], I've added coverage for AWS Organization and Account reconnaissance which was called out in the research.
### AWS Discovery API Calls via CLI from a Single Resource
- Expanded our existing Multi-service discovery rule to include `event.provider: oraganizations.amazonaws.com`
- added the new `aws.cloudtrail.session_credential_from_console` field to exclude console behavior from this rule, and added appropriate `min_stack` to account for introduction of the field.
GAP: This rule detects aws-cli usage only. In the mentioned reference, attackers used Botocore and Boto3 tooling for this recon activity.
SOLUTION:
### AWS Account Discovery By Rare User
- Created a new Discovery rule focused solely on Organization/Account reconnaissance.
- Made it a new terms rule to reduce false positive noise from common behavior that might be seen using Boto3 or Botocore tooling.
- excluded console session behavior and service account behavior
Testing:
- Ran PACU's organization__enum module
- created a script that can be run to validate the query
- plenty of test data in our stack to run the query against
* Update rules/integrations/aws/discovery_organization_discovery_by_rare_user.toml
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Expand AWS CloudTrail user-agent rule for TruffleHog and Kali
- Rename rule file to initial_access_suspicious_user_agent_detected_in_cloudtrail.toml
- Rule name: AWS Suspicious User Agent Fingerprint
- Match TruffleHog in user_agent.original (successful API calls)
- Retain Kali Linux distrib#kali fingerprint for aws-cli/Boto3
- Refresh narrative and references (incl. Kudelski Trivy supply-chain analysis)
Same rule_id f80ea920-f6f5-4c8a-9761-84ac97ec0cb2.
Made-with: Cursor
* Apply suggestion from @terrancedejesus
* Update euid job ids and min stack version
* Update euid job ids and min stack version
* Update job suffix from _euid to _ea
* Update pad okta rules
* Update min_stack_comments
* Update gcp audit rules
* Update rules based on new changes
* Add rule for v3_windows_rare_script_ea job
* Update updated_date for rule to pass test
* Remove integrations-only changes (moved to euid-rules-update-integrations branch)
DED, DGA, LMD, PAD, and ProblemChild ML rule changes have been moved to the
euid-rules-update-integrations branch which corresponds to integrations#17626.
This branch (euid-rules-update) now only contains Kibana-related ML rule changes.
Made-with: Cursor
* Update stale updated_date to 2026/04/01 across all modified ML rules
Made-with: Cursor
* Bump min_stack_version from 9.3.0 to 9.4.0 in azure/gcp city/country/user rules
Made-with: Cursor
* Add min_stack_comments to those missing
* [New] Elastic Defend Alert from Package Manager Install Ancestry
Detects Elastic Defend alerts (behavior, malicious file, memory signature, shellcode) where the alerted process has a package-manager install context in its ancestry: npm (Node.js), PyPI (pip / Python / uv), or Rust (cargo). Install-time spawn chains are a common path for supply-chain and postinstall abuse; this Higher-Order rule surfaces Defend alerts
whose process tree includes such activity for prioritization.
* Update initial_access_elastic_defend_alert_package_manager_ancestor.toml
* Update rules/cross-platform/initial_access_elastic_defend_alert_package_manager_ancestor.toml
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* Update rules/cross-platform/initial_access_elastic_defend_alert_package_manager_ancestor.toml
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* Update initial_access_elastic_defend_alert_package_manager_ancestor.toml
---------
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* [New] Potential Credential Discovery via Recursive Grep
Identifies recursive grep activity on Linux or macOS where the command line suggests hunting for secrets, credentials,
keys, tokens, or sensitive paths (for example .env, .git, .aws). Events are aggregated per host, user, parent process, and one-minute window, the rule surfaces activity only when at least three distinct grep command lines match in the same bucket, to reduce noise from one-off searches.
* Update credential_access_grep_recursive_credential_discovery.toml
* Update rules/cross-platform/credential_access_grep_recursive_credential_discovery.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/cross-platform/credential_access_grep_recursive_credential_discovery.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update credential_access_grep_recursive_credential_discovery.toml
* Update credential_access_grep_recursive_credential_discovery.toml
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New Rule] AWS API Activity from S3 Browser Client
Detects AWS API activity originating from the S3 Browser application based on the user agent string. S3 Browser is a Windows-based graphical client for managing S3 buckets that is rarely used in enterprise environments but has been observed in use by threat actors for data exfiltration due to its ease of use and bulk download capabilities. This rule was inspired by the Permiso LUCR-3 research which documented Scattered Spider using S3 Browser (v10.9.9) for data theft operations. No usage captured in alert telemetry and only one user utilized this browser in prod data.
Existing Related Coverage: We have several S3-related exfiltration rules covering bucket replication, policy modifications, and ransomware indicators. This new rule closes a gap by detecting a specific attacker tooling fingerprint rather than relying solely on behavioral patterns.
* Update rules/integrations/aws/exfiltration_s3_browser_user_agent.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [New Rule] AWS API Activity from Uncommon S3 Client by Rare User
This rule detects AWS API activity from S3 Browser and Cyberduck desktop clients based on user agent strings. Both are graphical S3 management tools that provide bulk upload/download capabilities and have been observed in use by threat actors for data exfiltration. S3 Browser usage is specifically documented in the Permiso blog on LUCR-3 (Scattered Spider), while Cyberduck is referenced in the MITRE ATT&CK Threat Emulation of Scattered Spider. The rule uses a New Terms approach on cloud.account.id and user.name to alert only on the first occurrence per user/account, reducing noise from repeated GetObject or PutObject operations while still capturing new suspicious tool usage.
No existing rules currently detect activity based on these specific S3 client user agents. This fills a gap in detecting exfiltration tooling commonly used in post-compromise data theft operations.
* adding space to S3 Browser
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* [New Rules] New Terms rules for malicious Python/Pickle model activity on macOS
Adds three new_terms SIEM detection rules to close the detection gap identified in ia-trade-team#666 where malicious pickle/PyTorch model files execute arbitrary commands via Python deserialization without triggering existing GenAI-parent-gated endpoint rules.
Co-authored-by: Cursor <cursoragent@cursor.com>
* Address PR feedback: broaden descriptions and simplify process.name
- Update descriptions across all three rules to not over-attribute to
pickle/PyTorch — these rules detect any malicious Python activity
(scripts, compromised dependencies, model deserialization, etc.)
- Simplify process.name from explicit enumeration to python* wildcard
since KQL matching is case-insensitive
- Update investigation guides to reflect broader scope of potential
attack vectors
Made-with: Cursor
* Apply suggestion from @DefSecSentinel
* Apply suggestion from @DefSecSentinel
* Apply suggestion from @DefSecSentinel
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
## Summary
This PR adds a new detection rule for AWS CloudShell environment creation, based on the **T1059.009 - Command and Scripting Interpreter: Cloud API** technique as documented in the [AWS Threat Technique Catalog](https://aws-samples.github.io/threat-technique-catalog-for-aws/Techniques/T1059.009.html).
AWS CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell can be abused by adversaries who gain access to compromised console sessions to execute commands, install tools, or interact with AWS services without needing local CLI credentials.
This rule detects the `CreateEnvironment` API call, which occurs when:
- A user launches CloudShell for the **first time**
- A user accesses CloudShell in a **new AWS region** (each region maintains a separate environment)
### Why `CreateEnvironment` instead of `CreateSession`?
`
While both `CreateEnviroment` and `CreateSession` are noted in the catalog for this technique, during testing I observed that:
- **`CreateEnvironment`** is called when a new CloudShell environment is created (first-time user OR new region)
- **`CreateSession`** is called when reconnecting to an existing CloudShell environment that was previously created
By focusing on `CreateEnvironment`, we capture the meaningful signal (new environment creation) while avoiding noise from users simply reconnecting to existing sessions.
* tune credential_access_genai_process_sensitive_file_access.toml to reduce 74% noise on local state
* tune defense_evasion_genai_config_modification.toml to conservatively reduce noise by 19% on file.path
* tune command_and_control_genai_process_unusual_domain.toml to reduce 34% noise by domains
* tune execution_openclaw_agent_child_process.toml to address 99 % of noise with ip/arp
Terrance DeJesus