VoIP and SIP Security Guide: Toll Fraud and Encryption

An exposed SIP service is one of the few systems where a single weak password turns directly into a large bill: attackers register to a PBX or abuse a trunk and route thousands of minutes to premium or international numbers overnight. The same weaknesses let them eavesdrop on calls, spoof caller ID and knock contact centres offline. This guide covers the SIP and RTP threat model, PBX and trunk hardening, signalling and media encryption (TLS, SRTP, DTLS-SRTP), toll fraud controls, caller ID authentication with STIR/SHAKEN, and how to detect abuse. It is written for voice engineers, network and security teams running on-premises PBXs, SIP trunks or hosted voice, and for the people who receive the carrier invoice.

Key takeaways

Toll fraud is the costliest VoIP failure. Weak extension passwords, open dial plans and unrestricted international routes let attackers generate revenue-share traffic, mostly out of hours, and the customer usually pays.
Never expose SIP directly to the internet. Put a session border controller or tightly filtered proxy in front, allow trunk traffic only from the provider's addresses and keep extension registration internal or behind VPN or TLS with strong credentials.
Encrypt signalling and media together. SIP over TLS protects credentials and keys in signalling; SRTP protects the audio. One without the other leaves calls exposed.
Digest MD5 is obsolete. RFC 8760 adds SHA-256 and SHA-512/256 for SIP Digest and marks MD5 as not recommended; long random secrets matter more than the hash.
Detect by behaviour. Call detail records showing new destinations, after-hours spikes or parallel calls from one extension catch fraud faster than any signature.

The VoIP and SIP threat model

SIP (RFC 3261) sets up, modifies and tears down sessions; SDP inside SIP describes the media; RTP carries the audio, usually on a dynamic UDP port range. SIP commonly uses UDP or TCP 5060 and TLS on 5061. RFC 3261 itself lists the core threats: registration hijacking, impersonating a server, tampering with message bodies, tearing down sessions, and denial of service and amplification.

Threat	What it looks like	Primary controls	ATT&CK v20
Extension credential guessing	Floods of REGISTER or INVITE with 401/403 responses from scanners	Long random secrets, rate limiting, ban on failures, no internet-facing registration	T1110.001, T1110.003
Toll fraud and IRSF	Calls to premium or high-cost international ranges, often at night or weekends	Dial plan restrictions, destination barring, spend limits, CDR alerting	T1078 (valid accounts used)
Registration hijacking	Attacker registers a contact for a legitimate extension and receives its calls	Strong auth, TLS, alert on new contact addresses	T1557
Eavesdropping	RTP captured on the LAN, Wi-Fi or provider path and replayed as audio	SRTP, voice VLAN, 802.1X on phone ports	T1040, T1123
Signalling tampering and call teardown	Forged BYE or CANCEL, modified SDP redirecting media	SIP over TLS, SBC topology hiding and validation	T1565.002
Denial of service and TDoS	INVITE floods, call floods occupying trunk channels or contact centre queues	SBC rate limits, provider DDoS controls, call admission control	T1499.002, T1498
Caller ID spoofing and vishing	Inbound calls showing your bank's or your own CEO's number	STIR/SHAKEN verification, staff verification procedures	n/a
Reconnaissance	OPTIONS scans, User-Agent and extension enumeration	SBC hides topology and User-Agent, uniform responses for unknown users	T1046, T1595

NIST SP 800-58 (Security Considerations for Voice over IP Systems, 2005) remains the NIST reference on the design trade-offs, although its product detail is dated.

Toll fraud and how to stop it

In International Revenue Share Fraud (IRSF) the attacker, or someone paying them, receives a share of the termination revenue on a premium or high-cost number range. Oracle's communications fraud documentation describes the PBX fraud pattern: attackers break into a PBX or voicemail system and call the premium number, often out of hours, and hide the source by suppressing calling line presentation. Asterisk's own security documentation warns that a misconfigured PBX can be used by unauthorised parties and run up substantial charges.

Entry points

