Behavioral Analytics and Threat Detection

Overview

Behavioral analytics in Kubernetes security involves detecting anomalous runtime behavior that indicates an active attack or compromise. Rather than relying solely on preventive controls (which can be bypassed), behavioral analytics focuses on detecting threats as they happen by monitoring system activity for known attack patterns.

CKS Exam Relevance

The CKS exam tests your ability to:

Recognize common Kubernetes attack patterns
Use Falco rules to detect specific threat behaviors
Understand the Kubernetes attack kill chain
Identify indicators of compromise in a running cluster
Respond to security incidents with appropriate actions

Common Kubernetes Attack Kill Chain

Understanding how attackers operate in Kubernetes environments helps you build effective detection rules and recognize ongoing attacks.

Common Attack Patterns in Kubernetes

Pattern 1: Cryptocurrency Mining

Crypto mining is one of the most common attacks in Kubernetes. Attackers exploit vulnerable applications or misconfigured clusters to deploy mining software that consumes compute resources.

Indicators:

High CPU usage from unknown processes
Connections to mining pool addresses (ports 3333, 4444, 5555, 8333, 14433)
Processes named xmrig, minerd, cpuminer, stratum
Download of binaries at runtime

Detection with Falco:

yaml

- list: miner_process_names
  items:
    - xmrig
    - minerd
    - cpuminer
    - minergate
    - stratum
    - cryptonight
    - xmr-stak

- list: mining_pool_ports
  items: [3333, 4444, 5555, 8333, 14433, 14444, 45700]

- rule: Detect crypto mining process
  desc: >
    Detects execution of known cryptocurrency mining processes
    inside containers.
  condition: >
    spawned_process and
    container and
    proc.name in (miner_process_names)
  output: >
    Crypto mining process detected
    (process=%proc.name command=%proc.cmdline
    user=%user.name container=%container.name
    pod=%k8s.pod.name ns=%k8s.ns.name
    image=%container.image.repository)
  priority: CRITICAL
  tags: [crypto, mining, mitre_impact]

- rule: Detect connection to mining pool
  desc: >
    Detects outbound network connections to common
    cryptocurrency mining pool ports.
  condition: >
    evt.type=connect and
    evt.dir=< and
    container and
    fd.sport in (mining_pool_ports)
  output: >
    Connection to mining pool detected
    (process=%proc.name connection=%fd.name
    container=%container.name pod=%k8s.pod.name
    ns=%k8s.ns.name image=%container.image.repository)
  priority: CRITICAL
  tags: [crypto, mining, network, mitre_impact]

Pattern 2: Reverse Shell

A reverse shell allows an attacker to establish a remote command-and-control channel from inside a compromised container back to their server.

Indicators:

Shell process with network file descriptor as stdin/stdout
Outbound connections from shells to external IPs
Use of bash -i, nc -e, python -c "import socket...", perl -e
Unexpected child processes of web servers or application processes

Detection with Falco:

yaml

- list: reverse_shell_commands
  items:
    - "bash -i"
    - "bash -l"
    - "/dev/tcp"
    - "nc -e"
    - "ncat -e"
    - "python -c"
    - "perl -e"
    - "ruby -rsocket"
    - "socat"
    - "mkfifo"

- rule: Detect reverse shell in container
  desc: >
    Detects common reverse shell patterns inside containers.
    A reverse shell indicates active exploitation and command-and-control.
  condition: >
    spawned_process and
    container and
    (proc.cmdline contains "/dev/tcp" or
     proc.cmdline contains "bash -i" or
     (proc.name in (nc, ncat, netcat) and
      proc.cmdline contains "-e") or
     (proc.name=python and
      proc.cmdline contains "import socket") or
     (proc.name=perl and
      proc.cmdline contains "socket") or
     (proc.name=socat and
      proc.cmdline contains "exec"))
  output: >
    Reverse shell detected in container
    (process=%proc.name command=%proc.cmdline
    parent=%proc.pname user=%user.name
    container=%container.name pod=%k8s.pod.name
    ns=%k8s.ns.name image=%container.image.repository)
  priority: EMERGENCY
  tags: [reverse_shell, mitre_execution, mitre_command_and_control]

