CKS Monitoring, Logging and Runtime Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  evt.type=read and fd.name=/etc/passwd

  Why it's wrong here

  The 'read' syscall is used to read data from an already-open file descriptor; pairing it with 'fd.name=/etc/passwd' detects a process reading the password file—a possible post-exploitation reconnaissance step—but reading a file is a completely different operation from executing a shell. A shell launch occurs via the 'execve' syscall, which replaces the process image with a new executable, so this rule will miss every shell execution that never touches /etc/passwd. Moreover, it will generate false positives from legitimate system components like NSS libraries or 'getent' that routinely read that file, making it both noisy and semantically incorrect for shell detection.

• ✓

  evt.type=execve and proc.name in (bash, sh)

  Why this is correct

  This rule is correct because 'execve' is the fundamental Linux syscall that executes a new program by replacing the caller's memory image. In Falco, for an 'execve' event, 'proc.name' is the basename of the new executable, so filtering for 'bash' or 'sh' directly matches the execution of those shell binaries. This aligns exactly with the intended goal of detecting an attempt to run a shell, and it intentionally ignores file access and process creation events that do not themselves indicate shell execution.

• ✗

  evt.type=clone and proc.name=bash

  Why it's wrong here

  The 'clone' syscall creates a new process or thread (a fork-like operation), but it does not determine whether that process will later execute a shell; the child may simply continue running the same code as the parent or execute any other program via 'execve'. Additionally, using 'proc.name=bash' means this rule only fires when a process already named 'bash' clones itself, which would miss the typical scenario where a shell is launched directly by an 'execve' from a different process (e.g., a web server) without a preceding fork. Thus, clone-based detection is both too narrow—it ignores direct exec—and semantically wrong, because process creation is not evidence of shell execution.

• ✗

  evt.type=open and fd.name=/bin/bash

  Why it's wrong here

  The 'open' syscall with 'fd.name=/bin/bash' merely indicates that a file descriptor for the bash binary has been requested, which can happen for legitimate reasons such as reading metadata, hashing the file, or mapping it into memory; it does not signal that the binary is being executed. Actual program execution requires the kernel to process an 'execve' syscall, where the executable is loaded and run, and this is the event that should be monitored. Furthermore, this rule is highly bypassable because shells often reside at other paths (e.g., '/bin/sh' or '/usr/bin/bash'), and attackers may execute a renamed or copied shell binary from a non-standard location, producing a false negative.

Go deeper

Related to this question