Browse Rules

Adding ssh keys to authorized_keys

After gaining access, attackers can modify the authorized_keys file to maintain persistence on a victim host. Where authorized_keys files are modified via cloud APIs or command line interfaces, an adversary may achieve privilege escalation on the target virtual machine if they add a key to a higher-privileged user. This rules aims at detecting any modification to the authorized_keys file, that is usually located under the .ssh directory in any user's home directory. This rule complements the mor

Backdoored library loaded into SSHD (CVE-2024-3094)

This rule detects possible CVE-2024-3094 exploitation when the SSH daemon process loads a vulnerable version of the liblzma library. An attacker could exploit this to interfere with authentication in sshd via systemd, potentially compromising sensitive data or escalating their privileges.

Basic Interactive Reconnaissance

This rule detects basic interactive reconnaissance commands that are typically run by unsophisticated attackers or used in internal Red Team exercises. Interactive is defined as a terminal being present (proc.tty != 0). This could be any form of reverse shell or usage of kubectl exec or ssh etc. In addition, filtering for the process being the process group leader indicates that the command was "directly" typed into the terminal and not run as a result of a script. This rule is a basic auditing

BPF Program Not Profiled

BPF is a kernel technology that can be misused for malicious purposes, like "Linux Kernel Module Injection". This rule should be considered an auditing rule to notify you of any unprofiled BPF tools running in your environment. However, it requires customization after profiling your environment. BPF-powered agents make bpf syscalls all the time, so this rule only sends logs for BPF_PROG_LOAD calls (bpf cmd=5) in the enter event. If you also want to log whether the syscall failed or succeeded, re

Change namespace privileges via unshare

Unprivileged users in containers may not have CAP_SYS_ADMIN or other elevated privileges. However, they can use the unshare system call with CLONE_NEWNS or CLONE_NEWUSER to create or clone a namespace or user with the necessary privileges to conduct further attacks. It is best practice to block the unshare system call via seccomp if it is not needed. Misuse of unshare can be related to misconfigured Kubernetes clusters, for example.

Change thread namespace

An attempt to alter the namespace of a process (often performed while creating a container) through the setns syscall. Conversely, the same syscall setns is triggered when an unauthorized attempt is made to break out from the container to the host, for example, when using commands like `nsenter --target 1` and similar ones. Recommending to profile your environment and refine this rule for effective operationalization.

Clear Log Activities

Detect clearing of critical access log files, typically done to erase evidence that could be attributed to an adversary's actions. To effectively customize and operationalize this detection, check for potentially missing log file destinations relevant to your environment, and adjust the profiled containers you wish not to be alerted on.

Contact cloud metadata service from container

Detects attempts to communicate with the Cloud Instance Metadata Service from a container. This detection is narrowly focused and might not apply to your environment. In addition, it could generate noise and require fine-tuning.

Contact EC2 Instance Metadata Service From Container

Detects attempts to communicate with the EC2 Instance Metadata Service from a container. This detection is narrowly focused and might not apply to your environment. In addition, it could generate noise and require fine-tuning.

Contact K8S API Server From Container

Detect attempts to communicate with the K8S API Server from a container by non-profiled users. Kubernetes APIs play a pivotal role in configuring the cluster management lifecycle. Detecting potential unauthorized access to the API server is of utmost importance. Audit your complete infrastructure and pinpoint any potential machines from which the API server might be accessible based on your network layout. If Falco can't operate on all these machines, consider analyzing the Kubernetes audit logs

Container Access to Host Sensitive Paths

Detects container processes accessing paths that typically only exist when the host filesystem is mounted into the container (like /host, /rootfs, /hostfs). This may indicate a container escape attempt or a misconfigured volume mount that exposes the host filesystem. Legitimate monitoring or backup containers may access these paths, so tune accordingly using the user_known_host_path_access macro.

Container Drift Detected (chmod)

Detect new executables created within a container as a result of chmod. While this detection can generate significant noise, chmod usage is frequently linked to dropping and executing malicious implants. The newer rule "Drop and execute new binary in container" provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. However, this rule might be more relevant for auditing if applicable in your environment, such as when chmod is used on f

Container Drift Detected (open+create)

Detect new executables created within a container as a result of open+create. The newer rule "Drop and execute new binary in container" provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule.

Container Run as Root User

Container detected running as the root user. This should be taken into account especially when policies disallow containers from running with root user privileges. Note that a root user in containers doesn't inherently possess extensive power, as modern container environments define privileges through Linux capabilities. To learn more, check out the rule "Launch Privileged Container".

Create files below dev

Detect the creation of files under /dev except for authorized device management programs. This can reveal rootkits hiding files in /dev. Additionally, consider the "Execution from /dev/shm" rule. The upstream rule already covers some tuning scenarios that you can further expand upon.

Create Hardlink Over Sensitive Files

Detect hardlink created over a curated list of sensitive files or subdirectories under /etc/ or root directories. Can be customized as needed. Refer to further and equivalent guidance within the rule "Read sensitive file untrusted".

Create Hidden Files or Directories

Detecting hidden files or directories creation can serve as an auditing rule to track general system changes. Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases.

Create Symlink Over Sensitive Files

Detect symlinks created over a curated list of sensitive files or subdirectories under /etc/ or root directories. Can be customized as needed. Refer to further and equivalent guidance within the rule "Read sensitive file untrusted".

DB program spawned process

A program related to the database server creates an unexpected child process (other than itself). This is not supposed to happen and often follows SQL injection attacks. This behavioral detection could indicate potential unauthorized data extraction or tampering with the database.

Debugfs Launched in Privileged Container

Detect file system debugger debugfs launched inside a privileged container which might lead to container escape. This rule has a more narrow scope.

Decoding Payload in Container

Detect any use of {base64} decoding in a container. Legitimate applications may decode encoded payloads. The template list known_decode_payload_containers can be used for simple tuning and customization, or you can adopt custom, more refined tuning. Less sophisticated adversaries may {base64}-decode their payloads not only to obfuscate them, but also to ensure that the payload remains intact when the application processes it. Note that injecting commands into an application's input often results

Delete or rename shell history

Detect shell history deletion, frequently used by unsophisticated adversaries to eliminate evidence. Note that it can also trigger when exiting a Terminal shell, such as with `kubectl exec`, which may introduce some noise.

Detect crypto miners using the Stratum protocol

Miners commonly specify the mining pool to connect to using a URI that starts with "stratum+tcp". However, this rule is highly specific to this technique, and matching command-line arguments can generally be bypassed quite easily.

Detect outbound connections to common miner pool ports

Miners usually connect to miner pools using standard ports, and this rule flags such activity. Important: Falco currently sends DNS requests to resolve miner pool domains, which could trigger other alerts. Prior to enabling this rule, it's advised to ensure whether this is acceptable for your environment. This rule is specifically disabled for that reason.

Detect release_agent File Container Escapes

Detect an attempt to exploit a container escape using release_agent file. By running a container with certains capabilities, a privileged user can modify release_agent file and escape from the container.