VoIP Toll Fraud Prevention: Stop SIP Attacks Before They Cost You

What toll fraud is, and why it's so costly

Toll fraud is the unauthorised use of your phone system to make calls you pay for. The calls almost always go to expensive international or premium-rate destinations, because the attacker has an arrangement to receive part of the revenue for each minute. Every call they make earns them money and costs you.

The damage builds quickly. Attackers run many calls in parallel, around the clock, and they time attacks for nights, weekends and holidays when nobody is watching. By Monday morning the bill can run into thousands. Industry surveys put total telecom fraud losses in the tens of billions of dollars a year; the Communications Fraud Control Association's survey reported about $39 billion for 2023, with revenue-share fraud among the largest categories.

Types of VoIP fraud

How a typical attack happens

• Scanning: automated tools sweep the internet for SIP servers on ports 5060 and 5061 and identify the software.
• Enumeration: they probe extension numbers to find ones that exist.
• Password guessing: they try common and default passwords against each extension, at high speed.
• Testing: with a working account, they place a few short calls to check what routes are open.
• Attack: they launch many parallel calls to expensive destinations, usually at night or over a weekend.
• Repeat: if not blocked, they come back, sometimes through other accounts they have found.

Every step leaves a trace: failed registrations, unusual user agents, calls to new countries, too many concurrent calls. Good defences stop the early steps and catch the later ones within minutes.

Defence in layers

Layer 1: network and edge

• Don't expose SIP to the whole internet if you don't need to: allow only your carriers' and offices' IP addresses.
• Where remote phones and apps must connect, put an SBC or a Kamailio or OpenSIPS edge in front of the PBX.
• Rate-limit requests per source address, and block known scanner user agents.
• Keep admin panels (FreePBX, FusionPBX, 3CX consoles) off the public internet, behind a VPN.
• Use fail2ban or similar to ban addresses after repeated authentication failures.
• Use SIP over TLS for phones and apps where possible; it also stops credentials leaking on the network.

A minimal fail2ban set-up for Asterisk watches the security log for failed authentication and bans the source address. Treat the numbers as starting points and tune them to your traffic.

# /etc/fail2ban/jail.d/asterisk.conf
[asterisk]
enabled  = true
filter   = asterisk          # shipped filter matching failed SIP authentication
logpath  = /var/log/asterisk/security
maxretry = 5                 # failures before a ban
findtime = 600               # within 10 minutes
bantime  = 86400             # ban for 24 hours
action   = iptables-allports[name=asterisk, protocol=all]

Example: rate limiting and scanner blocking in Kamailio

Kamailio's pike module tracks requests per source address and flags floods, which catches most scanners and brute-force attempts before they reach the PBX.

# kamailio.cfg (excerpt)
loadmodule "pike.so"
modparam("pike", "sampling_time_unit", 2)      # seconds per sampling window
modparam("pike", "reqs_density_per_unit", 16)  # max requests per window per IP
modparam("pike", "remove_latency", 4)

request_route {
    # Drop known scanner user agents early
    if ($ua =~ "friendly-scanner|sipvicious|sipcli|sip-scan") {
        xlog("L_WARN", "scanner blocked: $si ua=$ua\n");
        exit;
    }
    # Rate-limit everything not coming from our own servers
    if (src_ip != myself && !pike_check_req()) {
        xlog("L_ALERT", "pike: flood from $si, dropping\n");
        exit;
    }
    # ... normal routing, with authentication before relaying to the PBX
}

Our Kamailio development and OpenSIPS development pages cover SIP edge design, including topology hiding and per-tenant limits.

Layer 2: authentication

• Use long, random SIP secrets for every account, never the extension number or a dictionary word.
• Change every default password. FreeSWITCH, for example, ships with a default directory password (1234 in vars.xml) that must be changed before going live.
• Disable guest and anonymous calling unless you need it, and make sure unauthenticated calls can't reach outbound routes.
• Restrict where each account may register from, where possible, and alert when it registers from a new country.
• Use strong voicemail and portal PINs, and lock accounts after repeated failures.
• Remove accounts for departed staff and decommissioned phones promptly.