Weak extension secrets: numeric or extension-equals-password credentials guessed by automated SIP scanners within hours of exposure.
Open or guest contexts: anonymous or unauthenticated inbound calls landing in a dial plan context that can reach outbound trunks.
Voicemail and DISA: default voicemail PINs and Direct Inward System Access features that offer a dial tone to outside callers.
Admin web interfaces: PBX management portals exposed to the internet with default or reused passwords, where an attacker can create their own extension.
Trunk credentials: SIP trunk registration usernames and passwords stolen from a device or configuration and used from another IP.

Controls that work

Bar what the business does not use: block international, premium rate and satellite ranges by default, at both the PBX and the carrier. Allow-list countries per user group where needed.
Separate dial plan contexts: inbound calls land in a context that can reach only internal extensions and IVRs, never the outbound trunk.
Time and volume limits: restrict outbound international calling out of hours, cap concurrent calls per extension and per trunk, and ask the carrier for a spend or daily usage cap with automatic suspension.
Strong secrets per device: random secrets of 20 or more characters for SIP accounts, not matching the extension; change voicemail PINs from defaults and disable DISA unless required.
Bind trunks to sources: accept trunk traffic only from the provider's published IP ranges, and use IP authentication or TLS with certificates in addition to credentials where offered.
Agree the liability position: contracts with SIP trunk providers usually leave fraud charges with the customer. Know what fraud monitoring the provider runs and how fast it suspends.

See the Fraud Prevention Guide for Digital Businesses for the wider fraud programme.

Hardening the PBX, SBC and endpoints

Session border controller: terminate all external SIP on an SBC that normalises and validates messages, hides internal topology, rate limits per source, anchors media and enforces TLS and SRTP towards trunks and remote users.
Network separation: voice VLANs for handsets, 802.1X or MAB on phone ports, and firewall rules allowing only SIP, RTP and provisioning between voice and data segments. See the Network Segmentation Guide.
Disable SIP ALG on edge firewalls: SIP application layer gateways frequently rewrite messages incorrectly and break TLS-protected signalling; let the SBC handle NAT traversal instead.
Uniform authentication responses: configure the PBX to return the same challenge or rejection for unknown and known users (Asterisk calls this alwaysauthreject) so scanners cannot enumerate extensions.
Automated banning: feed PBX security events to a tool such as fail2ban or the SBC's own blocklist, banning sources after repeated authentication failures.
Phone provisioning: serve configuration files over HTTPS with per-device credentials or certificates, not TFTP or plain HTTP; provisioning files usually contain SIP secrets. Change handset admin passwords and keep firmware current.
Remote workers: prefer softphones and handsets that register over TLS to the SBC with SRTP, or over VPN, rather than opening registration ports to the internet.
Patch and reduce: track PBX, SBC and handset advisories, remove unused modules and channel drivers, and restrict admin portals to a management network with MFA.
Emergency calling: test that emergency calls still route and carry location after every routing, barring or SBC change; barring rules must never block them.

Encrypting signalling and media

Layer	Mechanism	What it protects	Notes
Signalling	SIP over TLS, SIPS URI (RFC 3261)	Credentials exchange, SDP, call metadata, SDES keys	SIPS requires TLS to the callee's domain; beyond that, security depends on that domain's policy
Signalling authentication	SIP Digest with SHA-256 or SHA-512/256 (RFC 8760)	Proves knowledge of the account secret	MD5 is NOT RECOMMENDED; offering it alongside allows downgrade by an on-path attacker
Media	SRTP (RFC 3711)	Audio confidentiality and integrity, SRTCP integrity	Default AES counter mode with 80-bit HMAC-SHA1 tag; NULL cipher is allowed by the standard, so check that encryption is actually negotiated
Media keying	SDES (keys in SDP, RFC 4568)	Delivers SRTP keys in signalling	Only safe when the signalling hop is TLS; keys are visible to every proxy that sees the SDP
Media keying	DTLS-SRTP (RFC 5763, RFC 5764)	Keys negotiated on the media path	Certificate fingerprint carried in SDP; used by WebRTC; needs integrity-protected signalling to bind the fingerprint
Caller identity	STIR Identity header with PASSporT (RFC 8224, RFC 8225)	Authority to use the calling number	ES256 signatures; verifier checks Date freshness (60 seconds recommended)

