X-KUB
kube-dnsspoof
Proof-of-concept that hijacks CoreDNS resolution from a compromised pod to demonstrate cluster-internal DNS spoofing and MITM.
OVERVIEW
kube-dnsspoof (danielsagi/kube-dnsspoof) is a proof-of-concept, written up alongside Aqua Security's research on DNS spoofing inside Kubernetes clusters, that shows how little privilege is needed to hijack internal name resolution: run from a pod on the same node as a cluster's CoreDNS/kube-dns pod, it stands up a proxy that forwards every DNS query to the real DNS pod except for domains listed in its own hosts file, which it answers with attacker-controlled, spoofed responses instead.
Because it needs no elevated Kubernetes RBAC and no special Linux capabilities beyond what a default pod already has, it's used less as a production tool and more as a demonstration: once an attacker has any code execution inside a cluster, they can redirect other workloads' internal service-to-service traffic toward a listener they control, purely by winning the node-local DNS race.
USE CASES
Practical use cases
- 01
Demonstrating, in a scoped engagement, that a compromised pod can hijack cluster-internal DNS for other workloads sharing its node — a MITM primitive rather than the endpoint attack itself.
- 02
Testing whether network policy actually restricts a pod's ability to reach other pods on the same node at the DNS/UDP layer.
- 03
Illustrating the impact of a code-execution finding elsewhere (an exposed kubelet, a vulnerable app) by chaining it into cluster-internal traffic interception.
- 04
Validating that a client's CNI plugin or network policy mitigates node-local DNS hijacking as its documentation claims.
QUICK START
To demonstrate the real-world impact of a code-execution foothold by chaining it into cluster-internal traffic interception, with explicit sign-off.
- Get explicit sign-off: this is an active MITM technique against cluster-internal traffic and must be scoped to a specific node/namespace and time window.
- Deploy the included pod manifests (`kubectl create -f pods/`) to place an attacker-controlled pod on the target node.
- Exec into that pod, edit the hosts file with the domains to spoof, and run the exploit script.
- Confirm impact by observing whether another workload on the node resolves the spoofed domain to the attacker-controlled address, then tear down the pods immediately after.
kubectl exec -it hacker -- ./exploit.py --forward-timeout 5BEFORE YOU RUN IT
What to check before running it
It's an unmaintained proof-of-concept (no license file, no releases) rather than a supported tool — read exploit.py before running it, and expect to adapt it to the CNI/CoreDNS version in the target cluster.
The technique only works against workloads sharing the same node as the pod running it, and it becomes unreliable if CoreDNS is scaled to multiple replicas since only one is being spoofed — plan the demonstration around the actual DNS topology.
Spoofing DNS for other workloads on a shared node is highly disruptive and easily mistaken for a real incident — coordinate the exact timing with the client's monitoring team before running it.