Prep for Release 9.3 (#5548)

rules/cross-platform/defense_evasion_processes_with_trailing_spaces.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2024/12/24"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -15,6 +15,37 @@ index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_mana
 language = "eql"
 license = "Elastic License v2"
 name = "Processes with Trailing Spaces"
+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 Processes with Trailing Spaces
+
+This rule detects execution of binaries whose names end with a space, a Unix-style masquerade that makes a malicious tool visually indistinguishable from a legitimate one and evades default file handling. An attacker pattern is a trojanized clone of ssh, curl, or ps with a trailing space placed in a user-writable PATH directory, then invoked by cron, shell scripts, or launch agents to harvest credentials or stage payloads while blending in.
+
+### Possible investigation steps
+
+- Confirm the binary's presence and trailing space on disk using commands that reveal whitespace (ls -b, find -print0, stat), and compare inode, size, permissions, and mtime against the non-spaced counterpart in the same directory.
+- Correlate the event with parent process, effective user, environment (PATH, IFS, aliases), and working directory to determine whether PATH hijacking or script misresolution is being exploited.
+- Hash the suspicious executable, check code signing and compiler metadata where applicable, and pivot in threat intel and internal repositories to identify known implants or unauthorized builds.
+- Enumerate all directories in PATH for lookalike binaries with whitespace or Unicode homographs, review recent file creations and chmod/chown activity in those paths, and identify the account and host that introduced them.
+- Investigate follow-on activity from the same process tree, including network connections, credential access attempts, file writes, and persistence artifacts such as cron entries or macOS LaunchAgents, to determine scope and containment actions.
+
+### False positive analysis
+
+- A legitimate wrapper or init script may use exec -a or setproctitle to set a custom argv[0] with a trailing space for labeling or formatting, causing process.name to end with a space even though the underlying binary is trusted.
+- Build or maintenance scripts that fail to trim variables can create and run an executable or symlink whose name includes a trailing space (e.g., when an optional suffix is empty), producing benign events that match this detection.
+
+### Response and remediation
+
+- Terminate the spaced-name process and its parent, stop any cron job or macOS LaunchAgent invoking the spaced executable (e.g., "ssh "), and isolate the host if it initiated outbound connections or prompted for credentials.
+- Find and remove or quarantine all executables and symlinks whose filenames end with a space in PATH directories such as ~/bin, /tmp, and project bin paths, using rm -- with exact quoting or null-delimited tools to avoid clobbering the legitimate counterpart.
+- Remove persistence and PATH hijacks by deleting cron entries and LaunchAgents referencing the spaced name, restoring PATH for affected users and services to a vetted list, and resetting file ownership and permissions on altered directories.
+- Reinstall or restore the legitimate binary from trusted packages or gold images, verify checksums and code signing, update scripts to use absolute paths and trimmed variables, and rotate credentials if the lookalike was a trojan of ssh, curl, or ps.
+- Escalate to incident response if the spaced executable resides in system directories (/bin, /usr/bin, /usr/local/bin), runs as root or via sudo, repeatedly respawns after removal, or opens external network connections.
+- Harden by enabling file integrity monitoring for filenames with trailing whitespace or Unicode confusables, removing user-writable directories from global PATH and enforcing write protections, configuring cron/launchd with sanitized PATH, and applying noexec or sticky-bit policies on shared temp directories.
+"""
 risk_score = 21
 rule_id = "0c093569-dff9-42b6-87b1-0242d9f7d9b4"
 severity = "low"
@@ -27,6 +58,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"

rules/cross-platform/privilege_escalation_trap_execution.toml

@@ -2,7 +2,7 @@
 creation_date = "2023/08/24"
 integration = ["endpoint", "auditd_manager"]
 maturity = "production"
-updated_date = "2025/12/24"
+updated_date = "2026/01/12"
 
 [rule]
 author = ["Elastic"]
@@ -15,6 +15,37 @@ index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_mana
 language = "eql"
 license = "Elastic License v2"
 name = "Trap Signals 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 Trap Signals Execution
+
+This rule flags use of the shell built-in trap to bind commands to POSIX signals, enabling automatic execution when interrupts like SIGINT, SIGHUP, or SIGTERM occur. Attackers commonly embed traps in bash, zsh, or service scripts so pressing Ctrl+C (SIGINT) or a daemon reload (SIGHUP) silently runs a payload—adding a user to sudoers, planting a setuid helper, or launching a reverse shell—achieving persistence or escalation without a direct command invocation.
+
+### Possible investigation steps
+
+- Pull the full trap command and its arguments plus the parent script path, then read the script to see which signals map to which payloads and whether they perform user, permission, or network actions.
+- Determine execution context by user and privilege, TTY/session versus systemd or cron, and whether the shell was invoked with sudo or as root to gauge impact if the trap triggers.
+- Correlate telemetry for signal delivery (kill, hangup, termination) to the same process and for immediate follow-on activity such as child process spawns, edits to /etc files, setuid or chmod events, and outbound connections.
+- Search the host for other trap definitions in login and init paths (.bashrc, .zshrc, /etc/profile, /etc/*rc, systemd unit scripts, and cron wrappers) to identify persistence or broader tampering.
+- Verify legitimacy by comparing the script to package or repository sources and change records, and preserve artifacts (path, hash, mtime, owner) along with shell history and environment for deeper analysis.
+
+### False positive analysis
+
+- Operations or maintenance scripts legitimately declare trap handlers for SIGTERM or SIGHUP to perform cleanup during routine shutdown or reload, producing trap commands with signal arguments that match this detection.
+- Interactive shell customization may set a trap on SIGINT (Ctrl+C) to restore terminal settings or print a message on interruption, resulting in benign trap invocations with SIG* arguments.
+
+### Response and remediation
+
+- Isolate the host or TTY session where a trap binds SIGINT/SIGHUP/SIGTERM to commands that write to /etc or open a socket, kill the offending shell and its parent process, and stop/disable any systemd unit or cron wrapper invoking the implicated script path.
+- Edit the identified script or rc file (.bashrc, .zshrc, /etc/profile, systemd unit script) to remove or unset the trap handlers, and delete or quarantine any referenced payload such as a reverse-shell binary, sudoers drop-in, or setuid helper.
+- Restore altered files from a known-good baseline (e.g., /etc/sudoers, unit .service files, shell RCs), revalidate file ownership and permissions, restart impacted services cleanly, and rotate credentials for users touched by the payload.
+- Sweep the host and peers for additional trap definitions by grepping for "trap SIG" in login/init paths and service scripts, and record script path, hash, mtime, and owner to confirm scope and support cleanup.
+- Escalate to incident response if the trap executes as root, modifies /etc/sudoers or PAM files, creates setuid files under /usr/bin or /usr/local/bin, or starts a reverse shell to an external IP/port.
+- Harden by restricting write access to /etc/*rc and service scripts, enforcing deployment via signed packages, adding audit rules for changes to /etc/sudoers and /etc/profile.d, blocking shells from egress to untrusted networks, and alerting on traps bound to EXIT/DEBUG or signals that invoke privileged actions.
+"""
 risk_score = 21
 rule_id = "cf6995ec-32a9-4b2d-9340-f8e61acf3f4e"
 severity = "low"
@@ -27,6 +58,7 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"