- rule: Shell with network redirect
  desc: >
    Detects a shell process where stdin/stdout is redirected
    to a network socket, indicating a reverse shell.
  condition: >
    spawned_process and
    container and
    shell_procs and
    (fd.type=ipv4 or fd.type=ipv6)
  output: >
    Shell with network redirection detected
    (process=%proc.name command=%proc.cmdline
    fd=%fd.name parent=%proc.pname
    container=%container.name pod=%k8s.pod.name
    ns=%k8s.ns.name)
  priority: EMERGENCY
  tags: [reverse_shell, mitre_execution]

Pattern 3: Lateral Movement

Lateral movement occurs when an attacker uses a compromised container to access other resources in the cluster -- other pods, services, namespaces, or the API server itself.

Indicators:

Container accessing the Kubernetes API server
Service account token reads from /var/run/secrets/kubernetes.io/serviceaccount/token
Network scanning from within containers (nmap, masscan, port scanning)
DNS lookups for other services
Access to other pods via their internal IPs

Detection with Falco:

yaml

- rule: Contact Kubernetes API from container
  desc: >
    Detects a container making direct API calls to the Kubernetes
    API server. Most applications should not need direct API access.
  condition: >
    evt.type=connect and
    evt.dir=< and
    container and
    fd.sip="10.96.0.1" and
    not (k8s.ns.name in (kube-system, monitoring))
  output: >
    Container contacting K8s API server
    (process=%proc.name command=%proc.cmdline
    connection=%fd.name container=%container.name
    pod=%k8s.pod.name ns=%k8s.ns.name
    image=%container.image.repository)
  priority: WARNING
  tags: [lateral_movement, mitre_discovery, k8s_api]

- rule: Service account token read
  desc: >
    Detects reading of the Kubernetes service account token
    from within a container. This may indicate an attacker
    attempting to authenticate to the API server.
  condition: >
    open_read and
    container and
    fd.name startswith /var/run/secrets/kubernetes.io
  output: >
    Service account token read in container
    (process=%proc.name command=%proc.cmdline
    file=%fd.name user=%user.name
    container=%container.name pod=%k8s.pod.name
    ns=%k8s.ns.name image=%container.image.repository)
  priority: WARNING
  tags: [lateral_movement, mitre_credential_access]

- rule: Network scanning tool launched
  desc: >
    Detects execution of network scanning tools inside containers.
    This is a strong indicator of lateral movement attempts.
  condition: >
    spawned_process and
    container and
    proc.name in (nmap, masscan, zmap, nping, netcat, nc, ncat)
  output: >
    Network scanning tool launched in container
    (tool=%proc.name command=%proc.cmdline
    user=%user.name container=%container.name
    pod=%k8s.pod.name ns=%k8s.ns.name
    image=%container.image.repository)
  priority: CRITICAL
  tags: [lateral_movement, scanning, mitre_discovery]

Pattern 4: Privilege Escalation

Privilege escalation in Kubernetes can happen at the container level (Linux privileges) or the cluster level (RBAC escalation).

Indicators:

Processes calling setuid/setgid
Mounting host filesystem paths
Accessing /proc/sysrq-trigger or other host kernel interfaces
Creating privileged pods
Modifying RBAC roles to grant additional permissions
Using nsenter to escape container namespaces

Detection with Falco:

yaml

- rule: Namespace breakout attempt
  desc: >
    Detects use of nsenter or unshare to escape container
    namespaces, which can lead to host-level access.
  condition: >
    spawned_process and
    container and
    proc.name in (nsenter, unshare)
  output: >
    Namespace breakout attempt detected
    (process=%proc.name command=%proc.cmdline
    user=%user.name container=%container.name
    pod=%k8s.pod.name ns=%k8s.ns.name
    image=%container.image.repository)
  priority: EMERGENCY
  tags: [privilege_escalation, container_escape, mitre_privilege_escalation]

