Attack Chain

1. An attacker gains initial access to a Kubernetes cluster, potentially through compromised credentials or a vulnerable application.
2. The attacker identifies a target container within the Kubernetes environment.
3. The attacker executes a command to spawn a shell (e.g., bash, sh) within the targeted container. This could be achieved through tools like kubectl exec.
4. Falco detects the shell spawning event by monitoring system calls within the container runtime.
5. The detection rule triggers based on the "A shell was spawned in a container" Falco event.
6. The attacker uses the spawned shell to execute further commands, potentially escalating privileges within the container.
7. The attacker may use the compromised container to access other resources within the Kubernetes cluster or the wider network.
8. The attacker achieves their objective, such as data exfiltration, service disruption, or lateral movement.

Impact

Compromising a Kubernetes container by spawning a shell can lead to significant damage. The attacker can execute arbitrary commands, leading to data breaches, service disruptions, and unauthorized access to sensitive information. This activity can severely impact the Kubernetes infrastructure's integrity and security. The rule triggers on any instance where a shell is spawned, regardless of intent; therefore, analysts need to assess the surrounding context.

Recommendation

• Enable Kubernetes audit logging and configure Falco to monitor system calls within containers to detect shell spawning events as described in the documentation (https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
• Deploy the provided Sigma rule to your SIEM to detect suspicious shell spawning activities within Kubernetes containers, tuning the rule for your specific environment.
• Investigate any alerts generated by the Sigma rule, focusing on the user and container involved to determine if the activity is legitimate.
• Review and restrict the use of kubectl exec and similar commands to authorized personnel only.
• Implement network policies to limit communication between containers, reducing the potential impact of a compromised container.