The Communications Fraud Control Association puts global telecom fraud near 38.95 billion USD a year, and the single largest slice of it is toll fraud: an attacker turns your phone system into a money pump and you find out on the next invoice. The PBX is the asset most security programs forget they own, yet it is just another stack of network services, SIP on 5060, RTP on a wide UDP range, and a web admin panel, each shipping with the same defaults and weak secrets you would never tolerate on a server.
This guide is built around the actual tool output you would see on an engagement, not a tool list. You will watch svwar surface a live extension, svcrack pop its password, and an RTP stream turn back into audio, then we close with the Asterisk settings that kill each finding. It pairs with our internal network penetration testing guide and the enterprise network misconfigurations breakdown, since voice almost always rides the same flat network everything else does.
Toll fraud is the reason VoIP testing pays for itself: a permissive dial plan plus one weak extension secret lets an attacker register, dial premium-rate or international revenue-share numbers around the clock, and bill it all to you. Single victims have lost six figures over a long weekend because nobody capped concurrent international channels.
The mechanics are simple and that is what makes it dangerous. An attacker who recovers an extension's SIP secret is, as far as the PBX is concerned, a legitimate phone. If the dial plan routes that extension to the outside world without restriction, every call it places is a charge. The attacker does not need an exploit or a CVE; they need an account and a route, both of which a misconfigured PBX hands over.
Beyond fraud, the high-value outcomes are eavesdropping on unencrypted calls and caller-ID spoofing that powers vishing. A spoofed From header showing your internal helpdesk number turns a generic phishing call into one your staff trust, so the SIP-layer weakness and the social-engineering risk are really one finding. NIST SP 800-58 frames the same controls from the defender's side.
Start by finding the SIP services and identifying the PBX software, because the rest of the test depends on knowing what you are talking to. nmap fingerprints the obvious ports and SIPVicious sweeps for live SIP devices. Run the UDP scan first since SIP is UDP by default.
$ nmap -sU -sV -p 5060,5061 --script sip-methods 10.0.0.0/24
Nmap scan report for pbx.corp.local (10.0.0.50)
PORT STATE SERVICE VERSION
5060/udp open sip Asterisk PBX 16.16.2 <- version + product, your fingerprint
| sip-methods:
|_ INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFYThat banner tells you it is Asterisk 16.16.2 and that REGISTER and SUBSCRIBE are accepted, so authentication and presence attacks are both on the table. Also profile the TFTP server phones provision from. Open provisioning config is a frequent jackpot: on a recent assessment of a regional hospital's PBX, we pulled a CUCM cluster's admin credentials out of a world-readable TFTP config (tftp 10.0.0.50 -c get SIPDefault.cnf) before ever touching the SIP service, which collapsed the whole engagement into one command.
Extension enumeration is SIP username enumeration: the PBX answers differently for a real extension than for one that does not exist, and svwar reads that difference. The telltale is the authentication column.
$ svwar -m INVITE -e 100-130 10.0.0.50
| Extension | Authentication |
| 101 | reqauth | <- real extension, server demands auth
| 102 | reqauth |
| 115 | reqauth |
[*] 3 extensions found, 25 returned 404 (do not exist)Every reqauth row is a live account to attack. Feed those into svcrack, which brute-forces the registration secret. A huge share of deployments set the secret equal to the extension number or a trivial default, so this lands in seconds.
$ svcrack -u 101 -d wordlist.txt 10.0.0.50
[*] Trying 101 ... [*] Trying 1234 ...
| Extension | Password |
| 101 | 101 | <- secret equals the extension number
[+] Password cracked for extension 101That cracked secret is an account on the phone system. You can prove a toll-fraud path safely with a single SIPp test call to an in-scope number (sipp -sn uac 10.0.0.50 -s 101 -au 101 -ap 101) rather than dialing a real premium line. Throttle svwar and svcrack: full-speed runs trip fail2ban or knock the PBX over, and a hung phone system during business hours is a fast way to lose the engagement.
Yes. When media is unencrypted, capturing and replaying calls is trivial, and RTP is unencrypted by default. On a flat or poorly segmented voice network, an attacker who can see the traffic, via ARP spoofing or a mirror port, captures the RTP stream and reassembles it into playable audio.
The chain is ARP-spoof into the path, capture a few minutes, then reassemble. tcpdump grabs the raw media and rtpbreak writes per-call audio files.
$ tcpdump -i eth0 -w voice.pcap udp portrange 10000-20000
$ rtpbreak -W -d ./out -f voice.pcap
[*] stream 0: 10.0.0.61:11042 -> 10.0.0.50:14310 G.711u 192 packets
[*] wrote ./out/rtp.0.0.raw <- decode to WAV and it plays back the callWireshark has a built-in RTP player as well (Telephony > RTP > RTP Streams > Play). This is one of the more visceral findings to demo, since you hand the client an audio file of an internal call. Do it responsibly: capture a single test call you place yourself, never live employee conversations, which keeps the proof in scope while still landing the point. The fix is SRTP for media and SIPS over TLS for signaling.
The deliverable is a prioritized findings table, because what a client needs is not a tool transcript but severity, evidence, and a fix they can action. The table below is the shape of a real VoIP report excerpt, and notice that none of the high-severity rows is a CVE, they are all configuration.
That is the recurring lesson of VoIP work: scanners report the patch level and stop, while the damage lives in extension secrets, dial-plan routes, and missing encryption. The report ties each finding to the evidence that proves it and the single config change that closes it, which is what turns a test into remediation.
Securing VoIP is mostly four config-level changes, not advice to use strong passwords. First, stop extension enumeration: in Asterisk set alwaysauthreject=yes (and allowguest=no) so the PBX returns an identical response for valid and invalid extensions, which blinds svwar.
; /etc/asterisk/sip.conf
[general]
alwaysauthreject=yes ; identical 401 for real and fake extensions
allowguest=no ; no anonymous calls
encryption=yes ; require SRTP for media
transport=tls ; SIPS signaling on 5061Second, lock the dial plan: block international and premium-rate prefixes by default and only allow the routes the business actually uses, so a cracked extension cannot reach a revenue-share number. Third, put voice on its own VLAN isolated from data and management, which kills the RTP eavesdropping path and ties into network segmentation. Fourth, set strong unique SIP secrets (never equal to the extension) and rate-limit registrations to slow svcrack.
Back it with a carrier-side hard cap on concurrent international channels and an off-hours spend alert, so even a missed misconfiguration cannot become a five-figure weekend bill. VoIP infrastructure drifts quietly as extensions and SIP trunks are added, so the continuous validation in agentic pentesting helps catch a newly exposed phone system before an attacker does. Retest after every dial-plan or trunk change, because that is exactly when toll-fraud exposure reappears.