<!-- FreeSWITCH vars.xml: change the default directory password before go-live -->
<X-PRE-PROCESS cmd="set" data="default_password=CHANGE-ME-to-a-long-random-value"/>

Layer 3: dialplan rules

Assume a password will be stolen one day. The dialplan decides how much damage a stolen account can do.

• Block international calling by default; enable it per account or per tenant only where needed.
• Use a country allow-list rather than a block-list; allow only the countries each customer actually calls.
• Block premium-rate and special-service ranges outright.
• Require a PIN for international calls from desk phones, or limit them to business hours.
• Never let incoming calls reach outbound routes through forwarding or remote-access features unless strictly controlled.

; Asterisk extensions.conf: international only for allowed accounts, with a concurrency cap
[outbound]
exten => _00X.,1,NoOp(International call from ${CALLERID(num)} to ${EXTEN})
 same => n,GotoIf(${DB_EXISTS(intl_allowed/${CALLERID(num)})}?allowed)
 same => n,Playback(ss-noservice)              ; not allowed for this account
 same => n,Hangup()
 same => n(allowed),Set(GROUP(intl)=${CDR(accountcode)})
 same => n,GotoIf($[${GROUP_COUNT(${CDR(accountcode)}@intl)} > 2]?busy)
 same => n,Dial(PJSIP/${EXTEN}@carrier,60)
 same => n,Hangup()
 same => n(busy),Playback(all-circuits-busy-now) ; more than 2 international calls at once
 same => n,Hangup()

Layer 4: call and spend limits

Limits don't prevent an attack, but they cap how much it can cost. They are the cheapest insurance you can buy.

On multi-tenant platforms, rating calls in real time against limits is part of the billing system; see our VoIP billing page and CDR and billing guide.

Layer 5: monitoring and automatic response

The response must be automatic. A human reading an email alert on Monday is too late; a rule that suspends international calling on an account within minutes is not.

Securing SIP trunks and carrier accounts

• Authenticate trunks by IP where your carrier supports it, and with strong credentials where it doesn't; ideally both.
• Never reuse trunk credentials on phones or apps.
• Enable international blocks, spend caps and fraud alerts on the carrier account itself, as a second line of defence.
• Use separate trunks or accounts for different tenants or departments, so one compromise doesn't affect all.
• Review carrier invoices and usage dashboards weekly, not only monthly.

Our SIP trunk solutions page covers trunk design and carrier failover.

Softphones and remote staff

Remote working means phones register from home networks, hotels and mobile data, so IP allow-lists alone can't protect them. Compensate with other controls.

• Provision softphones by QR code or link, so users never see or type their SIP password.
• Use TLS and SRTP for remote devices, so credentials and calls can't be captured on public Wi-Fi.
• Alert when an account registers from a new country, and block countries you never operate in.
• Limit remote accounts to the call types they need; most don't need international calling.
• Revoke credentials immediately when a device is lost or a person leaves.

Extra controls for multi-tenant platforms

Hosted PBX and UCaaS providers carry the risk for every customer at once. A single weak tenant can generate a large bill that the provider may not be able to recover.

See our multi-tenant VoIP platform architecture guide and the hosted PBX case study.

If you're hit

• Stop outbound international calling immediately, globally if needed.
• Ask your carrier to block destinations and flag the fraud; some can stop calls already in progress.
• Identify the compromised account or route from call records, and disable it.
• Change credentials on every account that could be affected, and review recent configuration changes.
• Keep call records and logs as evidence for your carrier and, if appropriate, the authorities.
• Fix the root cause before restoring service, then add the missing layer.

Test your defences regularly

Controls drift: a new tenant is created with international enabled, a firewall rule is relaxed for a test and never restored, a carrier changes its addresses. A short, regular test catches these before an attacker does.

Only test systems you own or are authorised to test, and tell your carrier before deliberately generating unusual traffic. A quarterly test, plus one after any major change to the platform, is a sensible rhythm for most organisations.

Toll-fraud prevention checklist

Frequently asked questions