Browse Rules

Launch Remote File Copy Tools in Container

Detect remote file copy tools (like rsync, scp, sftp, dcp) launched within a container, potentially indicating data exfiltration. Suggest refining this rule to accommodate legitimate use cases.

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.

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.

Schedule Cron Jobs

Detect scheduled cron jobs; this is a highly generic detection and certainly needs adjustments and profiling in your environment before operationalization. Simultaneously, exploiting the functionality of cron jobs is among one of the oldest TTPs used by adversaries.

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.

Program run with disallowed http proxy env

Detect curl or wget usage with HTTP_PROXY environment variable. Attackers can manipulate the HTTP_PROXY variable's value to redirect application's internal HTTP requests. This could expose sensitive information like authentication keys and private data.

Unexpected UDP Traffic

Detecting UDP traffic on ports other than 53 (DNS) or other commonly used ports. Misusing UDP is a known TTP among attackers. Monitoring unusual network activity is highly valuable but often generates significant noise, as is the case with this detection.

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.

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.

Launch Ingress Remote File Copy Tools in Container

Detect ingress remote file copy tools (such as curl or wget) launched inside containers. This rule can be considered a valuable auditing tool, but it has the potential to generate notable noise and requires careful profiling before full operationalization.

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.

Network Connection outside Local Subnet

Detect network traffic (inbound or outbound) from a container to a destination outside the local subnet. To operationalize this rule, profile your environment and update the template macro namespace_scope_network_only_subnet. Customizing network-related rules usually demands substantial engineering effort to ensure their functionality.

System procs network activity

Detect any unexpected network activity performed by system binaries that typically shouldn't perform network activity, including coreutils binaries (like sleep, mkdir, who, date, and others) or user management binaries (such as login, systemd, usermod, deluser, adduser, chpasswd, and others). This serves as a valuable baseline detection for network-related activities.

Mount Launched in Privileged Container

Detect filesystem mounts (using the mount binary) within a privileged container. Due to the elevated privileges, this action could be one of the TTPs used in an attempt to escape from a container to the host. This type of action is often preceded by reconnaissance activities, for which you can also create custom rules.

Launch Excessively Capable Container

Identify containers that start with a powerful set of capabilities, with exceptions for recognized trusted images. Similar to the "Launch Privileged Container" rule, this functions as a robust auditing rule. Compromised highly privileged containers can lead to substantial harm. For instance, if another rule is triggered within such a container, it might raise suspicion, prompting closer scrutiny.

Launch Suspicious Network Tool on Host

Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. This serves as a valuable general detection, but it's recommended to invest engineering effort to fine-tune it and prevent a high volume of legitimate logs. The host equivalent of "Launch Suspicious Network Tool in Container.".

Read environment variable from /proc files

An attempt to read process environment variables from /proc files. The consequences are akin to accessing traditional sensitive files, as sensitive data, including secrets, might be stored in environment variables. Understanding your environment, such as identifying critical namespaces, and incorporating extra filtering statements to alert exclusively for those, can enhance the rule's effectiveness.

Launch Suspicious Network Tool in Container

Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. This serves as a valuable general detection, but it's recommended to invest engineering effort to fine-tune it and prevent a high volume of legitimate logs. This rule complements the more specific "Netcat Remote Code Execution in Container" rule.

Launch Privileged Container

Detect the initial process initiation within a privileged container, with exemptions for known and trusted images. This rule primarily serves as an excellent auditing mechanism since highly privileged containers, when compromised, can result in significant harm. For instance, if another rule triggers within such a privileged container, it could be seen as more suspicious, prompting a closer inspection.

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.

Launch Package Management Process in Container

Detect package management processes executed within containers. An excellent auditing rule to monitor general drifts in containers. Particularly useful for newer rules like "Drop and execute new binary in container" during incident response investigations. This helps identify common anti-patterns of ad-hoc debugging. Simultaneously, to maintain optimal hygiene, it's recommended to prevent container drifts and instead opt for redeploying new containers.

Modify Shell Configuration File

Detect attempts to modify shell configuration files, primarily aimed at establishing persistence by automatically inserting commands into scripts executed by shells. The upstream rule excludes shell processes because they often create unnecessary noise. However, this might lead to missed detections. To customize the rule for your situation, you can fine-tune it using enhanced profiling. For example, you might want to only consider interactive shell processes (where proc.tty != 0).

Non sudo setuid

Detect attempts to change users through the use of setuid, with exceptions for sudo/su. The users "root" and "nobody" using setuid on themselves are also excluded, as setuid calls in these cases typically involve reducing privileges. By setting the setuid bit, an attacker could execute code in a different user's context, potentially with higher privileges. One drawback is the potential for noise, as many applications legitimately use this approach.

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.

Exfiltrating Artifacts via Kubernetes Control Plane

Detect the copying of artifacts from a container's file system using the Kubernetes control plane (kubectl cp). This rule can identify potential exfiltration of application secrets from containers' file systems, potentially revealing the outcomes of unauthorized access and control plane misuse via stolen identities (such as stolen credentials like Kubernetes serviceaccount tokens). Can be customized by the adopter to only monitor specific artifact paths, containers, or namespaces as needed.