* [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
* [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>
Davis Plumlee