falco-incubating_rules.yaml

# SPDX-License-Identifier: Apache-2.0
#
# Copyright (C) 2023 The Falco Authors.
#
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

# Information about rules tags and fields can be found here: https://falco.org/docs/rules/#tags-for-current-falco-ruleset
# The initial item in the `tags` fields reflects the maturity level of the rules introduced upon the proposal https://github.com/falcosecurity/rules/blob/main/proposals/20230605-rules-adoption-management-maturity-framework.md
# `tags` fields also include information about the type of workload inspection (host and/or container), and Mitre Attack killchain phases and Mitre TTP code(s)
# Mitre Attack References:
# [1] https://attack.mitre.org/tactics/enterprise/
# [2] https://raw.githubusercontent.com/mitre/cti/master/enterprise-attack/enterprise-attack.json

# Starting with version 8, the Falco engine supports exceptions.
# However the Falco rules file does not use them by default.
- required_engine_version: 0.31.0

- macro: open_write
  condition: (evt.type in (open,openat,openat2) and evt.is_open_write=true and fd.typechar='f' and fd.num>=0)

- macro: open_read
  condition: (evt.type in (open,openat,openat2) and evt.is_open_read=true and fd.typechar='f' and fd.num>=0)

- macro: open_directory
  condition: (evt.type in (open,openat,openat2) and evt.is_open_read=true and fd.typechar='d' and fd.num>=0)

# This macro `never_true` is used as placeholder for tuning negative logical sub-expressions, for example
# - macro: allowed_ssh_hosts
#   condition: (never_true)
# can be used in a rules' expression with double negation `and not allowed_ssh_hosts` which effectively evaluates
# to true and does nothing, the perfect empty template for `logical` cases as opposed to list templates.
# When tuning the rule you can override the macro with something useful, e.g.
# - macro: allowed_ssh_hosts
#   condition: (evt.hostname contains xyz)
- macro: never_true
  condition: (evt.num=0)

# This macro `always_true` is the flip side of the macro `never_true` and currently is commented out as
# it is not used. You can use it as placeholder for a positive logical sub-expression tuning template
# macro, e.g. `and custom_procs`, where
# - macro: custom_procs
#   condition: (always_true)
# later you can customize, override the macros to something like
# - macro: custom_procs
#   condition: (proc.name in (custom1, custom2, custom3))
# - macro: always_true
#   condition: (evt.num>=0)

# In some cases, such as dropped system call events, information about
# the process name may be missing. For some rules that really depend
# on the identity of the process performing an action such as opening
# a file, etc., we require that the process name be known.
- macro: proc_name_exists
  condition: (not proc.name in ("<NA>","N/A"))

- macro: rename
  condition: (evt.type in (rename, renameat, renameat2))

- macro: remove
  condition: (evt.type in (rmdir, unlink, unlinkat))

- macro: modify
  condition: (rename or remove)

- macro: spawned_process
  condition: (evt.type in (execve, execveat) and evt.dir=<)

- macro: chmod
  condition: (evt.type in (chmod, fchmod, fchmodat) and evt.dir=<)

- list: shell_binaries
  items: [ash, bash, csh, ksh, sh, tcsh, zsh, dash]

- list: ssh_binaries
  items: [
    sshd, sftp-server, ssh-agent,
    ssh, scp, sftp,
    ssh-keygen, ssh-keysign, ssh-keyscan, ssh-add
    ]

- list: coreutils_binaries
  items: [
    truncate, sha1sum, numfmt, fmt, fold, uniq, cut, who,
    groups, csplit, sort, expand, printf, printenv, unlink, tee, chcon, stat,
    basename, split, nice, "yes", whoami, sha224sum, hostid, users, stdbuf,
    base64, unexpand, cksum, od, paste, nproc, pathchk, sha256sum, wc, test,
    comm, arch, du, factor, sha512sum, md5sum, tr, runcon, env, dirname,
    tsort, join, shuf, install, logname, pinky, nohup, expr, pr, tty, timeout,
    tail, "[", seq, sha384sum, nl, head, id, mkfifo, sum, dircolors, ptx, shred,
    tac, link, chroot, vdir, chown, touch, ls, dd, uname, "true", pwd, date,
    chgrp, chmod, mktemp, cat, mknod, sync, ln, "false", rm, mv, cp, echo,
    readlink, sleep, stty, mkdir, df, dir, rmdir, touch
    ]

# dpkg -L login | grep bin | xargs ls -ld | grep -v '^d' | awk '{print $9}' | xargs -L 1 basename | tr "\\n" ","
- list: login_binaries
  items: [
    login, systemd, '"(systemd)"', systemd-logind, su,
    nologin, faillog, lastlog, newgrp, sg
    ]

# dpkg -L passwd | grep bin | xargs ls -ld | grep -v '^d' | awk '{print $9}' | xargs -L 1 basename | tr "\\n" ","
- list: passwd_binaries
  items: [
    shadowconfig, grpck, pwunconv, grpconv, pwck,
    groupmod, vipw, pwconv, useradd, newusers, cppw, chpasswd, usermod,
    groupadd, groupdel, grpunconv, chgpasswd, userdel, chage, chsh,
    gpasswd, chfn, expiry, passwd, vigr, cpgr, adduser, addgroup, deluser, delgroup
    ]

# repoquery -l shadow-utils | grep bin | xargs ls -ld | grep -v '^d' |
#     awk '{print $9}' | xargs -L 1 basename | tr "\\n" ","
- list: shadowutils_binaries
  items: [
    chage, gpasswd, lastlog, newgrp, sg, adduser, deluser, chpasswd,
    groupadd, groupdel, addgroup, delgroup, groupmems, groupmod, grpck, grpconv, grpunconv,
    newusers, pwck, pwconv, pwunconv, useradd, userdel, usermod, vigr, vipw, unix_chkpwd
    ]

- list: sysdigcloud_binaries
  items: [setup-backend, dragent, sdchecks]

- list: k8s_binaries
  items: [hyperkube, skydns, kube2sky, exechealthz, weave-net, loopback, bridge, openshift-sdn, openshift]

- list: lxd_binaries
  items: [lxd, lxcfs]

