Monthly Manifest and Schema Updation (#5920)

detection_rules/etc/stack-schema-map.yaml

@@ -145,11 +145,11 @@
   endgame: "8.4.0"
 
 "9.3.0":
-  beats: "9.3.1"
+  beats: "9.3.2"
   ecs: "9.3.0"
   endgame: "8.4.0"
 
 "9.4.0":
-  beats: "9.3.1"
+  beats: "9.3.2"
   ecs: "9.3.0"
   endgame: "8.4.0"

pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "detection_rules"
-version = "1.6.10"
+version = "1.6.11"
 description = "Detection Rules is the home for rules used by Elastic Security. This repository is used for the development, maintenance, testing, validation, and release of rules for Elastic Security’s Detection Engine."
 readme = "README.md"
 requires-python = ">=3.12"

rules/cross-platform/defense_evasion_data_encrypted_via_openssl.toml

@@ -2,7 +2,7 @@
 creation_date = "2026/03/26"
 integration = ["endpoint", "sentinel_one_cloud_funnel", "crowdstrike", "auditd_manager", "windows", "system"]
 maturity = "production"
-updated_date = "2026/03/26"
+updated_date = "2026/04/06"
 
 [rule]
 author = ["Elastic"]
@@ -27,6 +27,38 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "Data Encrypted via OpenSSL Utility"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Data Encrypted via OpenSSL Utility
+
+This rule flags the OpenSSL command-line tool when it starts encrypting a file with explicit input and output paths, a pattern that can indicate an attempt to hide or lock data. An attacker on Linux or macOS might run `openssl enc -aes-256-cbc -in /home/shared/payroll.csv -out /tmp/payroll.csv.enc` to encrypt collected documents before staging them for exfiltration or to prepare data for a ransomware-style extortion event.
+
+### Possible investigation steps
+
+- Review the full OpenSSL invocation to identify the cipher used, the source and destination file paths, whether a password or key was supplied inline or via script, and whether the targeted data is business-critical or user-owned.
+- Trace the parent and ancestor execution chain to determine whether the activity originated from an approved administrative workflow or from unusual launch points such as interactive shells, remote access tools, scheduled tasks, temporary folders, or user download locations.
+- Scope adjacent file activity on the host to see whether this was a single expected encryption task or part of a wider pattern of mass file reads, encrypted output creation, original file deletion, or access to shared drives and sensitive repositories.
+- Investigate the initiating account and system for precursor signs of compromise, including recent suspicious logons, privilege escalation, script execution, tool transfer, or other activity that is inconsistent with the user’s normal administrative behavior.
+- Search for follow-on actions that would raise ransomware or exfiltration concern, such as archive creation, outbound network transfers, ransom note drops, service stoppage, shadow copy removal, or attempts to disable security controls.
+
+### False positive analysis
+
+- Administrators may use `openssl enc -in ... -out ...` in backup or file-transfer scripts to protect exports, archives, or configuration bundles; verify the parent script or scheduled task, the service account, and the source and destination paths align with a documented maintenance workflow.
+- Developers or support personnel may encrypt test data sets or collected logs before sharing them internally for troubleshooting; verify the initiating user’s role, confirm the files are expected non-production artifacts, and check for a related change or support activity during the same time window.
+
+### Response and remediation
+
+- Isolate the affected endpoint from the network and disconnect mapped drives or mounted shares to stop further encryption while preserving the OpenSSL binary, shell history, encrypted output files, and any wrapper scripts as evidence.
+- Remove attacker persistence by deleting malicious Scheduled Tasks, cron jobs, systemd services, launch agents, startup items, and scripts that invoked `openssl enc`, and quarantine any copied tools or payloads found in temporary or user-writable directories.
+- Reset passwords, revoke active sessions and tokens, and rotate SSH keys or service-account secrets associated with the compromised host or user if the encryption activity was launched from an interactive shell, remote access session, or automation account.
+- Restore impacted files from known-good offline or immutable backups and rebuild or reimage the system if core binaries, startup locations, or security tools were modified, validating restored data before returning the host to production.
+- Escalate immediately to incident response if encrypted files were written to shared storage, similar OpenSSL commands appear on multiple hosts, ransom notes or extortion messages are present, or backup repositories and domain-admin accounts may be affected.
+- Harden the environment by restricting OpenSSL execution to approved admins and paths, enforcing application allowlisting, limiting write access to sensitive shares, disabling unused remote administration tools, and adding detections for mass file encryption and shadow-copy or backup tampering.
+
+"""
 risk_score = 21
 rule_id = "feba48f6-40ca-4d04-b41f-5dfa327de865"
 severity = "low"
@@ -45,6 +77,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: Windows Security Event Logs",
     "Data Source: Sysmon",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"

rules/cross-platform/execution_suspicious_python_command_execution.toml

@@ -2,7 +2,7 @@
 creation_date = "2026/03/26"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2026/03/26"
+updated_date = "2026/04/06"
 
 [rule]
 author = ["Elastic"]
@@ -15,6 +15,37 @@ from = "now-9m"
 language = "esql"
 license = "Elastic License v2"
 name = "Suspicious Python Shell Command Execution"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Suspicious Python Shell Command Execution
+
+This rule flags Linux or macOS activity where Python rapidly launches multiple shell commands through sh/bash-style interpreters, a strong sign that a script is driving hands-on execution rather than normal application behavior. An attacker might use a Python backdoor to run `sh -c` commands such as `whoami`, `uname`, `env`, `find`, and `curl` in quick succession to profile the host, locate data, and pull down follow-on tools.
+
+### Possible investigation steps
+
+- Reconstruct the full process tree around the Python parent to identify the originating script or module, execution path, user context, and whether it was launched by an interactive session, scheduled task, service, container runtime, or approved automation.
+- Review the Python code or script content that spawned the shells, along with recent file creation or modification and package installation activity, to determine whether it is legitimate application logic or an unexpected payload introduced in temporary, user, or application directories.
+- Compare the clustered shell commands with any immediate follow-on behavior such as outbound network connections, tool downloads, archive creation, credential store access, or additional interpreter launches to assess whether the activity moved from discovery into payload delivery or exfiltration.
+- Pivot on the same host and Python execution lineage for prior and subsequent events to uncover persistence or lateral movement indicators, including cron or systemd changes, launchd modifications, SSH activity, or repeated execution patterns across other endpoints.
+- Validate with the asset or application owner whether the behavior matches known deployment, build, or administrative workflows, and if it does not, isolate the host and collect memory, script artifacts, and shell history for deeper analysis.
+
+### False positive analysis
+
+- A legitimate Python administration or deployment script may call `sh -c` to run discovery and download commands such as `whoami`, `uname`, `env`, `find`, or `curl` during host setup; verify the parent Python script path, user, and working directory match an approved maintenance job and that the command set is expected for that script.
+- A Python application on Linux or macOS may spawn shell wrappers during startup, diagnostics, or update checks and generate several distinct commands within a minute; confirm the Python executable and child shell activity originate from the expected application directory and correlate with a recent authorized install, upgrade, or troubleshooting session.
+
+### Response and remediation
+
+- Isolate the affected Linux or macOS host from the network, terminate the malicious Python process and any spawned `sh -c` or `bash -c` children, and block any external IPs, domains, or download URLs the script contacted.
+- Preserve and quarantine the Python script, shell history, downloaded payloads, and files created in temporary, user, or application directories, then remove attacker persistence such as cron jobs, systemd service or timer units, launchd plists, login scripts, and unauthorized `authorized_keys` entries.
+- Restore the system to a known-good state by removing attacker-created files only after collection, reinstalling or repairing modified packages and startup items, and reimaging the host if system binaries, security tools, or core configuration files were altered.
+- Rotate credentials and secrets exposed on the host, including local accounts, SSH keys, API tokens, and application or cloud credentials, especially if the shell activity included `env`, keychain access, history review, or reads from credential files.
+- Escalate to incident response immediately if the Python-launched shells used `curl` or `wget` to fetch payloads, established outbound sessions to untrusted infrastructure, touched multiple endpoints, or showed evidence of credential theft, persistence, or data collection.
+- Harden the environment by restricting Python and shell execution from temporary or user-writable paths, limiting which users and services can invoke shell interpreters, tightening egress controls, and adding detections for Python spawning shell commands, new cron or launchd items, and unauthorized SSH key changes.
+"""
 risk_score = 47
 rule_id = "b42e4b88-fc4a-417b-a45e-4d4a3db9fd41"
 severity = "medium"
@@ -25,6 +56,7 @@ tags = [
     "Use Case: Threat Detection",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "esql"
 query = '''

rules/integrations/cloud_defend/privilege_escalation_chroot_execution_detected_inside_container.toml

@@ -4,7 +4,7 @@ integration = ["cloud_defend"]
 maturity = "production"
 min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
 min_stack_version = "9.3.0"
-updated_date = "2026/03/26"
+updated_date = "2026/04/06"
 
 [rule]
 author = ["Elastic"]
@@ -18,6 +18,36 @@ interval = "5m"
 language = "eql"
 license = "Elastic License v2"
 name = "Chroot Execution Detected via Defend for Containers"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Chroot Execution Detected via Defend for Containers
+
+This alert flags a process inside a Linux container that launches chroot, which can let code run against an alternate root filesystem and is often used to break container isolation. An attacker who has landed in a privileged or misconfigured container may chroot into a mounted host path such as /host or /proc/1/root, then spawn a shell to access host files, binaries, and credentials.
+
+### Possible investigation steps
+
+- Review the full execution chain and command arguments to identify the target root path and spawned program, prioritizing cases that reference host-linked locations such as /host, /proc/1/root, /mnt, or other node filesystem mounts.
+- Validate the container’s security posture at the time of execution, including whether it ran as root, used privileged mode, exposed host namespaces, or mounted sensitive host paths that would make a chroot attempt capable of escaping isolation.
+- Examine nearby process, file, and network activity from the same container or pod for follow-on actions against the host, such as shell launches, access to container runtime sockets, kubelet paths, SSH material, or other credential-bearing files.
+- Compare the behavior with the container image’s normal purpose, entrypoint, recent image or deployment changes, and any approved troubleshooting activity to determine whether the chroot was expected administration or anomalous runtime behavior.
+- If the activity is unexplained or hostile, isolate or terminate the workload, collect the container filesystem and runtime metadata for forensics, and assess the underlying node for compromise before rotating any potentially exposed secrets.
+
+### False positive analysis
+
+- Some build, initialization, or package-maintenance containers legitimately call chroot to install files into a staged root filesystem; verify the image or startup script is intended to prepare an alternate root and that the target path is an expected internal mount rather than a host-linked location.
+- An approved troubleshooting or recovery session in a privileged container may use chroot to inspect or repair an intentionally mounted filesystem; verify the user and timing align with authorized maintenance and confirm the command did not pivot to paths such as /proc/1/root, /host, or other node filesystems.
+
+### Response and remediation
+
+- Immediately isolate the affected pod or container, cordon the worker node it ran on, stop the malicious workload, and preserve the container filesystem, mounted volumes, and node logs for forensic review.
+- Hunt for and remove persistence related to the compromise, including rogue CronJobs or DaemonSets, modified entrypoint or startup scripts, unauthorized SSH authorized_keys, new sudoers entries, and unexpected systemd services on the node.
+- If the chroot targeted host-linked paths such as /proc/1/root or /host, or you find access to the container runtime socket, kubelet credentials, or new privileged workloads, escalate immediately to incident response and treat the node as potentially fully compromised.
+- Restore the environment from a known-good state by reimaging or replacing affected nodes, redeploying the workload from a trusted image digest, and rotating any credentials, service account tokens, kubeconfigs, or cloud keys exposed to the container or host.
+- Harden the environment to prevent recurrence by removing privileged mode and hostPath mounts, enforcing non-root containers, dropping unnecessary Linux capabilities, applying seccomp or AppArmor or SELinux profiles, and restricting access to host namespaces and runtime sockets.
+"""
 references = [
     "https://some-natalie.dev/container-escapes-chroot/",
 ]
@@ -30,6 +60,7 @@ tags = [
     "OS: Linux",
     "Use Case: Threat Detection",
     "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"

rules/integrations/kubernetes/credential_access_get_secrets_access.toml

@@ -2,7 +2,7 @@
 creation_date = "2026/03/26"
 integration = ["kubernetes"]
 maturity = "production"
-updated_date = "2026/03/26"
+updated_date = "2026/04/06"
 
 [rule]
 author = ["Elastic"]
@@ -15,6 +15,37 @@ index = ["logs-kubernetes.audit_logs-*"]
 language = "kuery"
 license = "Elastic License v2"
 name = "Kubernetes Secret Access via Unusual User Agent"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kubernetes Secret Access via Unusual User Agent
+
+This rule flags requests to read or enumerate Kubernetes secrets when they come from an uncommon client profile, account, and network source, which can expose tokens, keys, and passwords that unlock wider cluster or cloud access. A common attacker pattern is to compromise a pod or steal a kubeconfig, then use curl or a custom script from a new host to pull service-account tokens, registry credentials, or application secrets for follow-on movement.
+
+### Possible investigation steps
+
+- Determine whether the requesting identity, source IP, and user agent align with a known administrator workstation, CI/CD runner, controller, or approved automation path by validating change records, VPN or proxy logs, and asset ownership.
+- Review the exact secret names and namespaces accessed to assess impact, prioritizing service-account tokens, registry credentials, cloud keys, kubeconfigs, and secrets tied to production or highly privileged workloads.
+- Compare the event to the identity’s historical Kubernetes activity to confirm whether the client pattern, originating network, targeted namespaces, or access volume are new or unusually broad for that account.
+- Correlate nearby cluster and cloud activity from the same identity or source for signs of follow-on actions such as pod exec, token creation, role binding changes, API discovery bursts, or authentication attempts using newly exposed credentials.
+- If the access is not clearly authorized, contain by revoking or rotating the exposed secrets and linked credentials, then inspect the originating host or pod and its RBAC permissions for evidence of compromise or misuse.
+
+### False positive analysis
+
+- A cluster administrator may legitimately use curl, a browser, or a custom script from a newly assigned workstation or bastion host to inspect a secret during troubleshooting, so verify the activity against approved maintenance records and confirm the source IP and user identity map to that authorized host and user.
+- A workload or internal automation can access secrets through a nonstandard Kubernetes API client after a deployment, restart, or credential rotation, so confirm the service account, namespace, and RBAC scope match the application’s expected behavior and correlate the timing with recent operational changes.
+
+### Response and remediation
+
+- Isolate the source of the secret access by quarantining the implicated workstation or pod, cordoning the hosting node if needed, and temporarily blocking its network path to the Kubernetes API server and other sensitive services.
+- Revoke the attacker’s access by disabling the abused user or service account, deleting exposed or suspicious kubeconfigs, API tokens, CronJobs, DaemonSets, backdoor pods, and any newly created RoleBindings or ClusterRoleBindings tied to the activity.
+- Rotate every secret that was read or listed and all downstream credentials it protects, including service-account tokens, registry passwords, cloud IAM keys, database credentials, and application secrets, then restart affected workloads so they load the new values from trusted sources.
+- Restore the cluster to a known-good state by redeploying affected workloads from trusted images and manifests, validating namespaces and mounts against approved baselines, and removing any unauthorized containers or helper utilities left behind for persistence.
+- Escalate to incident response immediately if the access touched production namespaces, cluster-admin or cloud-linked credentials, multiple namespaces, or was followed by pod exec, token creation, or lateral movement from the same host or account.
+- Harden against recurrence by reducing secret-read permissions to only required service accounts, forcing administrative access through approved bastions, enforcing short-lived credentials with regular rotation, and alerting on nonstandard clients or sudden secret enumeration activity.
+"""
 risk_score = 21
 rule_id = "cbda9a0e-2be4-4eaa-9571-8d6a503e9828"
 severity = "low"
@@ -24,6 +55,7 @@ tags = [
     "Domain: Cloud",
     "Use Case: Threat Detection",
     "Tactic: Credential Access",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"