Monthly Manifest and Schema Refresh + investigation guides

detection_rules/etc/stack-schema-map.yaml

@@ -150,11 +150,11 @@
   endgame: "8.4.0"
 
 "9.4.0":
-  beats: "9.3.4"
-  ecs: "9.4.0-rc1"
+  beats: "9.4.3"
+  ecs: "9.4.0"
   endgame: "8.4.0"
 
 "9.5.0":
-  beats: "9.3.4"
-  ecs: "9.4.0-rc1"
+  beats: "9.4.3"
+  ecs: "9.4.0"
   endgame: "8.4.0"

pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "detection_rules"
-version = "1.7.7"
+version = "1.7.8"
 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/linux/command_and_control_netcon_file_creation.toml

@@ -2,7 +2,7 @@
 creation_date = "2026/07/02"
 integration = ["endpoint"]
 maturity = "production"
-updated_date = "2026/07/02"
+updated_date = "2026/07/06"
 
 [rule]
 author = ["Elastic"]
@@ -16,6 +16,37 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.file*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Network Connection Followed by File Creation"
+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 Network Connection Followed by File Creation
+
+This rule spots a Linux process running from an unusual writable directory that makes an outbound connection and then creates a file within seconds, a pattern that often marks an active implant receiving tasks and staging follow-on activity. Attackers launch a loader from /dev/shm or /tmp, poll a remote web-based command server, and immediately drop a script or renamed payload for execution or persistence.
+
+### Possible investigation steps
+
+- Review the process ancestry and launch context for the binary in the writable directory to determine whether it originated from a user session, script, scheduled task, package operation, or remote execution mechanism.
+- Inspect the external destination's reputation, ownership, protocol details, and whether other hosts contacted it at similar times to distinguish approved software behavior from likely command-and-control traffic.
+- Examine the created file's location, type, hash, contents, permissions, and any immediate chmod, rename, or execution activity to assess whether it is a staged payload, script, or persistence artifact.
+- Build a concise timeline around the alert to identify preceding download, decode, or unpack actions and any follow-on child processes, credential access attempts, or lateral movement from the same host.
+- Search the environment for the same executable hash, destination, or dropped artifact on other systems and contain the host if you observe repeated beaconing, additional suspicious file creation, or evidence of execution.
+
+### False positive analysis
+
+- A legitimate software installer, updater, or bootstrap script launched from /tmp or /var/tmp can contact an external repository and immediately create unpacked files; verify the parent process, initiating user, shell history, and whether the destination IP and dropped files align with an approved installation or update at that time.
+- An administrator or automation job may execute a temporary script from /dev/shm or /run/user to fetch remote content and write logs, configuration, or cache files; confirm the activity matches a scheduled task or provisioning change and inspect the created file paths and script contents for expected benign output.
+
+### Response and remediation
+
+- Isolate the affected Linux host from the network except for approved management access, kill the suspicious process running from the writable directory, quarantine the binary and any files it created, and block the contacted external IP or domain at the firewall, proxy, and DNS layers.
+- Remove attacker footholds by deleting malicious systemd services, cron jobs, shell profile modifications, SSH authorized_keys entries, and any copied or renamed payloads the implant placed under writable paths or startup locations, after preserving forensic copies.
+- Reset potentially exposed access by rotating passwords, SSH keys, API tokens, and service credentials used on the host, especially if the process ran as root, touched authentication files, or dropped scripts and configuration files that may contain secrets.
+- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline when the binary or dropped files executed, then validate package integrity, startup items, and critical application data before reconnecting it to production.
+- Escalate immediately to incident response if the same executable hash, outbound destination, or dropped artifact appears on additional hosts, or if you identify privilege escalation, credential theft, persistence in multiple locations, or attempted lateral movement.
+- Harden the environment by blocking execution from /tmp, /dev/shm, and other writable directories where feasible, tightening egress rules to approved destinations, enforcing application allowlisting, and improving monitoring for new outbound beacons followed by file creation.
+"""
 risk_score = 21
 rule_id = "01c1e353-9d86-4344-abdf-523ab80c6f08"
 setup = """## Setup
