new(rules): detect GPU/accelerator cryptojacking and device access (T1496)

[DevamShah]

/kind feature

/area rules

/area maturity-sandbox

What type of PR is this?

/kind feature

Any specific area of the project related to this PR?

/area rules
/area maturity-sandbox

What this PR does / why we need it

Adds three maturity_sandbox artifacts to rules/falco-sandbox_rules.yaml that detect GPU/accelerator cryptojacking — a container opening an NVIDIA/AMD compute device, and GPU management tooling (nvidia-smi, rocm-smi) running inside a container — closing a coverage gap the existing CPU/network-centric cryptominer rules do not address.

Problem / motivation

Falco's current cryptominer coverage in falco-sandbox_rules.yaml is CPU- and network-centric:

• Detect crypto miners using the Stratum protocol matches proc.cmdline for stratum+tcp / stratum+ssl.
• Detect outbound connections to common miner pool ports matches known pool domains/ports.
• Known Cryptominer Process Executed matches a fixed list of miner binary names (xmrig, ethminer, ...).

All three are trivially evaded by a GPU miner. An attacker who has compromised a GPU-equipped node (common in ML/AI and rendering fleets, where idle accelerator capacity is a high-value cryptojacking target) can use a renamed or custom miner binary, connect over an encrypted/proxied channel to an unknown pool, and avoid the stratum URI scheme entirely.

What the miner cannot avoid is opening a GPU character device to submit work to the hardware (/dev/nvidia*, /dev/nvidiactl, /dev/nvidia-uvm for CUDA; /dev/kfd and /dev/dri/renderD* for AMD ROCm). That device open is the chokepoint this PR instruments. This is GPU compute, distinct from the existing Privileged Container Device Access rule, which targets raw block/storage devices (/dev/sd, /dev/nvme, /dev/mem) for container escape (T1611) — no overlap with GPU compute devices.

Change

• list: gpu_device_files — /dev/nvidiactl, /dev/nvidia-uvm, /dev/nvidia-uvm-tools, /dev/kfd.
• macro: open_gpu_device — an open_read/open_write on a gpu_device_files entry, any /dev/nvidia* per-GPU node, or a /dev/dri/renderD* DRM render node.
• list: gpu_management_binaries — nvidia-smi, nvidia-debugdump, nvidia-persistenced, nvidia-cuda-mps-control, rocm-smi, rocminfo.
• macro: user_known_gpu_workloads (defaults to never_true) — the documented tuning hook for clusters with legitimate ML/HPC/rendering workloads, overridable by image (e.g. container.image.repository in (my_ml_images)).
• rule: Container Accessing GPU Device (priority CRITICAL, disabled by default) — behavioral signal: a container opens a GPU compute device and is not an allowlisted workload. Shipped disabled because it is noisy until user_known_gpu_workloads is tuned to the images expected to use the GPU.
• rule: GPU Management Tool Run in Container (priority CRITICAL) — signature signal: GPU fingerprinting tooling runs in a non-allowlisted container.

Conventions mirror the adjacent rules: first tag is the maturity level (maturity_sandbox); container scope, killchain phase (mitre_impact) and TTP (T1496) tags match the sibling stratum and miner-binary rules; both rules use a never_true-backed user_known_* tuning macro and the established evt_type / user / process / proc_exepath / parent / command / terminal output template. The device-open rule deliberately reuses the exact (open_read or open_write) and container and fd.name startswith /dev/... pattern already used by the existing Privileged Container Device Access rule in this same file.

Security rationale

• MITRE ATT&CK T1496 — Resource Hijacking (Impact tactic). GPU cryptojacking is the same technique as CPU cryptojacking on a far higher-value target. Tagged identically to the existing T1496 rules.
• Defense-in-depth against evasion. Pairs a behavioral detection (device open — hard to avoid) with a signature detection (management tooling — high precision), consistent with the project's preference for behavioral robustness over command-line string matching.
• Bounded false-positive surface. Both rules are container-scoped and gated by a single documented user_known_gpu_workloads tuning macro. The behavioral rule ships enabled: false per repo precedent for noisy-by-default rules.

Testing / validation

• Engine validation against the real Falco engine (the authoritative CI path):
  falco --validate rules/falco-sandbox_rules.yaml in falcosecurity/falco:0.44.1 → Ok.
• Runtime firing proof (modern eBPF, capture-on-host). Ran Falco live with the modern_ebpf driver and the rule temporarily enabled, then opened character-device nodes at the matched paths inside a separate container:
  • Container Accessing GPU Device fired CRITICAL on cat /dev/nvidia0 and head -c1 /dev/nvidiactl from a busybox container:
    Critical Container accessing GPU device | device=/dev/nvidia0 image=busybox evt_type=openat ... process=cat ... container_name=gpu-trigger2
  • GPU Management Tool Run in Container fired CRITICAL on executing nvidia-smi inside a container:
    Critical GPU management tool run in container | image=busybox evt_type=execve process=nvidia-smi ...
  • This also confirms the open_read/open_write macros (fd.typechar='f', fd.num>=0) do match successful character-device opens, exactly as the sibling block-device rule relies on.
• Diff is additive only: 1 file, +81 lines.

Special notes for your reviewer

Submitted as maturity_sandbox per the maturity framework — an experimental detection that pairs a behavioral and a signature signal. Happy to split the two rules, adjust the device/management-binary lists, or change the default-enabled state based on maintainer preference.

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: DevamShah
Once this PR has been reviewed and has the lgtm label, please assign darryk10 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• rules/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[poiana]

Welcome @DevamShah! It looks like this is your first PR to falcosecurity/rules 🎉