- list: db_server_binaries
  items: [mysqld, postgres, sqlplus]

# The explicit quotes are needed to avoid the - characters being
# interpreted by the filter expression.
- list: rpm_binaries
  items: [dnf, dnf-automatic, rpm, rpmkey, yum, '"75-system-updat"', rhsmcertd-worke, rhsmcertd, subscription-ma,
          repoquery, rpmkeys, rpmq, yum-cron, yum-config-mana, yum-debug-dump,
          abrt-action-sav, rpmdb_stat, microdnf, rhn_check, yumdb]

- list: deb_binaries
  items: [dpkg, dpkg-preconfigu, dpkg-reconfigur, dpkg-divert, apt, apt-get, aptitude,
    frontend, preinst, add-apt-reposit, apt-auto-remova, apt-key,
    apt-listchanges, unattended-upgr, apt-add-reposit, apt-cache, apt.systemd.dai
    ]
- list: python_package_managers
  items: [pip, pip3, conda]

# The truncated dpkg-preconfigu is intentional, process names are
# truncated at the falcosecurity-libs level.
- list: package_mgmt_binaries
  items: [rpm_binaries, deb_binaries, update-alternat, gem, npm, python_package_managers, sane-utils.post, alternatives, chef-client, apk, snapd]

- macro: package_mgmt_procs
  condition: (proc.name in (package_mgmt_binaries))

- macro: package_mgmt_ancestor_procs
  condition: (proc.pname in (package_mgmt_binaries) or
             proc.aname[2] in (package_mgmt_binaries) or
             proc.aname[3] in (package_mgmt_binaries) or
             proc.aname[4] in (package_mgmt_binaries))

# A canonical set of processes that run other programs with different
# privileges or as a different user.
- list: userexec_binaries
  items: [sudo, su, suexec, critical-stack, dzdo]

- list: known_setuid_binaries
  items: [
    sshd, dbus-daemon-lau, ping, ping6, critical-stack-, pmmcli,
    filemng, PassengerAgent, bwrap, osdetect, nginxmng, sw-engine-fpm,
    start-stop-daem
    ]

- list: user_mgmt_binaries
  items: [login_binaries, passwd_binaries, shadowutils_binaries]

- list: dev_creation_binaries
  items: [blkid, rename_device, update_engine, sgdisk]

- list: nomachine_binaries
  items: [nxexec, nxnode.bin, nxserver.bin, nxclient.bin]

- macro: system_procs
  condition: (proc.name in (coreutils_binaries, user_mgmt_binaries))

- list: mail_binaries
  items: [
    sendmail, sendmail-msp, postfix, procmail, exim4,
    pickup, showq, mailq, dovecot, imap-login, imap,
    mailmng-core, pop3-login, dovecot-lda, pop3
    ]

# RFC1918 addresses were assigned for private network usage
- list: rfc_1918_addresses
  items: ['"10.0.0.0/8"', '"172.16.0.0/12"', '"192.168.0.0/16"']

- macro: outbound
  condition: >
    (((evt.type = connect and evt.dir=<) or
      (evt.type in (sendto,sendmsg) and evt.dir=< and
       fd.l4proto != tcp and fd.connected=false and fd.name_changed=true)) and
     (fd.typechar = 4 or fd.typechar = 6) and
     (fd.ip != "0.0.0.0" and fd.net != "127.0.0.0/8" and not fd.snet in (rfc_1918_addresses)) and
     (evt.rawres >= 0 or evt.res = EINPROGRESS))

# Very similar to inbound/outbound, but combines the tests together
# for efficiency.
- macro: inbound_outbound
  condition: >
    ((((evt.type in (accept,accept4,listen,connect) and evt.dir=<)) and
     (fd.typechar = 4 or fd.typechar = 6)) and
     (fd.ip != "0.0.0.0" and fd.net != "127.0.0.0/8") and
     (evt.rawres >= 0 or evt.res = EINPROGRESS))

- list: bash_config_filenames
  items: [.bashrc, .bash_profile, .bash_history, .bash_login, .bash_logout, .inputrc, .profile]

- list: bash_config_files
  items: [/etc/profile, /etc/bashrc]

# Covers both csh and tcsh
- list: csh_config_filenames
  items: [.cshrc, .login, .logout, .history, .tcshrc, .cshdirs]

- list: csh_config_files
  items: [/etc/csh.cshrc, /etc/csh.login]

- list: zsh_config_filenames
  items: [.zshenv, .zprofile, .zshrc, .zlogin, .zlogout]

- list: shell_config_filenames
  items: [bash_config_filenames, csh_config_filenames, zsh_config_filenames]

- list: shell_config_files
  items: [bash_config_files, csh_config_files]

- list: shell_config_directories
  items: [/etc/zsh]

- macro: user_known_shell_config_modifiers
  condition: (never_true)