- rule: Sensitive host mount access
  desc: >
    Detects access to sensitive host filesystem paths from
    within a container, which may indicate a container escape
    or privilege escalation attempt.
  condition: >
    open_read and
    container and
    (fd.name startswith /proc/sysrq-trigger or
     fd.name startswith /proc/kcore or
     fd.name startswith /sys/firmware or
     fd.name startswith /dev/mem)
  output: >
    Sensitive host path accessed from container
    (file=%fd.name process=%proc.name command=%proc.cmdline
    container=%container.name pod=%k8s.pod.name
    ns=%k8s.ns.name)
  priority: EMERGENCY
  tags: [privilege_escalation, host_access, mitre_privilege_escalation]

Pattern 5: Data Exfiltration

Attackers may attempt to extract sensitive data (secrets, configuration, databases) from the cluster.

Indicators:

Large outbound data transfers
DNS tunneling (unusually long DNS queries)
Use of file transfer tools (curl, wget, scp, rsync)
Access to Kubernetes Secrets
Base64 encoding of data before transfer

Detection with Falco:

yaml

- rule: File transfer tool in container
  desc: >
    Detects execution of file transfer tools inside containers.
    These tools can be used for data exfiltration.
  condition: >
    spawned_process and
    container and
    proc.name in (curl, wget, scp, sftp, rsync, ftp, nc, ncat)
  output: >
    File transfer tool launched in container
    (tool=%proc.name command=%proc.cmdline
    user=%user.name container=%container.name
    pod=%k8s.pod.name ns=%k8s.ns.name
    image=%container.image.repository)
  priority: WARNING
  tags: [data_exfiltration, mitre_exfiltration]

Behavioral Analytics with Audit Logs

Kubernetes audit logs can also be used for behavioral detection at the API level.

Suspicious API Patterns

bash

# Find excessive Secret reads (potential exfiltration)
cat audit.log | jq -s '
  [.[] | select(.objectRef.resource=="secrets" and .verb=="get")] |
  group_by(.user.username) |
  map({user: .[0].user.username, count: length}) |
  sort_by(-.count) |
  .[:10]'

# Find RBAC modifications (potential persistence)
cat audit.log | jq 'select(
  .objectRef.resource | test("roles|rolebindings|clusterroles|clusterrolebindings")
) | select(.verb | test("create|update|patch|delete"))'

# Find pod exec events (potential execution)
cat audit.log | jq 'select(
  .objectRef.subresource=="exec" and
  .verb=="create"
) | {
  user: .user.username,
  pod: .objectRef.name,
  namespace: .objectRef.namespace,
  time: .requestReceivedTimestamp
}'

# Find anonymous or unauthenticated requests
cat audit.log | jq 'select(
  .user.username=="system:anonymous" or
  .user.groups[] == "system:unauthenticated"
)'

# Find requests from unusual source IPs
cat audit.log | jq -s '
  [.[] | .sourceIPs[0]] |
  group_by(.) |
  map({ip: .[0], count: length}) |
  sort_by(-.count)'

Incident Response Basics

When a security incident is detected, follow a structured response process.

Incident Response Steps

Containment Actions

bash

# 1. Isolate the pod with a NetworkPolicy that denies all traffic
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-compromised-pod
  namespace: <namespace>
spec:
  podSelector:
    matchLabels:
      app: <compromised-app>
  policyTypes:
  - Ingress
  - Egress
  # No ingress or egress rules = deny all
EOF

# 2. Cordon the node to prevent new pods from being scheduled
kubectl cordon <node-name>

# 3. Delete the compromised pod (if containment is more important than evidence)
# WARNING: This destroys runtime evidence
kubectl delete pod <pod-name> -n <namespace>

# 4. Revoke compromised credentials
kubectl delete serviceaccount <sa-name> -n <namespace>
kubectl delete secret <token-secret> -n <namespace>