Choosing a keying approach

SDES with TLS: widest support among enterprise handsets, PBXs and trunks. Acceptable when every signalling hop is TLS and you trust every intermediary that sees SDP.
DTLS-SRTP: keys never travel in signalling, so intermediaries cannot read them. Mandatory for WebRTC; growing in SBCs and softphones. Choose it where clients support it, especially for browser-based contact centres.
Trunks: many carriers offer TLS and SRTP on SIP trunks on request. Where they do not, the call is protected only on your side of the SBC; document that as accepted risk.
Recording and lawful requirements: media anchored at an SBC or recorder is decrypted there, so that system becomes a high-value target; protect and log it accordingly.

See the How TLS Works Guide and the mTLS Guide for certificate design.

Caller ID authentication and STIR/SHAKEN

STIR (RFC 8224) adds an Identity header to a SIP request carrying a signed PASSporT; SHAKEN is the carrier deployment profile. RFC 8588 defines the attestation claim: A (full attestation, the provider knows the customer and their right to the number), B (partial, the provider originated the call but cannot verify the number) and C (gateway, received from a network that does not support it), plus an opaque per-call origid UUID that supports traceback.

US obligations: under 47 CFR Part 64 Subpart HH, voice service providers had to implement STIR/SHAKEN in their IP networks by 30 June 2021, with extensions for small providers and non-IP networks. Providers must file in the Robocall Mitigation Database, respond to traceback requests within 24 hours and recertify annually by 1 March. Providers using a third party to sign calls must keep attestation decisions and use their own certificate.
Enterprise impact: outbound calls from your own numbers through a provider that cannot verify you may receive B or C attestation and be labelled or blocked. Make sure numbers presented on trunks are numbers you own and that the provider has them on record.
Limits: attestation shows the originating provider vouched for the call, not that the caller is who they claim. Vishing defences still need verification procedures. See the Vishing and Smishing Guide.

Where identity fits

SIP extension secrets, trunk credentials, provisioning server credentials and SBC certificates are machine credentials. They are often stored in clear text in provisioning files and PBX configuration, shared across devices and never rotated. Give each device its own secret or certificate, store trunk and admin credentials in a secrets manager, rotate them when an integrator or employee leaves, and include them in non-human identity inventories. Contact centre platforms add API keys and OAuth integrations to CRM systems that deserve the same treatment. See the Secrets Management Guide.

Implementation roadmap

Week 1, stop the bleeding: confirm no SIP, PBX admin or provisioning service is reachable from the internet except through the SBC; bar premium and unused international destinations at the carrier; set a carrier spend cap.
Weeks 2 to 4, credentials: audit every SIP account and voicemail PIN, regenerate weak or default secrets, disable unused extensions, enable failure-based banning and uniform rejection responses.
Month 2, dial plan: separate inbound and outbound contexts, add time and concurrency limits, and test with a pilot group before applying estate-wide. Keep the previous dial plan exported for rollback.
Month 3, encryption: enable TLS and SRTP on a pilot site and one trunk, check call quality, transfer, hold, conferencing and recording, then expand by site. Roll back per site by reverting the transport profile.
Ongoing, detection: stream CDRs and PBX or SBC security logs to the SIEM with the alerts below, and review destination barring quarterly.

Decision guidance

Hosted or UCaaS voice: the provider runs the SBC and PBX. Your controls are account security with MFA for the admin portal, calling permission policies, international barring and reviewing call logs. Ask the provider how it detects and caps fraud.
On-premises PBX with SIP trunks: you own every control in this guide. An SBC is worth the cost even for small sites; for a very small office, a firewall restricting SIP to the provider's IPs and no remote registration is the minimum.
Contact centres: add TDoS planning with the carrier, queue overflow routing and separate admin roles; see the Unified Communications Security Guide for collaboration platforms.
Large or multi-country estates: central dial plan policy, per-country allow-lists, central CDR analytics and certificate-based trunk authentication.