@@ -51,6 +82,7 @@ tags = [
     "Tactic: Command and Control",
     "Tactic: Execution",
     "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
 ]
 type = "eql"
 query = '''

rules/linux/defense_evasion_lolbin_so_load.toml

@@ -2,7 +2,7 @@
 creation_date = "2026/07/02"
 integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2026/07/02"
+updated_date = "2026/07/06"
 
 [rule]
 author = ["Elastic"]
@@ -22,6 +22,37 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "Shared Object Load via LoLBin"
+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 Shared Object Load via LoLBin
+
+This alert flags a Linux program that normally is not used as a loader but is started with options that pull a shared object into memory, a common way to hide malicious code behind trusted tools. An attacker can launch `openssl -engine /tmp/libcrypto.so` or a short `python -c` snippet that calls `cdll.LoadLibrary("/tmp/libx.so")` to execute a rogue library while blending in with legitimate system activity.
+
+### Possible investigation steps
+
+- Review the full command line, ancestor process chain, session context, and executing user to determine whether the shared object load aligns with a legitimate admin task, build workflow, or expected plugin behavior.
+- Identify the referenced `.so` file on disk and validate its package ownership, hash reputation, permissions, timestamps, and location, giving extra scrutiny to libraries in temporary, user-writable, hidden, or recently created paths.
+- Pivot on the same library path or hash across hosts and users to determine whether it is isolated to one system, newly introduced, or part of a broader sequence involving script execution, file drops, or repeated LoLBin abuse.
+- Examine activity immediately before and after the load for suspicious follow-on behavior such as outbound network connections, credential access attempts, unexpected child processes, privilege escalation, or persistence-related file changes.
+- If the library is not attributable to approved software, collect the binary and related artifacts for static or sandbox analysis and consider host containment or blocking the file hash and path if corroborating malicious evidence is present.
+
+### False positive analysis
+
+- Developers or build jobs may use `python -c`, `ruby -e`, or `openssl -engine` to validate a locally built `.so` during compilation or testing; confirm the parent process and working directory map to an expected build path or `make`-driven workflow and that the library resides in a project or package-managed location.
+- Administrators may intentionally load a legitimate shell builtin or application plugin through `bash -c`, `gdb`, or `vim` while troubleshooting or enabling features; verify the session is interactive and attributable to the user, then check that the referenced `.so` is package-owned or stored in a standard system library or plugin directory rather than a writable temporary path.
+
+### Response and remediation
+
+- Isolate the affected Linux host from the network, terminate the abusing LoLBin and any spawned processes, and quarantine the referenced `.so` and any copies found in writable locations such as `/tmp`, `/dev/shm`, user home directories, or hidden folders.
+- Remove attacker persistence by deleting unauthorized entries from `/etc/ld.so.preload`, shell startup files, cron jobs, systemd services or timers, and any wrapper scripts that relaunch `openssl -engine`, `python -c`, `ruby -e`, or shell commands to load the malicious library.
+- Reset credentials and revoke secrets used on the host, including SSH keys, API tokens, and service-account passwords, if the library executed under a privileged account or accessed authentication material, browser data, or configuration files with embedded secrets.
+- Restore the host to a known-good state by rebuilding from a trusted image or reinstalling verified packages, then validate that no unapproved libraries, altered loader settings, or attacker-added binaries remain on disk before returning the system to production.
+- Escalate to incident response immediately if the same library hash or path is present on multiple hosts, the load occurred as `root`, or the host showed follow-on behavior such as new persistence, remote command execution, or suspicious outbound network connections.
+- Harden the environment by restricting plugin and engine loads to approved library directories, enforcing package integrity checks, monitoring for changes to preload files and service definitions, and applying SELinux or AppArmor policies that prevent scripts and LoLBins from loading shared objects from user-writable paths.
+"""
 references = ["https://gtfobins.github.io/#+library%20load"]
 risk_score = 47
 rule_id = "ebf493d1-20be-41a0-a010-c1b6a6f90e28"
@@ -66,6 +97,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"

rules/linux/defense_evasion_proxy_execution_via_systemd_run.toml

@@ -2,7 +2,7 @@
 creation_date = "2026/07/02"
 integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
 maturity = "production"
-updated_date = "2026/07/02"
+updated_date = "2026/07/06"
 
 [rule]
 author = ["Elastic"]
@@ -23,6 +23,37 @@ index = [
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Proxy Execution via Systemd-run"
+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 Potential Proxy Execution via Systemd-run
+
+This alert fires when a Linux process launches another command through systemd-run instead of executing it directly, which can hide execution behind a trusted system utility and detach it into a transient service or scope. An attacker might use systemd-run --user or a transient unit to start a shell, downloader, or credential-harvesting script in the background from an interactive session, reducing visibility into the real payload and parent-child chain.
+
+### Possible investigation steps
+
+- Reconstruct the full process tree around the event to determine which user, shell, script, service, or remote access session invoked systemd-run and whether the ancestry aligns with normal administrative or automation activity on that host.
+- Review the exact command passed through systemd-run, including flags such as --user, --scope, scheduling options, or custom unit names, and classify the spawned payload as expected software management, benign interactive use, or suspicious shell, downloader, or persistence behavior.
+- Query systemd and journal artifacts for the transient unit that was created, including unit properties, start time, execution account, service output, and whether the unit remained active, failed, or was configured to run again.
+- Correlate the execution with nearby events from the same user or host such as logins, sudo activity, file creation in writable locations, outbound network connections, or follow-on launches of interpreters and admin tools to identify a broader intrusion sequence.
+- If the activity is unauthorized or unclear, inspect the referenced binary or script for path reputation, package ownership, hash prevalence, and recent modification history, then stop the transient unit and contain any files or persistence it introduced.
+
+### False positive analysis
+
+- A legitimate administrator or maintenance script may use `systemd-run` to launch a transient unit for package updates, cache rebuilds, or controlled service restarts, so verify the initiating user, the parent script or shell history, and nearby package-management or scheduled change activity.
+- A normal desktop or user session can invoke `systemd-run --user` or `--scope` to start an application, terminal, or session task in a transient scope, so confirm the parent process belongs to the logged-in user’s graphical session and that the spawned command matches expected interactive activity in systemd or journal logs.
+
+### Response and remediation
+
+- Isolate the affected Linux host from the network except for approved management channels, terminate the malicious `systemd-run` transient unit or scope, and kill any child shell, downloader, or script it launched.
+- Remove attacker persistence by deleting unauthorized unit files and drop-ins from `/etc/systemd/system/`, `/run/systemd/transient/`, `/var/lib/systemd/`, and affected users’ `~/.config/systemd/user/` directories, then run `systemctl daemon-reload` and disable any malicious timers or services.
+- Preserve and quarantine the executed payload, related scripts, and any files created from writable locations such as `/tmp`, `/var/tmp`, `/dev/shm`, or a user home directory, and revoke exposed access by resetting compromised passwords, SSH keys, tokens, and sudo access tied to the initiating account.
+- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline if the command ran as `root`, modified security tooling, or executed an unknown binary, and validate that only approved packages, services, and startup entries remain before returning it to production.
+- Escalate to incident response immediately if the `systemd-run` activity spawned a reverse shell, downloader, credential access tool, or lateral movement utility, if similar transient units appear on multiple hosts, or if the affected account has privileged or production access.
+- Harden the environment by restricting who can invoke `systemd-run` through sudoers and privileged group membership, enforcing MFA and least privilege for administrative access, monitoring for new transient units and unexpected `--user` executions, and blocking execution from world-writable paths where the payload was staged.
+"""
 risk_score = 21
 rule_id = "a2e5e290-f534-4b71-bc3f-2dd1932b4cd6"
 setup = """## Setup
@@ -66,6 +97,7 @@ tags = [
     "Data Source: Auditd Manager",
     "Data Source: SentinelOne",
     "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"