2026-10-05·[securitydetectionvoipsippbxessential-eightincident-response]
Header illustration for "The phone system is a network door too: detecting SIP/VoIP attacks on your PBX"

"The phone system is a network door too: detecting SIP/VoIP attacks on your PBX"

The phone system is a network door too: detecting SIP/VoIP attacks on your PBX

Most organisations secure their email and their VPN and then leave the phone system alone, a box in the comms room, running Asterisk or FreePBX or a vendor's IP-PBX, quietly listening on ports 5060 and 5061. It shouldn't be surprising that attackers find it first. A recent Hackers Arise walkthrough of testing office phones with SIPVicious shows how quickly a SIP endpoint can be fingerprinted, its extensions enumerated and its passwords guessed with free tooling, and the same playbook, run by someone with no authorisation, is how toll fraud and PBX-facilitated intrusions happen. This post flips it around: how the attack works conceptually, what it looks like in your logs, and how to stop it, with Australian context at the end.

Why phone systems get owned

SIP, the protocol that sets up most VoIP calls, was designed in 1999 for a friendlier internet. Authentication is digest-based (a challenge-response over the registration), the default transport is UDP on port 5060, and large numbers of deployments still expose their PBX admin web interface to the internet so staff can "manage it from anywhere". Two consequences follow:

And a compromised PBX is not just a phone problem. In 2025, Sangoma shipped emergency fixes for actively exploited FreePBX zero-days, CVE-2025-57819 and related flaws (CVSS 9.3) that gave unauthenticated remote code execution and admin takeover when the admin panel was internet-exposed. The SIP-credential attack is the low-effort cousin of that: no zero-day required, just patience.

The attack, step by step

The SIPVicious toolkit breaks the attack into exactly the stages a defender should map detection onto:

1. Fingerprinting (svmap). The attacker sprays OPTIONS or REGISTER requests across an IP range and reads the User-Agent and Server headers from responses: Asterisk PBX 16.2.1, FreePBX 15.0.37, Grandstream UCM. This maps which targets exist and what software runs, enough in many cases to match a public CVE.

2. Extension enumeration (svwar). The attacker sends REGISTER or INVITE probes for extension ranges (1000–1010, then wider) and reads the response codes. Historically, a 401 Unauthorized for one number and 404 Not Found for another confirmed which extensions are real. Modern PBXs return the same code for everything, but the walkthrough shows the technique still works against plenty of real deployments, and --force mode keeps probing even when the server tries to be uniform.

3. Password cracking (svcrack). With a list of valid extensions, the attacker registers with guessed passwords: a wordlist, the numeric default range 100–999, or --enabledefaults, which includes the extension number itself as the password. SIP digest auth doesn't need the server to leak anything, the attacker simply computes the response hash for each candidate password and tries the registration. A successful 200 OK means they own that extension.

4. Cash-out or pivot. From here the goals are usually one of:

5. Persistence. Less careful attackers leave credentials in a managed extension. Better ones create their own extension or trunks, or modify dialplan, so a password reset on the CFO's account doesn't evict them.

Indicators of compromise

Look for these in Asterisk logs (/var/log/asterisk/full), the FreePBX admin UI, and your flow data:

Detection rules you can deploy this week

You don't need a SIEM to start. fail2ban ships an Asterisk filter, and a basic Sipewolf-style regex catches the enumeration stage:

# fail2ban filter (asterisk.conf, abridged)
NOTICE.* .*: Registration from '.*' failed for '<HOST>' .*Wrong password
NOTICE.* .*: Failed to authenticate user .*<HOST>.*
NOTICE.* <HOST>.*: Registration from '.*' failed.*No matching peer found

Ban aggressive: findtime = 300, maxretry = 3, and ban the address at the firewall, not just in Asterisk, every cracked-guess attempt still costs the server a digest computation.

At the network layer, a Suricata/Snort rule for out-of-place SIP registration looks like:

alert sip any any -> $HOME_NET 5060 (msg:"SIP registration from non-trusted source"; \
  sid:1000001; rev:1;)

trivially noisy, so pair it with a home-net exclusion list of your actual SIP provider signalling IPs. The high-value rule is egress: alert on any new external SIP peer, and on international call volume per extension exceeding a threshold you set from your own CDR baseline.

If your PBX is FreePBX, enable its Intrusion Detection module and review the Audit Logs (Admin → Audit Logs) weekly, the 2025 exploitation wave showed that admin-panel access is the higher-value target than SIP itself.

Mitigation that actually works

  1. Don't expose what nobody needs. SIP and the admin panel belong behind VPN or an allow-listed provider range. If the admin panel must be internet-reachable for a vendor, restrict it by source IP and MFA. After the FreePBX zero-days, internet-exposed admin panels are the single biggest risk multiplier.
  2. Kill default and weak passwords. Long random passwords per extension (a password manager generates them), no password equal to the extension number, and disable extensions that aren't in use.
  3. Fail closed on authentication. In Asterisk, set alwaysauthreject=yes so enumeration gets uniform responses; consider deny/permit ACLs per peer.
  4. Limit what a stolen credential can do. Restrict outbound dialling patterns per extension, block or PIN-protect international and premium-rate destinations, and disable direct-inward-system-access unless a use case demands it.
  5. Patch the PBX like it's a server. Subscribe to Sangoma/Asterisk security announcements; the 2025 emergency releases are the recent proof.
  6. Encrypt where you can. TLS for SIP signalling and SRTP for media at least prevents passive call interception on-path.
  7. Monitor fraud signals upstream. Ask your carrier about call-fraud alerts; most Australian providers can flag international volume spikes, but only if you ask.

The Australian angle

The phone system earned its place on the network in 1999 and has kept its security model since. Five minutes with a packet sniffer on your PBX's port 5060 will tell you whether anyone has been knocking. Do that today.

← All posts