VoIP network segmentation is one of those things that looks solid on a network diagram but often falls apart in practice, and VoIPHopper is the tool I use to prove that gap during authorized network penetration tests. It automates a technique that used to require a lot of manual packet crafting: mimicking a VoIP phone well enough that a switch places your attacking machine directly onto the (supposedly isolated) voice VLAN.
What Is VoIPHopper?
VoIPHopper is a VLAN hopping tool designed specifically to test the security of VoIP networks. Its core purpose is to demonstrate that an attacker with physical or logical access to a data VLAN port can “hop” onto the voice VLAN by mimicking the behavior of a legitimate Cisco, Avaya, Nortel, or Alcatel-Lucent IP phone — and once on the voice VLAN, potentially eavesdrop on calls, access voicemail systems, or pivot toward other VoIP infrastructure.
How It Works Internally
Most enterprise VoIP deployments use Auto VLAN discovery protocols so that when you plug in an IP phone, the switch automatically assigns it to the correct voice VLAN without manual per-port configuration. VoIPHopper exploits exactly this convenience feature. Depending on the target environment, it supports multiple discovery mechanisms:
- CDP (Cisco Discovery Protocol) — VoIPHopper can sniff CDP packets from real Cisco IP phones already on the network to learn the voice VLAN ID, then craft and send its own spoofed CDP packets identifying itself as a Cisco IP phone, prompting the switch to tag the port with the voice VLAN.
- DHCP — some VoIP deployments assign VLAN info via DHCP options; VoIPHopper can parse DHCP responses for VLAN hints.
- LLDP-MED — the vendor-neutral equivalent of CDP, used for VLAN discovery on non-Cisco gear.
- 802.1Q tagging — once VoIPHopper determines the correct VLAN ID, it configures a tagged (802.1Q) sub-interface on the attacking NIC and injects traffic into that VLAN directly, bypassing the switch’s assumption that only trusted phones sit there.
In short: it listens for how a real IP phone identifies itself to the network, replicates that identification, and lets the switch do the actual VLAN-hopping work for it.
Installation
VoIPHopper is preinstalled on Kali Linux:
sudo apt update
sudo apt install voiphopper
Verify:
voiphopper -h
Basic Syntax
voiphopper -i <interface> -c <mode> [options]
Modes
| Mode | Purpose |
|---|---|
0 | Sniff mode — passively listen for CDP packets to auto-detect VLAN ID |
1 | Pre-set Cisco CDP spoof using a specific VLAN ID |
2 | Cisco discovery mode with automatic CDP crafting after sniffing |
3 | Send a generic/custom spoofed CDP packet |
Example: Sniff and Auto-Hop (Cisco Environment)
sudo voiphopper -i eth0 -c 0
This passively listens for CDP announcements from real Cisco IP phones on the segment, extracts the voice VLAN ID, then automatically configures a tagged VLAN interface and injects a spoofed CDP packet to get the switch port assigned to that VLAN.
Sample output:
VoIP Hopper 3.0
Interface: eth0
Reading packets on eth0...
Received CDP Packet from Cisco IP Phone
Discovered Voice VLAN ID: 110
Spoofing CDP packet as a Cisco 7961 IP Phone...
Configuring eth0.110 with DHCP...
Successfully hopped to Voice VLAN 110
Example: Manually Specifying a Known VLAN ID
sudo voiphopper -i eth0 -c 1 -v 110
Example: Non-Cisco Environment (LLDP-MED)
sudo voiphopper -i eth0 -c 2 -E
(The -E or equivalent flag toggles LLDP-based discovery depending on the VoIPHopper build; always check -h output for your installed version, since flag sets have shifted slightly across releases.)
Real-World Use Case (Authorized Lab Only)
In a segmented lab network with a data VLAN (100) and a supposedly isolated voice VLAN (110) carrying a Cisco IP phone, I connected my attacking laptop to a switch port configured for the data VLAN. Running VoIPHopper in sniff mode captured a live CDP announcement from a nearby IP phone, extracted VLAN 110, and successfully tagged my interface into that VLAN. From there, within the same authorized lab, I could reach the voice VLAN’s DHCP scope and observe SIP/RTP traffic with a packet capture tool — directly demonstrating that VLAN segmentation alone, without port security or 802.1X, isn’t sufficient isolation.
Workflow Integration
- Wireshark/tcpdump → capture and analyze CDP/LLDP traffic before and after the hop, and to inspect SIP/RTP traffic once on the voice VLAN.
- VoIPHopper → perform the actual VLAN hop.
- sipvicious/SIPp → once on the voice VLAN, these tools can enumerate SIP extensions or test for weak authentication on the VoIP call manager.
- Nmap → scan the voice VLAN’s subnet once access is achieved to map VoIP infrastructure (call managers, gateways, voicemail servers).
Troubleshooting & Common Mistakes
- No CDP packets captured — some switches rate-limit CDP to once every 60 seconds; give sniff mode enough time, or check whether CDP is disabled entirely (common in hardened environments, which would make this specific vector unavailable).
- Interface doesn’t get an IP on the new VLAN — confirm the voice VLAN’s DHCP scope isn’t restricted by MAC-based reservations or 802.1X, both of which would block this attack even after a successful VLAN tag.
- Requires root/sudo — VoIPHopper needs raw socket access to craft and inject packets, so always run with elevated privileges.
- Wrong interface/driver issues — some wireless or virtual interfaces don’t support 802.1Q tagging cleanly; use a wired interface for reliable results.
Best Practices
- Only test this against networks/scopes explicitly covered in your engagement’s rules of engagement — VLAN hopping can have real operational impact on live voice services.
- Document not just success/failure but the specific discovery protocol exploited (CDP vs LLDP vs DHCP), since remediation differs (e.g., disabling CDP on access ports, enabling 802.1X, implementing port security).
- Pair findings with a clear business-impact explanation — most stakeholders understand “this lets an attacker on the office network potentially listen to phone calls” better than protocol-level detail alone.
FAQ
Does VoIPHopper work against modern switches with port security enabled? Not reliably — port security (MAC address limiting/sticky MAC) and 802.1X authentication are the standard mitigations against this exact technique, and a properly hardened deployment should block it.
Is this attack still relevant in 2026? Yes, particularly in older or under-maintained enterprise networks where CDP is left enabled on access ports without corresponding port security — a surprisingly common finding in internal penetration tests.
Can VoIPHopper target Avaya or Nortel phones too? Yes — it includes discovery/spoofing support for Cisco, Avaya, Nortel, and Alcatel-Lucent phone signatures, not just Cisco CDP.
Summary
VoIPHopper turns an often-overlooked network segmentation assumption — “the voice VLAN is isolated because phones auto-discover it” — into a concrete, demonstrable finding. By mimicking legitimate VoIP phone discovery traffic, it shows exactly how an attacker on a regular data port can end up on the voice network, making it a valuable tool for internal network penetration tests focused on VoIP security.
References
- Official project page: http://voiphopper.sourceforge.net/
- Kali Linux Tools: https://www.kali.org/tools/voiphopper/
- Source repository: https://github.com/OFTC-CzH/voiphopper (community mirrors of the original SourceForge project)
