From d53e0b507d100e925a53c11945d6dc9283b60370 Mon Sep 17 00:00:00 2001 From: Devam Shah Date: Tue, 23 Jun 2026 09:17:11 +0530 Subject: [PATCH 1/2] new(rules): detect GPU/accelerator cryptojacking and device access (T1496) Add three maturity_sandbox artifacts to falco-sandbox_rules.yaml that detect GPU/accelerator cryptojacking, closing a gap the existing CPU/network-centric cryptominer rules do not cover: - list gpu_device_files + macro open_gpu_device + rule "Container Accessing GPU Device" (disabled by default): flags a container opening an NVIDIA/AMD compute device (/dev/nvidia*, /dev/nvidiactl, /dev/nvidia-uvm, /dev/kfd, /dev/dri/renderD*). The device open is the chokepoint a GPU miner cannot avoid even when it renames its binary and hides its pool traffic. - list gpu_management_binaries + rule "GPU Management Tool Run in Container": flags nvidia-smi/rocm-smi and friends running in a non-allowlisted container, a common pre-mining reconnaissance step. - macro user_known_gpu_workloads (never_true) as the documented tuning hook. Conventions mirror the sibling T1496 rules and the existing "Privileged Container Device Access" rule, which uses the same (open_read or open_write) + fd.name device-prefix pattern. Priority CRITICAL to match sibling T1496 rules; output uses the established bare key=%val template. Signed-off-by: Devam Shah --- rules/falco-sandbox_rules.yaml | 81 ++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) diff --git a/rules/falco-sandbox_rules.yaml b/rules/falco-sandbox_rules.yaml index e9a24536..e7455354 100644 --- a/rules/falco-sandbox_rules.yaml +++ b/rules/falco-sandbox_rules.yaml @@ -1972,3 +1972,84 @@ output: Container accessing host filesystem paths | 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_sandbox, container, filesystem, mitre_privilege_escalation, T1611] + +############################################################################# +# GPU / accelerator cryptojacking and unauthorized device access +# +# The existing cryptominer rules (Stratum protocol, known miner pool ports, +# known miner process names) are CPU- and network-centric. They miss GPU +# cryptojacking entirely: an attacker mining on a GPU need not use a renamed +# known miner binary nor connect to a known pool domain, but it must open a +# GPU character device to submit work. These rules add a complementary +# device-access signal scoped to containers, where direct accelerator access +# from an unexpected workload is anomalous. T1496 (Resource Hijacking). +############################################################################# + +# GPU and accelerator character devices. Opening one of these is required to +# submit compute work to NVIDIA (CUDA) or AMD (ROCm) hardware. +# /dev/nvidiactl, /dev/nvidia-uvm, /dev/nvidia-uvm-tools: NVIDIA control and +# Unified Virtual Memory devices. +# /dev/nvidia0../dev/nvidiaN: per-GPU NVIDIA devices (matched by prefix). +# /dev/kfd: AMD ROCm Kernel Fusion Driver compute device. +# /dev/dri/renderD*: DRM render nodes used by ROCm/OpenCL for compute. +- list: gpu_device_files + items: [/dev/nvidiactl, /dev/nvidia-uvm, /dev/nvidia-uvm-tools, /dev/kfd] + +- macro: open_gpu_device + condition: > + (open_read or open_write) + and (fd.name in (gpu_device_files) or + fd.name startswith /dev/nvidia or + fd.name startswith /dev/dri/renderD) + +# Userspace tooling that queries or manages NVIDIA/AMD GPUs. Legitimate when run +# by an ML/HPC workload; suspicious when spawned inside a workload that has no +# business touching the accelerator (e.g. a web frontend or a sidecar). +- list: gpu_management_binaries + items: [nvidia-smi, nvidia-debugdump, nvidia-persistenced, nvidia-cuda-mps-control, rocm-smi, rocminfo] + +# Tuning hook for environments where specific images legitimately use the GPU. +# Override with the set of container images (or other criteria) that are +# expected to access accelerators, e.g.: +# - macro: user_known_gpu_workloads +# condition: (container.image.repository in (my_ml_images)) +- macro: user_known_gpu_workloads + condition: (never_true) + +# Disabled by default: in clusters with legitimate ML, HPC, or rendering +# workloads this rule is noisy until user_known_gpu_workloads is tuned to the +# set of images expected to access the GPU. Enable after tuning. +- rule: Container Accessing GPU Device + desc: > + Detects a container process opening an NVIDIA or AMD GPU or accelerator character device. + Opening such a device is required to submit compute work to the hardware, making this a + high-signal indicator of GPU cryptojacking when it originates from a workload that is not + expected to use accelerators. It complements the network- and process-name-centric + cryptominer rules, which a GPU miner can evade by using an unknown binary name and an + unknown mining pool. Because a miner cannot submit work to a GPU without opening the device, + this device open is a reliable behavioral chokepoint for the Resource Hijacking technique. + condition: > + open_gpu_device + and container + and not user_known_gpu_workloads + enabled: false + output: Container accessing GPU device | device=%fd.name image=%container.image.repository 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: CRITICAL + tags: [maturity_sandbox, container, filesystem, mitre_impact, T1496] + +- rule: GPU Management Tool Run in Container + desc: > + Detects execution of an NVIDIA or AMD GPU management or query tool, such as nvidia-smi or + rocm-smi, inside a container. Attackers commonly run these tools immediately after gaining + access to a GPU-equipped node to fingerprint the available accelerators before deploying a + miner. Inside a workload container this is rarely legitimate outside of machine learning and + HPC images. It is a signature-style detection that pairs with the device-access rule to + provide both a behavioral and a signature view of the same accelerator-hijacking technique. + condition: > + spawned_process + and container + and proc.name in (gpu_management_binaries) + and not user_known_gpu_workloads + output: GPU management tool run in container | image=%container.image.repository 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: CRITICAL + tags: [maturity_sandbox, container, process, mitre_impact, T1496] From fa9be60ab00f30fea1ae42a6685b47b6b025f5da Mon Sep 17 00:00:00 2001 From: devamshah Date: Fri, 28 Aug 2026 09:19:26 +0530 Subject: [PATCH 2/2] update(sandbox): address review feedback on GPU cryptojacking rules - gpu_management_binaries: truncate entries to their kernel comm form. proc.name is task->comm (char[16], 15 usable chars), so nvidia-debugdump (16), nvidia-persistenced (19) and nvidia-cuda-mps-control (23) could never match and silently made half the list dead. Now nvidia-debugdum, nvidia-persiste and nvidia-cuda-mps, matching the existing nvidia-installe / unicorn_launche convention in falco_rules.yaml. Added a comment so the names are not "corrected" back. - Both rules: drop image=%container.image.repository from the output. No rule in the tree carries container identity fields; the style guide asks to keep upstream outputs minimal and leave ID-style fields to the customization phase. Operators still get container metadata via append_output or -pc. The sibling "Privileged Container Device Access" rule this one mirrors uses device=%fd.name evt_type=... with no image. - GPU Management Tool Run in Container: ship enabled: false. It gates on the same never_true user_known_gpu_workloads macro as the device-access rule, so the "noisy until the macro is tuned" reasoning applies equally. The previous asymmetry was not justified. Signed-off-by: Devam Shah Signed-off-by: devamshah --- rules/falco-sandbox_rules.yaml | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/rules/falco-sandbox_rules.yaml b/rules/falco-sandbox_rules.yaml index e7455354..a01cf99e 100644 --- a/rules/falco-sandbox_rules.yaml +++ b/rules/falco-sandbox_rules.yaml @@ -2005,8 +2005,14 @@ # Userspace tooling that queries or manages NVIDIA/AMD GPUs. Legitimate when run # by an ML/HPC workload; suspicious when spawned inside a workload that has no # business touching the accelerator (e.g. a web frontend or a sidecar). +# +# Names are the kernel comm form (task->comm is char[16]: 15 chars plus NUL), as +# matched by proc.name. Do not "correct" these to their full binary names or they +# will never match: nvidia-debugdum(p), nvidia-persiste(nced), +# nvidia-cuda-mps(-control). Same convention as nvidia-installe and +# unicorn_launche in falco_rules.yaml. - list: gpu_management_binaries - items: [nvidia-smi, nvidia-debugdump, nvidia-persistenced, nvidia-cuda-mps-control, rocm-smi, rocminfo] + items: [nvidia-smi, nvidia-debugdum, nvidia-persiste, nvidia-cuda-mps, rocm-smi, rocminfo] # Tuning hook for environments where specific images legitimately use the GPU. # Override with the set of container images (or other criteria) that are @@ -2033,10 +2039,15 @@ and container and not user_known_gpu_workloads enabled: false - output: Container accessing GPU device | device=%fd.name image=%container.image.repository 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 + output: Container accessing GPU device | device=%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: CRITICAL tags: [maturity_sandbox, container, filesystem, mitre_impact, T1496] +# Disabled by default for the same reason as the rule above: it is gated on the +# same untuned user_known_gpu_workloads macro, so until an operator declares +# which images are expected to touch the accelerator this rule cannot tell a +# routine nvidia-smi in an ML image from an attacker fingerprinting the GPU. +# Enable after tuning. - rule: GPU Management Tool Run in Container desc: > Detects execution of an NVIDIA or AMD GPU management or query tool, such as nvidia-smi or @@ -2050,6 +2061,7 @@ and container and proc.name in (gpu_management_binaries) and not user_known_gpu_workloads - output: GPU management tool run in container | image=%container.image.repository 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 + enabled: false + output: GPU management tool run 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 priority: CRITICAL tags: [maturity_sandbox, container, process, mitre_impact, T1496]