- rule: Modify Shell Configuration File
  desc: > 
    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).
  condition: >
    open_write 
    and (fd.filename in (shell_config_filenames) or
         fd.name in (shell_config_files) or
         fd.directory in (shell_config_directories))
    and not proc.name in (shell_binaries)
    and not exe_running_docker_save
    and not user_known_shell_config_modifiers
  output: A shell configuration file has been modified (file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority:
    WARNING
  tags: [maturity_incubating, host, container, filesystem, mitre_persistence, T1546.004]

- macro: user_known_cron_jobs
  condition: (never_true)

- rule: Schedule Cron Jobs
  desc: >
    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.
  condition: >
    ((open_write and fd.name startswith /etc/cron) or
     (spawned_process and proc.name = "crontab")) 
    and not user_known_cron_jobs
  output: Cron jobs were scheduled to run (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority:
    NOTICE
  tags: [maturity_incubating, host, container, filesystem, mitre_execution, T1053.003]

# Use this to test whether the event occurred within a container.
#
# When displaying container information in the output field, use
# %container.info, without any leading term (file=%fd.name
# %container.info user=%user.name user_loginuid=%user.loginuid, and not file=%fd.name
# container=%container.info user=%user.name user_loginuid=%user.loginuid). The output will change
# based on the context and whether or not -pk/-pm/-pc was specified on
# the command line.
- macro: container
  condition: (container.id != host)

- macro: container_started
  condition: >
    ((evt.type = container or
     (spawned_process and proc.vpid=1)) and
     container.image.repository != incomplete)

- list: cron_binaries
  items: [anacron, cron, crond, crontab]

# Qualys seems to run a variety of shell subprocesses, at various
# levels. This checks at a few levels without the cost of a full
# proc.aname, which traverses the full parent hierarchy.
- macro: run_by_qualys
  condition: >
    (proc.pname=qualys-cloud-ag or
     proc.aname[2]=qualys-cloud-ag or
     proc.aname[3]=qualys-cloud-ag or
     proc.aname[4]=qualys-cloud-ag)

- macro: run_by_sumologic_securefiles
  condition: >
    ((proc.cmdline="usermod -a -G sumologic_collector" or
      proc.cmdline="groupadd sumologic_collector") and
     (proc.pname=secureFiles.sh and proc.aexe[2] endswith java))

- macro: run_by_yum
  condition: ((proc.pname=sh and proc.aname[2]=yum) or
              (proc.aname[2]=sh and proc.aname[3]=yum))

- macro: run_by_ms_oms
  condition: >
    (proc.aname[3] startswith omsagent- or
     proc.aname[3] startswith scx-)

- macro: run_by_google_accounts_daemon
  condition: >
    (proc.aname[1] startswith google_accounts or
     proc.aname[2] startswith google_accounts or
     proc.aname[3] startswith google_accounts)

- macro: java_running_sdjagent
  condition: (proc.exe endswith java and proc.cmdline contains sdjagent.jar)

- macro: kubelet_running_loopback
  condition: (proc.pname=kubelet and proc.name=loopback)

- macro: rancher_agent
  condition: (proc.name=agent and container.image.repository contains "rancher/agent")

- macro: rancher_network_manager
  condition: (proc.name=rancher-bridge and container.image.repository contains "rancher/network-manager")

- macro: exe_running_docker_save
  condition: >
    (proc.name = "exe"
    and (proc.cmdline contains "/var/lib/docker"
    or proc.cmdline contains "/var/run/docker")
    and proc.pname in (dockerd, docker, dockerd-current, docker-current))

- macro: user_ssh_directory
  condition: (fd.name contains '/.ssh/' and fd.name glob '/home/*/.ssh/*')

# The rule below is disabled by default as many system management tools
# like ansible, etc can read these files/paths. Enable it using this macro.
- macro: user_known_read_ssh_information_activities
  condition: (never_true)

- rule: Read ssh information
  desc: > 
    This rule identifies attempts to read files within ssh directories using programs that are not related to ssh. It's a simple and 
    versatile detection method that works well alongside more specific rules focused on sensitive file access. You have a couple of 
    options for using this rule effectively: you can adjust the specialized rules to cover all the important scenarios and ensure 
    precedence in rule smatching for those, or you can analyze the combined view of ssh-related file access across various rules on 
    your downstream computing platform. Just like with other rules, you can narrow down monitoring to specific processes, or you can 
    limit it to interactive access only.
  condition: >
    (open_read or open_directory) 
     and (user_ssh_directory or fd.name startswith /root/.ssh)
     and not user_known_read_ssh_information_activities 
     and not proc.name in (ssh_binaries)
  output: ssh-related file/directory read by non-ssh program (file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: ERROR
  tags: [maturity_incubating, host, container, filesystem, mitre_collection, T1005]

- macro: calico_node
  condition: (container.image.repository endswith calico/node and proc.name=calico-node)

- macro: postgres_running_wal_e
  condition: (proc.pname=postgres and (proc.cmdline startswith "sh -c envdir /etc/wal-e.d/env /usr/local/bin/wal-e" or proc.cmdline startswith "sh -c envdir \"/run/etc/wal-e.d/env\" wal-g wal-push"))

- macro: user_known_db_spawned_processes
  condition: (never_true)

- rule: DB program spawned process
  desc: >
    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.
  condition: >
    spawned_process
    and proc.pname in (db_server_binaries)
    and not proc.name in (db_server_binaries)
    and not postgres_running_wal_e
    and not user_known_db_spawned_processes
  output: Database-related program spawned process other than itself (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: NOTICE
  tags: [maturity_incubating, host, container, process, database, mitre_execution, T1190]

# This list allows for easy additions to the set of commands allowed
# to change thread namespace without having to copy and override the
# entire change thread namespace rule.
- list: user_known_change_thread_namespace_binaries
  items: [crio, multus]

- macro: user_known_change_thread_namespace_activities
  condition: (never_true)

- list: network_plugin_binaries
  items: [aws-cni, azure-vnet]

- macro: weaveworks_scope
  condition: (container.image.repository endswith weaveworks/scope and proc.name=scope)

- rule: Change thread namespace
  desc: >
    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.
  condition: >
    evt.type=setns and evt.dir=<
    and proc_name_exists
    and not (container.id=host and proc.name in (docker_binaries, k8s_binaries, lxd_binaries, nsenter))
    and not proc.name in (sysdigcloud_binaries, sysdig, calico, oci-umount, cilium-cni, network_plugin_binaries)
    and not proc.name in (user_known_change_thread_namespace_binaries)
    and not proc.name startswith "runc"
    and not proc.cmdline startswith "containerd"
    and not proc.pname in (sysdigcloud_binaries, hyperkube, kubelet, protokube, dockerd, tini, aws)
    and not java_running_sdjagent
    and not kubelet_running_loopback
    and not rancher_agent
    and not rancher_network_manager
    and not calico_node
    and not weaveworks_scope
    and not user_known_change_thread_namespace_activities
  output: Namespace change (setns) by unexpected program (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE
  tags: [maturity_incubating, host, container, process, mitre_privilege_escalation, T1611]

- rule: Change namespace privileges via unshare
  desc: > 
    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.
  condition: >
    evt.type=unshare and evt.dir=< 
    and container 
    and not thread.cap_permitted contains CAP_SYS_ADMIN
  output: Change namespace privileges via unshare (res=%evt.res evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE
  tags: [maturity_incubating, container, mitre_privilege_escalation, T1611]

- macro: allowed_openshift_registry_root
  condition: >
    (container.image.repository startswith openshift3/ or
     container.image.repository startswith registry.redhat.io/openshift3/ or
     container.image.repository startswith registry.access.redhat.com/openshift3/)

# Source: https://docs.openshift.com/enterprise/3.2/install_config/install/disconnected_install.html
- macro: openshift_image
  condition: >
    (allowed_openshift_registry_root and
      (container.image.repository endswith /logging-deployment or
       container.image.repository endswith /logging-elasticsearch or
       container.image.repository endswith /logging-kibana or
       container.image.repository endswith /logging-fluentd or
       container.image.repository endswith /logging-auth-proxy or
       container.image.repository endswith /metrics-deployer or
       container.image.repository endswith /metrics-hawkular-metrics or
       container.image.repository endswith /metrics-cassandra or
       container.image.repository endswith /metrics-heapster or
       container.image.repository endswith /ose-haproxy-router or
       container.image.repository endswith /ose-deployer or
       container.image.repository endswith /ose-sti-builder or
       container.image.repository endswith /ose-docker-builder or
       container.image.repository endswith /ose-pod or
       container.image.repository endswith /ose-node or
       container.image.repository endswith /ose-docker-registry or
       container.image.repository endswith /prometheus-node-exporter or
       container.image.repository endswith /image-inspector))

- list: redhat_io_images_privileged
  items: [registry.redhat.io/openshift-logging/fluentd-rhel8, registry.redhat.io/openshift4/ose-csi-node-driver-registrar, registry.redhat.io/openshift4/ose-kubernetes-nmstate-handler-rhel8, registry.redhat.io/openshift4/ose-local-storage-diskmaker]

- macro: redhat_image
  condition: >
    (container.image.repository in (redhat_io_images_privileged))

# https://docs.aws.amazon.com/eks/latest/userguide/add-ons-images.html
#  official AWS EKS registry list. AWS has different ECR repo per region
- macro: allowed_aws_ecr_registry_root_for_eks
  condition: >
    (container.image.repository startswith "602401143452.dkr.ecr" or
     container.image.repository startswith "877085696533.dkr.ecr" or
     container.image.repository startswith "800184023465.dkr.ecr" or
     container.image.repository startswith "918309763551.dkr.ecr" or
     container.image.repository startswith "961992271922.dkr.ecr" or
     container.image.repository startswith "590381155156.dkr.ecr" or
     container.image.repository startswith "558608220178.dkr.ecr" or
     container.image.repository startswith "151742754352.dkr.ecr" or
     container.image.repository startswith "013241004608.dkr.ecr")

- macro: aws_eks_core_images
  condition: >
    (allowed_aws_ecr_registry_root_for_eks and
    (container.image.repository endswith ".amazonaws.com/amazon-k8s-cni" or
     container.image.repository endswith ".amazonaws.com/eks/kube-proxy"))

# These images are allowed both to run with --privileged and to mount
# sensitive paths from the host filesystem.
#
# NOTE: This list is only provided for backwards compatibility with
# older local falco rules files that may have been appending to
# trusted_images. To make customizations, it's better to add images to
# either privileged_images or falco_sensitive_mount_images.
- list: trusted_images
  items: []

# Add conditions to this macro (probably in a separate file,
# overwriting this macro) to specify additional containers that are
# trusted and therefore allowed to run privileged *and* with sensitive
# mounts.
#
# Like trusted_images, this is deprecated in favor of
# user_privileged_containers and user_sensitive_mount_containers and
# is only provided for backwards compatibility.
#
# In this file, it just takes one of the images in trusted_containers
# and repeats it.
- macro: user_trusted_containers
  condition: (never_true)

- list: sematext_images
  items: [docker.io/sematext/sematext-agent-docker, docker.io/sematext/agent, docker.io/sematext/logagent,
          registry.access.redhat.com/sematext/sematext-agent-docker,
          registry.access.redhat.com/sematext/agent,
          registry.access.redhat.com/sematext/logagent]

# Falco containers
- list: falco_containers
  items:
    - falcosecurity/falco
    - docker.io/falcosecurity/falco
    - public.ecr.aws/falcosecurity/falco

# Falco no driver containers
    - falcosecurity/falco-no-driver
    - docker.io/falcosecurity/falco-no-driver
    - public.ecr.aws/falcosecurity/falco-no-driver

# These container images are allowed to run with --privileged and full set of capabilities
- list: falco_privileged_images
  items: [
    falco_containers,
    docker.io/calico/node,
    calico/node,
    docker.io/cloudnativelabs/kube-router,
    docker.io/docker/ucp-agent,
    docker.io/mesosphere/mesos-slave,
    docker.io/rook/toolbox,
    docker.io/sysdig/sysdig,
    gcr.io/google_containers/kube-proxy,
    gcr.io/google-containers/startup-script,
    gcr.io/projectcalico-org/node,
    gke.gcr.io/kube-proxy,
    gke.gcr.io/gke-metadata-server,
    gke.gcr.io/netd-amd64,
    gke.gcr.io/watcher-daemonset,
    gcr.io/google-containers/prometheus-to-sd,
    registry.k8s.io/ip-masq-agent-amd64,
    registry.k8s.io/kube-proxy,
    registry.k8s.io/prometheus-to-sd,
    quay.io/calico/node,
    sysdig/sysdig,
    sematext_images,
    registry.k8s.io/dns/k8s-dns-node-cache,
    mcr.microsoft.com/oss/kubernetes/kube-proxy
  ]

- macro: falco_privileged_containers
  condition: (openshift_image or
              user_trusted_containers or
              aws_eks_core_images or
              container.image.repository in (trusted_images) or
              container.image.repository in (falco_privileged_images) or
              container.image.repository startswith istio/proxy_ or
              container.image.repository startswith quay.io/sysdig/)

# Add conditions to this macro (probably in a separate file,
# overwriting this macro) to specify additional containers that are
# allowed to run privileged
#
# In this file, it just takes one of the images in falco_privileged_images
# and repeats it.
- macro: user_privileged_containers
  condition: (never_true)

- rule: Launch Privileged Container
  desc: > 
    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.
  condition: >
    container_started 
    and container
    and container.privileged=true
    and not falco_privileged_containers
    and not user_privileged_containers
    and not redhat_image
  output: Privileged container started (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: INFO
  tags: [maturity_incubating, container, cis, mitre_execution, T1610, PCI_DSS_10.2.5]

# These capabilities were used in the past to escape from containers
- macro: excessively_capable_container
  condition: >
    (thread.cap_permitted contains CAP_SYS_ADMIN
    or thread.cap_permitted contains CAP_SYS_MODULE
    or thread.cap_permitted contains CAP_SYS_RAWIO
    or thread.cap_permitted contains CAP_SYS_PTRACE
    or thread.cap_permitted contains CAP_SYS_BOOT
    or thread.cap_permitted contains CAP_SYSLOG
    or thread.cap_permitted contains CAP_DAC_READ_SEARCH
    or thread.cap_permitted contains CAP_NET_ADMIN
    or thread.cap_permitted contains CAP_BPF)

- rule: Launch Excessively Capable Container
  desc: > 
    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.
  condition: >
    container_started 
    and container
    and excessively_capable_container
    and not falco_privileged_containers
    and not user_privileged_containers
  output: Excessively capable container started (cap_permitted=%thread.cap_permitted evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: INFO
  tags: [maturity_incubating, container, cis, mitre_execution, T1610]

- macro: login_doing_dns_lookup
  condition: (proc.name=login and fd.l4proto=udp and fd.sport=53)

# sockfamily ip is to exclude certain processes (like 'groups') that communicate on unix-domain sockets
# systemd can listen on ports to launch things like sshd on demand
- rule: System procs network activity
  desc: >
    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.
  condition: >
    inbound_outbound
    and fd.sockfamily = ip 
    and (system_procs or proc.name in (shell_binaries))
    and not proc.name in (known_system_procs_network_activity_binaries)
    and not login_doing_dns_lookup
    and not user_expected_system_procs_network_activity_conditions
  output: Known system binary sent/received network traffic (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE
  tags: [maturity_incubating, host, network, process, mitre_execution, T1059]

# This list allows easily whitelisting system proc names that are
# expected to communicate on the network.
- list: known_system_procs_network_activity_binaries
  items: [systemd, hostid, id]

# This macro allows specifying conditions under which a system binary
# is allowed to communicate on the network. For instance, only specific
# proc.cmdline values could be allowed to be more granular in what is
# allowed.
- macro: user_expected_system_procs_network_activity_conditions
  condition: (never_true)

# When filled in, this should look something like:
# (proc.env contains "HTTP_PROXY=http://my.http.proxy.com ")
# The trailing space is intentional so avoid matching on prefixes of
# the actual proxy.
- macro: allowed_ssh_proxy_env
  condition: (never_true)

- list: http_proxy_binaries
  items: [curl, wget]

- macro: http_proxy_procs
  condition: (proc.name in (http_proxy_binaries))

- rule: Program run with disallowed http proxy env
  desc: >
    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.
  condition: >
    spawned_process 
    and http_proxy_procs 
    and proc.env icontains HTTP_PROXY
    and not allowed_ssh_proxy_env 
  output: Curl or wget run with disallowed HTTP_PROXY environment variable (env=%proc.env evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: NOTICE
  tags: [maturity_incubating, host, container, users, mitre_execution, T1204]

- list: openvpn_udp_ports
  items: [1194, 1197, 1198, 8080, 9201]

- list: l2tp_udp_ports
  items: [500, 1701, 4500, 10000]

- list: statsd_ports
  items: [8125]

- list: ntp_ports
  items: [123]

# Some applications will connect a udp socket to an address only to
# test connectivity. Assuming the udp connect works, they will follow
# up with a tcp connect that actually sends/receives data.
#
# With that in mind, we listed a few commonly seen ports here to avoid
# some false positives. In addition, we make the main rule opt-in, so
# it's disabled by default.
- list: test_connect_ports
  items: [0, 9, 80, 3306]

- list: expected_udp_ports
  items: [53, openvpn_udp_ports, l2tp_udp_ports, statsd_ports, ntp_ports, test_connect_ports]

- macro: expected_udp_traffic
  condition: fd.port in (expected_udp_ports)

- rule: Unexpected UDP Traffic
  desc: > 
    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.
  condition: > 
    inbound_outbound 
    and fd.l4proto=udp 
    and not expected_udp_traffic
  output: Unexpected UDP Traffic Seen (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE
  tags: [maturity_incubating, host, container, network, mitre_exfiltration, TA0011]

- macro: somebody_becoming_themselves
  condition: ((user.name=nobody and evt.arg.uid=nobody) or
              (user.name=www-data and evt.arg.uid=www-data) or
              (user.name=_apt and evt.arg.uid=_apt) or
              (user.name=postfix and evt.arg.uid=postfix) or
              (user.name=pki-agent and evt.arg.uid=pki-agent) or
              (user.name=pki-acme and evt.arg.uid=pki-acme) or
              (user.name=nfsnobody and evt.arg.uid=nfsnobody) or
              (user.name=postgres and evt.arg.uid=postgres))

- macro: nrpe_becoming_nagios
  condition: (proc.name=nrpe and evt.arg.uid=nagios)

# In containers, the user name might be for a uid that exists in the
# container but not on the host. (See
# https://github.com/draios/sysdig/issues/954). So in that case, allow
# a setuid.
- macro: known_user_in_container
  condition: (container and not user.name in ("<NA>","N/A",""))

# Add conditions to this macro (probably in a separate file,
# overwriting this macro) to allow for specific combinations of
# programs changing users by calling setuid.
#
# In this file, it just takes one of the condition in the base macro
# and repeats it.
- macro: user_known_non_sudo_setuid_conditions
  condition: (user.name=root)

# sshd, mail programs attempt to setuid to root even when running as non-root. Excluding here to avoid meaningless FPs
- rule: Non sudo setuid
  desc: >
    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.
  condition: >
    evt.type=setuid and evt.dir=>
    and (known_user_in_container or not container)
    and not (user.name=root or user.uid=0)
    and not somebody_becoming_themselves
    and not proc.name in (known_setuid_binaries, userexec_binaries, mail_binaries, docker_binaries,
                          nomachine_binaries)
    and not proc.name startswith "runc:"
    and not java_running_sdjagent
    and not nrpe_becoming_nagios
    and not user_known_non_sudo_setuid_conditions
  output: Unexpected setuid call by non-sudo, non-root program (arg_uid=%evt.arg.uid evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE
  tags: [maturity_incubating, host, container, users, mitre_privilege_escalation, T1548.001]

- macro: user_known_user_management_activities
  condition: (never_true)

- macro: chage_list
  condition: (proc.name=chage and (proc.cmdline contains "-l" or proc.cmdline contains "--list"))

- rule: User mgmt binaries
  desc: >
    Detect activity by any programs that can manage users, passwords, or permissions (such as login, systemd, usermod, deluser, adduser, 
    chpasswd, and others). sudo and su are excluded. Activity in containers is also excluded -- some containers create custom users on 
    top of a base linux distribution at startup. Some innocuous command lines that don't actually change anything are excluded. You might 
    want to consider applying this rule to container actions as well.
  condition: >
    spawned_process 
    and not container
    and proc.name in (user_mgmt_binaries) 
    and not proc.name in (su, sudo, lastlog, nologin, unix_chkpwd)  
    and not proc.pname in (cron_binaries, systemd, systemd.postins, udev.postinst, run-parts)
    and not proc.cmdline startswith "passwd -S" 
    and not proc.cmdline startswith "useradd -D" 
    and not proc.cmdline startswith "systemd --version" 
    and not run_by_qualys 
    and not run_by_sumologic_securefiles 
    and not run_by_yum 
    and not run_by_ms_oms 
    and not run_by_google_accounts_daemon 
    and not chage_list 
    and not user_known_user_management_activities
  output: User management binary command run outside of container (gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: NOTICE
  tags: [maturity_incubating, host, users, software_mgmt, mitre_persistence, T1098]

- list: allowed_dev_files
  items: [
    /dev/null, /dev/stdin, /dev/stdout, /dev/stderr,
    /dev/random, /dev/urandom, /dev/console, /dev/kmsg
    ]

- macro: user_known_create_files_below_dev_activities
  condition: (never_true)

# (we may need to add additional checks against false positives, see:
# https://bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/86153)
- rule: Create files below dev
  desc: > 
    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.
  condition: >
    (evt.type = creat or (evt.type in (open,openat,openat2)))
    and evt.arg.flags contains O_CREAT
    and fd.directory = /dev
    and not proc.name in (dev_creation_binaries)
    and not fd.name in (allowed_dev_files)
    and not fd.name startswith /dev/tty
    and not user_known_create_files_below_dev_activities
  output: File created below /dev by untrusted program (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: ERROR
  tags: [maturity_incubating, host, filesystem, mitre_persistence, T1543]

# In a local/user rules file, you could override this macro to
# explicitly enumerate the container images that you want to allow
# access to EC2 metadata. In this main falco rules file, there isn't
# any way to know all the containers that should have access, so any
# container is allowed, by repeating the "container" macro. In the
# overridden macro, the condition would look something like
# (container.image.repository = vendor/container-1 or
# container.image.repository = vendor/container-2 or ...)
- macro: ec2_metadata_containers
  condition: (never_true)

# On EC2 instances, 169.254.169.254 is a special IP used to fetch
# metadata about the instance. It may be desirable to prevent access
# to this IP from containers.
- rule: Contact EC2 Instance Metadata Service From Container
  desc: > 
    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.
  condition: > 
    outbound 
    and container
    and fd.sip="169.254.169.254" 
    and not ec2_metadata_containers
  output: Outbound connection to EC2 instance metadata service (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE
  tags: [maturity_incubating, network, aws, container, mitre_credential_access, T1552.005]

# This rule is not enabled by default, since this rule is for cloud environment(GCP, AWS and Azure) only.
# You can filter the container that you want to allow access to metadata by overwriting user_known_metadata_access macro.
- macro: user_known_metadata_access
  condition: (k8s.ns.name = "kube-system")

# On GCP, AWS and Azure, 169.254.169.254 is a special IP used to fetch
# metadata about the instance. The metadata could be used to get credentials by attackers.
- rule: Contact cloud metadata service from container
  desc: > 
    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.
  condition: > 
    outbound 
    and container 
    and fd.sip="169.254.169.254" 
    and not user_known_metadata_access
  enabled: true
  output: Outbound connection to cloud instance metadata service (connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE
  tags: [maturity_incubating, network, container, mitre_discovery, T1565]

- list: network_tool_binaries
  items: [nc, ncat, netcat, nmap, dig, tcpdump, tshark, ngrep, telnet, mitmproxy, socat, zmap]

- macro: network_tool_procs
  condition: (proc.name in (network_tool_binaries))

# In a local/user rules file, create a condition that matches legitimate uses
# of a package management process inside a container.
#
# For example:
# - macro: user_known_package_manager_in_container
#   condition: proc.cmdline="dpkg -l"
- macro: user_known_package_manager_in_container
  condition: (never_true)

# Container is supposed to be immutable. Package management should be done in building the image.
- macro: pkg_mgmt_in_kube_proxy
  condition: >
    (proc.cmdline startswith "update-alternat"
    and container.image.repository = "registry.k8s.io/kube-proxy")

- rule: Launch Package Management Process in Container
  desc: > 
    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.
  condition: >
    spawned_process
    and container
    and user.name != "_apt"
    and package_mgmt_procs
    and not package_mgmt_ancestor_procs
    and not user_known_package_manager_in_container
    and not pkg_mgmt_in_kube_proxy
  output: Package management process launched in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: ERROR
  tags: [maturity_incubating, container, process, software_mgmt, mitre_persistence, T1505]

- macro: user_known_network_tool_activities
  condition: (never_true)

- rule: Launch Suspicious Network Tool in Container
  desc: >
    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.
  condition: >
    spawned_process 
    and container 
    and network_tool_procs 
    and not user_known_network_tool_activities
  output: Network tool launched in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: NOTICE
  tags: [maturity_incubating, container, network, process, mitre_execution, T1059]

- rule: Launch Suspicious Network Tool on Host
  desc: >
    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.".
  condition: >
    spawned_process 
    and not container 
    and network_tool_procs 
    and not user_known_network_tool_activities
  output: Network tool launched on host (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags)
  priority: NOTICE
  tags: [maturity_incubating, host, network, process, mitre_execution, T1059]

# here `ash_history` will match both `bash_history` and `ash_history`
- macro: modify_shell_history
  condition: >
    (modify and (
      evt.arg.name endswith "ash_history" or
      evt.arg.name endswith "zsh_history" or
      evt.arg.name contains "fish_read_history" or
      evt.arg.name endswith "fish_history" or
      evt.arg.oldpath endswith "ash_history" or
      evt.arg.oldpath endswith "zsh_history" or
      evt.arg.oldpath contains "fish_read_history" or
      evt.arg.oldpath endswith "fish_history" or
      evt.arg.path endswith "ash_history" or
      evt.arg.path endswith "zsh_history" or
      evt.arg.path contains "fish_read_history" or
      evt.arg.path endswith "fish_history"))

# here `ash_history` will match both `bash_history` and `ash_history`
- macro: truncate_shell_history
  condition: >
    (open_write and (
      fd.name endswith "ash_history" or
      fd.name endswith "zsh_history" or
      fd.name contains "fish_read_history" or
      fd.name endswith "fish_history") and evt.arg.flags contains "O_TRUNC")

- macro: var_lib_docker_filepath
  condition: (evt.arg.name startswith /var/lib/docker or fd.name startswith /var/lib/docker)

# todo!: the usage of `evt.arg*` filter check in the output should be avoided
# when more than one event type is involved because some event will populate
# the filtercheck and others will always return <NA>. It would be better to use
# a more generic filter like `fs.path.*`
- rule: Delete or rename shell history
  desc: > 
    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.
  condition: >
    (modify_shell_history or truncate_shell_history) 
    and not var_lib_docker_filepath 
    and not proc.name in (docker_binaries)
  output: Shell history deleted or renamed (file=%fd.name name=%evt.arg.name path=%evt.arg.path oldpath=%evt.arg.oldpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority:
    WARNING
  tags: [maturity_incubating, host, container, process, filesystem, mitre_defense_evasion, T1070]

- list: user_known_chmod_applications
  items: [hyperkube, kubelet, k3s-agent]

# This macro should be overridden in user rules as needed. This is useful if a given application
# should not be ignored altogether with the user_known_chmod_applications list, but only in
# specific conditions.
- macro: user_known_set_setuid_or_setgid_bit_conditions
  condition: (never_true)

# todo!: the usage of `evt.arg*` filter check in the output should be avoided
# when more than one event type is involved because some event will populate
# the filtercheck and others will always return <NA>. In this specific
# rule, 'chmod' doesn't have a `%evt.arg.fd` argument for example so
# we will always return `<NA>`.
- rule: Set Setuid or Setgid bit
  desc: >
    This rule is focused on detecting the use of setuid or setgid bits set via chmod. These bits, when set for an application, 
    result in the application running with the privileges of the owning user or group. By enabling the setuid or setgid bits, 
    an attacker could run code in a different user's context, possibly with elevated privileges. However, there's a trade-off 
    with noise, given that numerous applications legitimately run chmod. This rule is related to the "Non sudo setuid" rule.
  condition: >
    chmod 
    and (evt.arg.mode contains "S_ISUID" or evt.arg.mode contains "S_ISGID")
    and not proc.name in (user_known_chmod_applications)
    and not exe_running_docker_save
    and not user_known_set_setuid_or_setgid_bit_conditions
  output: Setuid or setgid bit is set via chmod (fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority:
    NOTICE
  tags: [maturity_incubating, host, container, process, users, mitre_privilege_escalation, T1548.001]

- list: remote_file_copy_binaries
  items: [rsync, scp, sftp, dcp]

- macro: remote_file_copy_procs
  condition: (proc.name in (remote_file_copy_binaries))

# Users should overwrite this macro to specify conditions under which a
# Custom condition for use of remote file copy tool in container
- macro: user_known_remote_file_copy_activities
  condition: (never_true)

- rule: Launch Remote File Copy Tools in Container
  desc: > 
    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.
  condition: >
    spawned_process
    and container
    and remote_file_copy_procs
    and not user_known_remote_file_copy_activities
  output: Remote file copy tool launched in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: NOTICE
  tags: [maturity_incubating, container, network, process, mitre_exfiltration, T1020]

# Namespaces where the rule is enforce
- list: namespace_scope_network_only_subnet
  items: []

- macro: network_local_subnet
  condition: >
    (fd.rnet in (rfc_1918_addresses) or
    fd.ip = "0.0.0.0" or
    fd.net = "127.0.0.0/8")

# # The rule is disabled by default.
# # How to test:
# # Add 'default' to namespace_scope_network_only_subnet
# # Run:
# kubectl run --generator=run-pod/v1 -n default -i --tty busybox --image=busybox --rm -- wget google.com -O /var/google.html
# # Check logs running
- rule: Network Connection outside Local Subnet
  desc: > 
    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.
  condition: >
    inbound_outbound 
    and container 
    and k8s.ns.name in (namespace_scope_network_only_subnet) 
    and not network_local_subnet 
  output: Network connection outside local subnet (fd_rip_name=%fd.rip.name fd_lip_name=%fd.lip.name fd_cip_name=%fd.cip.name fd_sip_name=%fd.sip.name connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: WARNING
  tags: [maturity_incubating, container, network, mitre_discovery, T1046, PCI_DSS_6.4.2]

- macro: mount_info
  condition: (proc.args="" or proc.args intersects ("-V", "-l", "-h"))

- macro: known_gke_mount_in_privileged_containers
  condition:
    (k8s.ns.name = kube-system
    and container.image.repository = gke.gcr.io/gcp-compute-persistent-disk-csi-driver)

- macro: known_aks_mount_in_privileged_containers
  condition:
    ((k8s.ns.name = kube-system and container.image.repository in (mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi,mcr.microsoft.com/oss/kubernetes-csi/azurefile-csi))
    or (k8s.ns.name = system and container.image.repository = mcr.microsoft.com/oss/kubernetes-csi/secrets-store/driver))

- macro: user_known_mount_in_privileged_containers
  condition: (never_true)

- rule: Mount Launched in Privileged Container
  desc: > 
    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.
  condition: >
    spawned_process 
    and container
    and container.privileged=true
    and proc.name=mount
    and not mount_info
    and not known_gke_mount_in_privileged_containers
    and not known_aks_mount_in_privileged_containers
    and not user_known_mount_in_privileged_containers
  output: Mount was executed inside a privileged container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: WARNING
  tags: [maturity_incubating, container, cis, filesystem, mitre_privilege_escalation, T1611]

- list: ingress_remote_file_copy_binaries
  items: [wget]

- macro: ingress_remote_file_copy_procs
  condition: (proc.name in (ingress_remote_file_copy_binaries))

# Users should overwrite this macro to specify conditions under which a
# Custom condition for use of ingress remote file copy tool in container
- macro: user_known_ingress_remote_file_copy_activities
  condition: (never_true)

- macro: curl_download
  condition: (proc.name = curl and
              (proc.cmdline contains " -o " or
              proc.cmdline contains " --output " or
              proc.cmdline contains " -O " or
              proc.cmdline contains " --remote-name "))

- rule: Launch Ingress Remote File Copy Tools in Container
  desc: > 
    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.
  condition: >
    spawned_process 
    and container 
    and (ingress_remote_file_copy_procs or curl_download) 
    and not user_known_ingress_remote_file_copy_activities
  output: Ingress remote file copy tool launched in container (evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: NOTICE
  tags: [maturity_incubating, container, network, process, mitre_command_and_control, TA0011]

- list: docker_binaries
  items: [docker, dockerd, containerd-shim, "runc:[1:CHILD]", pause, exe, docker-compose, docker-entrypoi, docker-runc-cur, docker-current, dockerd-current]

- list: known_binaries_to_read_environment_variables_from_proc_files
  items: [scsi_id, argoexec]

- rule: Read environment variable from /proc files
  desc: > 
    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.
  condition: >
    open_read 
    and container 
    and (fd.name glob /proc/*/environ)
    and not proc.name in (known_binaries_to_read_environment_variables_from_proc_files)
  output: Environment variables were retrieved from /proc files (file=%fd.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: WARNING
  tags: [maturity_incubating, container, filesystem, process, mitre_discovery, T1083]

# The steps libcontainer performs to set up the root program for a container are:
# - clone + exec self to a program runc:[0:PARENT]
# - clone a program runc:[1:CHILD] which sets up all the namespaces
# - clone a second program runc:[2:INIT] + exec to the root program.
#   The parent of runc:[2:INIT] is runc:0:PARENT]
# As soon as 1:CHILD is created, 0:PARENT exits, so there's a race
#   where at the time 2:INIT execs the root program, 0:PARENT might have
#   already exited, or might still be around. So we handle both.
# We also let runc:[1:CHILD] count as the parent process, which can occur
# when we lose events and lose track of state.
- macro: container_entrypoint
  condition: (not proc.pname exists or proc.pname in (runc:[0:PARENT], runc:[1:CHILD], runc, docker-runc, exe, docker-runc-cur, containerd-shim, systemd, crio))

- macro: system_level_side_effect_artifacts_kubectl_cp
  condition: (fd.name startswith /etc or 
              fd.name startswith /proc or 
              fd.name startswith /lib or 
              fd.name startswith /run or 
              fd.name startswith /usr or 
              fd.name="/")

- rule: Exfiltrating Artifacts via Kubernetes Control Plane
  desc: >
    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.
  condition: >
    open_read 
    and container 
    and proc.name=tar 
    and container_entrypoint 
    and proc.tty=0 
    and not system_level_side_effect_artifacts_kubectl_cp
  output: Exfiltrating Artifacts via Kubernetes Control Plane (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty %container.info)
  priority: NOTICE
  tags: [maturity_incubating, container, filesystem, mitre_exfiltration, TA0010]

- rule: Adding ssh keys to authorized_keys
  desc: >
    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 more generic auditing rule "Read ssh information"
    by specifically detecting the writing of new, potentially attacker-provided keys.
  condition: >
    open_write
    and (user_ssh_directory or fd.name startswith /root/.ssh)
    and fd.name endswith authorized_keys
    and not proc.name in (ssh_binaries)
  output: Adding ssh keys to authorized_keys (file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty)
  priority: WARNING
  tags: [maturity_incubating, host, filesystem, mitre_persistence, T1098.004]

# possible use of CVE-2023-4911
- macro: glibc_tunables_env
  condition: (proc.env icontains GLIBC_TUNABLES)

- rule: Potential Local Privilege Escalation via Environment Variables Misuse
  desc: >
    Process run with suspect environment variable that could be attempting privilege escalation. One use case is 
    detecting the use of the GLIBC_TUNABLES environment variable, which could be used for privilege escalation 
    on systems running vulnerable glibc versions. Only known and carefully profiled processes that legitimately 
    exhibit this behavior should be excluded from this rule. This rule is expected to trigger on every attempt, 
    even failed ones.
  condition: >
    spawned_process 
    and glibc_tunables_env
  enabled: true
  output: Process run with suspect environment variable which could be attempting privilege escalation (env=%proc.env evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: NOTICE
  tags: [maturity_incubating, host, container, users, mitre_privilege_escalation, TA0004]

- rule: Backdoored library loaded into SSHD (CVE-2024-3094)
  desc: 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.
  condition: > 
    open_read and 
    proc.name=sshd and 
    (fd.name contains "liblzma.so.5.6.0" or fd.name contains "liblzma.so.5.6.1")
  output: SSHD loaded a backdoored version of liblzma library %fd.name with parent %proc.pname and cmdline %proc.cmdline (process=%proc.name parent=%proc.pname file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid proc_exepath=%proc.exepath command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: WARNING
  tags: [maturity_incubating, host, container]