Hacking voice over IP communications

Corporate voice network, also known as Voice over IP (VoIP) network, turns out to be an interesting target for those looking for confidential and private information. In my experience though, this target is often underestimated both by intruders or ethical hackers during their engagement, but also by company security officers.

In this article, I will go through a very practical case, using some well known tools to demonstrate the potential lack of security on VoIP networks. I’ll explain, step by step, how I’ve been using these tools, sometimes not exactly how they’re supposed to be used but that’s just how I managed to make it work altogether.

This example focuses on a specific VoIP technical environment and setup, and serves the only purpose of raising awareness on how easy it is to hack VoIP communications.

Technical environment and background

The environment used in this example is a big corporate VoIP network, using Cisco technology:

  • Switches
  • Telephones (7940 and 7941 models)
  • Call Managers

In this environment, every single switch port distributes both the VoIP network and the standard data network (the one laptops or desktops are connected to).

On the switch side, it means each switch port is configured as an « access port » with a data VLAN, but it also has a  specific and dedicated voice VLAN defined on the same port (hence acting as a 2-VLAN trunk, even it not configured as a proper trunk port).

On the terminal side, the phone and the computer are connected in a daisy chain layout. The telephone is connected to the network switch while the computer is connected to the telephone, as shown below (ex: Cisco 7940 model):

A typical Cisco swith port sample configuration is :

interface range Fast(Giga)Ethernet0/1-24
  switchport access vlan XXX
  switchport host
  switchport voice vlan YYY

It’s important to understand how the switch decides which packets belong to which VLAN: voice or data. To achieve this, there are several mechanisms and protocols depending on vendors and setup (CDP, LLDP, 802.1q) but the typical one used in Cisco environment is CDP. Keep this in mind as this is the key word to hop into the voice VLAN.

The first thing to notice is that the switch advertises the voice VLAN ID by sending a specific CDP packet, once every 30 seconds by default, on each port configured with a voice VLAN. So this is no secret information, the switch is very verbose about it, and a mere network sniffer connected on the port, through the wall network socket, will tell you straight away whether or not there’s a voice VLAN configured on that port and if so, what is the VLAN ID. An example network capture of such packet:

The second thing is: in order for a telephone or any other terminal (typically an attacker’s computer) to end up in the voice VLAN, it has to send a sequence of specific CDP packets, such that the switch is being instructed that this terminal requires to be connected to the voice VLAN. Once done, all subsequent packets from this terminal, of any type (typically DHCP request and further IP packets), are automatically tagged with the voice VLAN ID.

One last note on the network communication flow structure at stake in a phone call. There are mainly two protocols in the VoIP world: SIP and RTP:

  • SIP is used esssentially for signaling, call routing and establishment. The TCP connection is established between the phones and the call manager.
  • RTP is used as the actual multimedia (voice, video) transport, over UDP. It’s a point-to-point communication between the phones. This is where the voice packets are.

VoIP network hacking principle

Armed with the previous knowledge, the principle for intercepting VoIP communications is pretty easy to understand:

  1. Find a network port advertising a voice VLAN. This step is essentially about getting physical access to a network socket, plug in a sniffer, and listen for specific CDP packets indicating the presence of a voice VLAN.
  2. Get a terminal, typically the attacker’s computer, to hop into the voice VLAN by forging the proper sequence of CDP packets.
  3. Scan the voice VLAN IP range to find other phones. It is common to have voice VLANs with as much as 500, and even up to 1000, phones connected to it. In this step, it comes in handy to have a mapping between the phone numbers (aka ‘extension’) and the corresponding phone IP, to ease target selection.
  4. Select the target based on previous discovery and using, for instance, a corporate phone directory indicating the targets of interest (eg: CEO, HR, etc.). It is also possible to target all phones on the network, but it’s less stealthy and more risky.
  5. Perform a man-in-the-middle attack by using ARP spoofing technics against the target.
  6. Sniff and record the network traffic.
  7. Extract the voice records from the captured traffic.
  8. Re-ARP the target.

Tools installation

There are a few tools available that can perform all or part of the steps described in the previous chapter.

In this case study, I’ve been using:

  1. KALI: the v2.0 linux platform specialized in penetration testing
  2. voiphopper: a command line tool available in the KALI distribution
  3. Nmap: a command line network scanner available in the KALI distribution
  4. UCSniff: a tool providing both a command line and a graphical interface

STEP 1 – Install KALI

The easiest way is to download a VirtualBox image of Kali from the Kali website and run it within VirtualBox (free hypervisor from Oracle available for almost all OS’s). Because UCSniff is only available on 32 bits platform, pay attention to download the 32 bits image of KALI.

Pay also attention, when configuring the network adapter for your KALI virtual machine, to set it to bridge mode.

STEP 2 – Install voiphopper and Nmap

Nothing to do, as I said, these tools are included with KALI.

STEP 3 – Install UCSniff

This is the step I had more difficulties with. I first tried to compile UCSniff from source to be sure to get the latest version, but it failed miserably on a fresh KALI install. I tried to fix some of the dependencies failure, but I eventually gave up and turned back to the debian package proposed on the UCSniff site:


Even though this package is a little bit outdated it works just fine, and once downloaded it is as easy to install as issuing the following command in KALI:

root@kali# wget http://vorboss.dl.sourceforge.net/project/ucsniff/ucsniff/ucsniff%203.0%20Debian%20Packages/ucsniff_3.07-1_i386.deb
root@kali# dpkg -i ucsniff_3.07-1_i386.deb

One slight adjustment though: this package relies on an old version of OpenSSL (0.9.8) which is not present anymore in KALI v2.0. So it is required to download it from here :


and then install it :

root@kali# wget http://snapshot.debian.org/archive/debian/20110406T213352Z/pool/main/o/openssl098/libssl0.9.8_0.9.8o-7_i386.deb
root@kali# dpkg -i libssl0.9.8_0.9.8o-7_i386.deb

Using the tools to sniff voice communications

It is now time to use all these tools to sniff and capture some voice over IP communication !

Prerequisite: From now on, I’ll assume the KALI machine is connected on a network port/socket that has a voice VLAN configured. The very first step will confirm this anyway.

Side note: UCSniff is supposed to be able to handle the vlan hopping mechanism, either via CDP sniff, CDP spoof, or by manually specifying the voice VLAN ID, but for whatever reason, I did not manage to make it work for this preliminary part. That’s the reason why we’ll be using voiphopper for this, and UCSniff for the rest of the attack.

STEP 1 – Discover the voice VLAN and hop into it

Let’s launch voiphopper on the eth0 interface (change it to match your own interface) with a set of options to fake a Cisco model 7940 phone (check voiphopper manual for detailed explanations). It will automatically:

  1. discover the voice VLAN ID (in this example: 323)
  2. hop into this VLAN by creating a subinterface tagged with the VLAN ID: eth0.323
  3. perform a DHCP request so that we end up with a ready to use IP interface within the voice VLAN
  4. send proper CDP packets on a regular basis to continuously fake the presence of a Cisco phone

If everything went right, we end up with a new subinterface named eth0.323, with an IP address and network mask:

STEP 2 – Scan the voice VLAN for targets

What we now have is an IP address within the voice VLAN and a corresponding network mask. So this gives us all we need to perform a network scan with Nmap. However, in order to select a meaningful target, the IP addresses of other phones on the network will not be enough. What would be ideal is to get the corresponding phone number (ie: phone extension) because that’s how we would be able to map it to a real person, through the use of phone directory (public or internal).

I created a specific Nmap script for this purpose, called cisco-voip-phone-number (beware: it’s only been tested on Cisco 7940 and 7941 phone models, but it can be easily extended to other models). You can download it from my Github repository. What we want to do is run Nmap with this script on port 80 of all devices in the voice VLAN, using the voice VLAN network IP and corresponding network mask. Below is a sample output of this script on a specific phone within the voice VLAN:

Next to the « cisco-voip-phone-number » output, you get the correspondig phone extension. So once we’ve run this script on the whole voice network, we should end up with a list of phone IPs and corresponding phone number/extension. It’s time to pick up the target !

STEP 3 – Attack the target and capture voice calls

Once the target is selected, let’s create a targets.txt file (the file name is important as it will be used by UCSniff) with the following fields:



  • target_ip : set the targeted phone IP address, you have it from the previous Nmap scan
  • target_phone_extension : set the targeted phone extension, you have it from the previous Nmap scan
  • target_name : arbitrary name you give to your target. Eg: « CEO »
  • sip : the VoIP protocol used in this example environment

Once the targets.txt file is created, from the same directory, launch UCSniff in graphical mode :

root@kali# ucsniff -G

The UCSniff graphical interface opens. Set the following options in this order :

  1. Select Interface : Select the subinterface created by voiphopper in step one, ex: eth0.323
  2. Select Mode : Set it to « MitM »
  3. MitM Mode : Set it to « Target » –> a popup window appears, select the only target available (should be the one previously created in the targets.txt file) and then close the popup window
  4. Miscellaneous Options : Select both « Enable arp request poisonning » and « Bypass of GARP Disablement » (required for Cisco phones that might be configured to ignore gratuitous ARP packets)
  5. VLAN Hop? : Leave it to « No »
  6. ACE? : Leave it to « No »

Then click on the « Start UCSniff » button and watch the magic happening…

In the above screenshot, once UCSniff is ready after having properly ARP-Poisonning the target, it automatically captures any phone call to/from the target, creates the corresponding pcap files and, even better, it extracts the wav files corresponding to each captured voice call.

Once we’re done with UCSniff, click the « Stop UCSniff » button in order to re-ARP the targets, this is an important step to remain stealthy and to not leave the target in a DoS situation.


Raising the concern of attacks on VoIP network might not always be an easy task, the world of VoIP being often misunderstood or underestimated in terms of ease of attack as well as potential information that can be captured.

This practical demonstration will hopefully help raising awareness. What about telling your CEO or CISO how easy it is to listen to all their phone calls  🙂 ?

Like this article ? Tip me with some bitcoins !

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s