# 5. Disable the compromised service account
kubectl patch serviceaccount <sa-name> -n <namespace> \
  -p '{"automountServiceAccountToken": false}'

Evidence Collection

bash

# Collect pod logs before deletion
kubectl logs <pod-name> -n <namespace> > /tmp/evidence/pod-logs.txt
kubectl logs <pod-name> -n <namespace> --previous > /tmp/evidence/pod-logs-previous.txt

# Collect pod specification
kubectl get pod <pod-name> -n <namespace> -o yaml > /tmp/evidence/pod-spec.yaml

# Collect events
kubectl get events -n <namespace> --sort-by=.lastTimestamp > /tmp/evidence/events.txt

# Collect audit logs
cp /var/log/kubernetes/audit/audit.log /tmp/evidence/audit.log

# Collect Falco alerts
journalctl -u falco --since "1 hour ago" > /tmp/evidence/falco-alerts.txt

Critical Rule

Always collect evidence before taking destructive containment actions. Deleting a pod destroys its runtime state (memory, processes, network connections). If possible, isolate first, investigate second, delete last.

Detection Coverage Matrix

Map your detection rules to the MITRE ATT&CK framework for Kubernetes:

Attack Technique	Detection Method	Tool
Initial Access -- Exploited Application	Network anomaly, new process	Falco
Execution -- Shell in Container	Process monitoring	Falco
Execution -- Exec into Pod	Audit log (pods/exec)	Audit Logging
Persistence -- Backdoor ServiceAccount	Audit log (SA creation)	Audit Logging
Persistence -- CronJob Backdoor	Audit log (CronJob creation)	Audit Logging
Privilege Escalation -- Privileged Container	Pod admission	PSS/Gatekeeper
Privilege Escalation -- Host Mount	Pod admission + Falco	PSS + Falco
Lateral Movement -- API Server Access	Network + audit	Falco + Audit
Lateral Movement -- Network Scanning	Process monitoring	Falco
Credential Access -- Secret Read	Audit log	Audit Logging
Exfiltration -- File Transfer	Process monitoring	Falco
Impact -- Crypto Mining	Process + network	Falco

Summary

Concept	Key Point
Kill chain	Initial Access, Execution, Persistence, Privilege Escalation, Lateral Movement, Impact
Crypto mining	Detect by process name, CPU usage, mining pool connections
Reverse shells	Detect by shell network redirection, known command patterns
Lateral movement	Detect by API server access, token reads, network scanning
Privilege escalation	Detect by setuid/setgid, nsenter, host filesystem access
Data exfiltration	Detect by file transfer tools, large outbound transfers
Incident response	Detect, Triage, Contain, Investigate, Eradicate, Recover, Learn
Evidence first	Always collect evidence before destructive actions

Behavioral Analytics and Threat Detection ​

Overview ​

Common Kubernetes Attack Kill Chain ​

Common Attack Patterns in Kubernetes ​

Pattern 1: Cryptocurrency Mining ​

Pattern 2: Reverse Shell ​

Pattern 3: Lateral Movement ​

Pattern 4: Privilege Escalation ​

Pattern 5: Data Exfiltration ​

Behavioral Analytics with Audit Logs ​

Suspicious API Patterns ​

Incident Response Basics ​

Incident Response Steps ​

Containment Actions ​

Evidence Collection ​

Detection Coverage Matrix ​

Summary ​

Behavioral Analytics and Threat Detection

Overview

Common Kubernetes Attack Kill Chain

Common Attack Patterns in Kubernetes

Pattern 1: Cryptocurrency Mining

Pattern 2: Reverse Shell

Pattern 3: Lateral Movement

Pattern 4: Privilege Escalation

Pattern 5: Data Exfiltration

Behavioral Analytics with Audit Logs

Suspicious API Patterns

Incident Response Basics

Incident Response Steps

Containment Actions

Evidence Collection

Detection Coverage Matrix

Summary