[New Rules] DDExec Analysis

[Aegrah]

Summary

This PR proposes several new Linux DRs, originating from the analysis of the DDExec tool, which allows you to load shellcodes and binaries in memory abusing the dd binary (installed everywhere) from a regular sh/bash shell.

The following new rules are proposed:

1. Suspicious /proc/maps Discovery
2. Suspicious Dynamic Linker Discovery via od
3. Potential Memory Seeking Activity
4. Suspicious Memory grep Activity

Suspicious /proc/maps Discovery

Monitors for /proc/*/maps file reads. The /proc/*/maps file in Linux provides a memory map for a specific process, detailing the memory segments, permissions, and what files are mapped to these segments. Attackers may read a process's memory map to identify memory addresses for code injection or process hijacking.

Detection

0 FPs in telemetry and my testing stack over the last 365 days

process where host.os.type == "linux" and event.action == "exec" and event.type == "start" and
process.name in ("cat", "grep") and process.args : "/proc/*/maps" and process.entry_leader.name in (
  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"
)

Several TPs originating from DDExec, SSH injection and truffleproc/bash memory dump testing.

Suspicious Dynamic Linker Discovery via od

Monitors for dynamic linker discovery via the od utility. od (octal dump) is a command-line utility in Unix operating systems used for displaying data in various formats, including octal, hexadecimal, decimal, and ASCII, primarily used for examining and debugging binary files or data streams. Attackers can leverage od to analyze the dynamic linker by identifying injection points and craft exploits based on the observed behaviors and structures within these files.

Detection

0 FPs in telemetry and my testing stack over last 365 days

process where host.os.type == "linux" and event.action == "exec" and event.type == "start" and
process.name == "od" and process.args in (
  "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/etc/ld.so.preload", "/lib64/ld-linux-x86-64.so.2",
  "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2"
)

BBR - Potential Memory Seeking Activity

Monitors for the execution of Unix utilities that may be leveraged as memory address seekers. Attackers may leverage built-in utilities to seek specific memory addresses, allowing for potential future manipulation/exploitation.

Detection

There are several FPs in telemetry, and those FPs were related to development and therefore difficult to tune. Chose to add this as a BBR, so I can gather additional telemetry and potentially promote to DR in the future.

process where host.os.type == "linux" and event.action == "exec" and event.type == "start" and (
  (process.name == "tail" and process.args == "-c") or
  (process.name == "cmp" and process.args == "-i") or
  (process.name in ("hexdump", "xxd") and process.args == "-s") or
  (process.name == "dd" and process.args : ("skip*", "seek*"))
)

BBR - Memory grep Activity

Monitors for grep activity related to memory mapping. The /proc/*/maps file in Linux provides a memory map for a specific process, detailing the memory segments, permissions, and what files are mapped to these segments. Attackers may read a process's memory map to identify memory addresses for code injection or process hijacking.

Detection

0 FPs in telemetry nor my stack, however, given that I chose to go the process event category route, I am unable to specifically match the "/proc/pid/maps" file, therefore I created room for potential FPs by grepping random files. A workaround for this would be to use auditd_manager, and chain this with a /proc/pid/maps file read by grep. I chose not to do this for now as auditd_manager is not (yet) widely implemented, so this method will be more useful. Might be a way to tune in the future.

process where host.os.type == "linux" and event.action == "exec" and event.type == "start" and
process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]")

[Samirbous]

nice set of rules, one thing is to check for process exec only rules compatiblity with other datasources/index array to maximise rule usage.

[Aegrah]

@Samirbous ++, added endgame + audit_manager support.

[Aegrah]

When adding auditd_manager support, I noticed I must supply the event.dataset value in the query - this currently does not make sense. Will check with Terrance to see whether we can extend coverage without being forced to do this. Created this Meta for it: #3428.

[terrancedejesus]

Looks good!