Detection and measurement

Authentication failures: REGISTER or INVITE failures by source IP and by extension; spikes indicate scanning or guessing.
Call pattern anomalies: Oracle's fraud guidance uses per-subscriber time-of-day profiles, destination allow and block lists, and destination traffic spikes against historical averages. In practice: first calls to a new country, after-hours international calls, many parallel calls from one extension and short repeated calls to the same range.
New registration contacts: an extension registering from a new IP or country, or two simultaneous contacts.
Configuration changes: new extensions, trunks, routes or admin users created outside change control.
Media without encryption: calls negotiated with plain RTP on paths where SRTP is required.

Metrics:

Fraudulent call minutes or cost per month, and time from first fraudulent call to block.
Percentage of SIP accounts with secrets meeting the length standard and rotated in the last 12 months.
Percentage of calls with TLS signalling and SRTP media, internal and on trunks.
Number of internet-reachable SIP, PBX admin or provisioning services not behind the SBC (target zero).
Authentication failures blocked per week, as a trend.

Common failure patterns

PBX left on the internet after a migration or proof of concept: found by scanners within hours, then used for out-of-hours international calls discovered on the next invoice.
Extension number as password: or a short numeric secret set at installation for convenience and never changed.
Inbound calls able to reach outbound routes: a dial plan include or transfer feature that lets an outside caller get a dial tone.
SRTP without TLS: SDES keys travel in clear text SDP, so anyone capturing the signalling can decrypt the media.
Provisioning over TFTP: handset configuration files containing SIP secrets served to anyone on the voice VLAN who can guess the MAC-based file name.
Trusting the displayed number: help desks and finance teams acting on calls that appear to come from internal or known numbers. The ShinyHunters Salesforce campaign shows how phone-based pretexting led staff to authorise malicious connected apps.

Framework mapping

Framework	Reference	Application to voice
NIST CSF 2.0	PR.DS-02, PR.IR-01, PR.PS-01, DE.CM-01	Encrypt signalling and media, restrict access to voice systems, harden configuration, monitor calls and signalling
NIST SP 800-53 Rev. 5	SC-8, SC-23, SC-7, CM-7, IA-5, SI-4, SC-13	Transmission protection, session authenticity, SBC boundary, least functionality, secret management, monitoring, cryptography (the former VoIP control SC-19 is withdrawn in Rev. 5)
CIS Controls v8.1	Control 4, Control 12, Control 13	Secure configuration of PBX and handsets, network infrastructure, network monitoring
ISO/IEC 27001:2022 Annex A	A.8.20, A.8.21, A.8.24, A.8.16	Network security, security of network services (carrier contracts), cryptography, monitoring
MITRE ATT&CK v20	T1110.001, T1110.003, T1078, T1040, T1123, T1557, T1499.002	Guessing and spraying, valid account abuse, sniffing, audio capture, on-path attacks, service exhaustion
US regulation	47 CFR Part 64 Subpart HH	STIR/SHAKEN and Robocall Mitigation Database for voice service providers

Practitioner checklist

Confirm all external SIP terminates on an SBC and trunks accept traffic only from provider IP ranges.
Bar premium, satellite and unused international destinations at the PBX and the carrier, and set a carrier spend cap.
Regenerate every SIP secret to a long random value, change default voicemail PINs and disable DISA.
Separate inbound and outbound dial plan contexts and add out-of-hours and concurrency limits.
Enable SIP over TLS and SRTP internally and on trunks where offered; prefer DTLS-SRTP where clients support it.
Offer SHA-256 Digest where supported and remove MD5 once all clients cope.
Provision handsets over HTTPS with per-device credentials and keep firmware current.
Stream CDRs and security logs to the SIEM with alerts for new destinations, after-hours spikes and auth failure bursts.
Test emergency calling after every routing or barring change.

VoIP and SIP Security Guide: Toll Fraud, SIP Hardening and Encryption