VoIP toll fraud and SIP security: how attacks happen

VoIP toll fraud is the unauthorised use of someone else’s voice service to place calls that the account holder is then billed for. In almost every case the attacker is not stealing calls for their own conversations. They are generating traffic to destinations where they, or someone paying them, receive a share of the termination revenue. The call itself is the product. The victim’s SIP account is just the machine that manufactures it.

That economic structure explains most of what follows: why attacks arrive at weekends, why the destinations look strange, why call durations cluster, and why an incident that starts on a Friday evening can produce a five-figure bill by Monday. This article explains how the attacks work, which of them the SIP standard itself anticipates, and which controls actually interrupt them.

Toll fraud at a glance

What toll fraud is, and what it is not

Toll fraud is a billing attack, not a data breach. Nothing is exfiltrated and nothing is encrypted for ransom. The attacker uses your service exactly as it was designed to be used, at a scale you did not authorise, to a destination you would not have chosen.

It is worth separating three things that often get merged.

Toll fraud is unauthorised outbound calling billed to the victim.

Caller ID spoofing is presenting a number the caller has no right to present. It can be part of a fraud scheme, but on its own it costs the number’s owner nothing directly, and it is governed by a different set of rules.

Eavesdropping and tampering are confidentiality and integrity attacks on the call itself. They matter, and unencrypted SIP and RTP make them possible, but they are a much smaller share of real-world incidents than the billing attacks.

A useful way to hold the distinction: toll fraud attacks your account, spoofing attacks your identity, and interception attacks your conversation. The defences overlap but they are not the same defences.

Why your trunk is worth money to a stranger

International voice settlement is a chain of payments. When a call terminates in another country, the originating side pays the terminating side. Some number ranges carry very high termination rates, and some parties in that chain share the revenue with whoever generates the traffic. That arrangement, used legitimately, is how international premium rate services work. Used fraudulently, it is the engine of most voice fraud.

The industry term is International Revenue Share Fraud, usually abbreviated IRSF. The GSMA, whose IRSF prevention service maintains real-time intelligence on the number ranges involved, describes it as fraud in which the perpetrator artificially inflates traffic to portions of international number ranges, either by generating the calls directly with no intention of paying for them, or by stimulating other people into calling those ranges.

That second variant has its own name. Wangiri, from the Japanese for “one ring and cut”, places very large numbers of one-ring calls and waits for people to call back out of curiosity. The callback is the revenue event. The United States rules define this precisely enough to be worth quoting the mechanism: the FCC’s rules at 47 CFR 64.1200 define a one-ring scam as one in which a caller rings the called party for a short duration in order to prompt a return call that subjects the called party to charges, and permit voice service providers to block calls from numbers that reasonable analytics identify as highly likely to be associated with such a scam.

The Communications Fraud Control Association runs a biennial Global Fraud Loss Survey, the most widely cited industry measure of the total. Its 2025 edition has been reported as putting global telecommunications fraud losses at roughly USD 41.8 billion, with revenue-share and traffic-inflation categories consistently among the largest single contributors. The full report is available to CFCA members.

Two things follow from the economics that are worth internalising.

First, the attacker does not need long calls. Short, high-volume bursts to expensive destinations generate the same revenue with less chance of interruption. This is why a fraud pattern often looks like a dialler campaign rather than like conversation.

Second, blocking a list of “high-risk countries” is a weak control. The number ranges used are spread widely, change frequently, and are often not identifiable as premium rate from any published numbering plan. Allow-listing the destinations you actually call is far stronger than blocking the destinations you think are dangerous.

How attackers find SIP systems

Reconnaissance is automated and indiscriminate. Large parts of the public internet are scanned continuously for hosts that answer SIP, which normally means UDP and TCP port 5060 and TLS on 5061. A host that responds to an unauthenticated request has already revealed that it is a SIP endpoint, what software it runs, and often which version.

Two properties of SIP make the next step easier than it should be.

The first is that responses are informative. A SIP server that answers differently for a valid account than for an invalid one has told the scanner which accounts exist, before any password has been attempted. Returning 401 Unauthorized for a real account and 404 Not Found for a non-existent one is a specification-faithful implementation and an enumeration oracle at the same time. Well-configured systems return the same challenge either way. Our SIP response code reference covers what each code is supposed to mean and where the confusions arise.

The second is that SIP over UDP is cheap to probe and easy to source-spoof. There is no handshake to complete before sending a request, so a scanner can attempt an enormous number of hosts quickly, and an attacker can send requests that appear to come from an address that is not theirs.

An important corollary: an attacker does not always need to register at all. If a system accepts an INVITE and routes it without authenticating the sender, the trunk is effectively open. This is a configuration error rather than a protocol flaw, and it is a common one on systems where an internal-only trunk was later exposed, or where a permissive rule added for testing was never removed.

How credentials fall

Where authentication is required, the credentials generally fall for unglamorous reasons.

The extension is the username and something close to it is the password. Provisioning scripts that generate accounts sequentially with predictable secrets remain widespread.

Digest authentication historically used MD5. SIP borrowed HTTP Digest Access Authentication, and RFC 3261 specified MD5. RFC 8760, published in March 2020, updates that by adding SHA-256 and SHA-512/256 to SIP’s digest scheme. It keeps MD5 only for backward compatibility, states that its use is not recommended, and notes that retaining it opens the system to a downgrade attack by an on-path attacker, with the most effective remedy being to stop supporting MD5 at all. Support in real implementations arrived years after the RFC, so it is worth checking what your PBX and your provider actually negotiate rather than assuming the modern algorithm is in use.

Credentials leak from places other than the PBX. Provisioning files served over unauthenticated HTTP, configuration backups in cloud storage, softphone settings on a lost laptop, screenshots in support tickets, and credentials pasted into a shared document all appear in real incidents.

Password reuse crosses systems. A SIP secret that matches an email or portal password inherits the compromise of whichever is weakest.

Rate limiting matters more here than password complexity alone. A system that accepts unlimited authentication attempts from a single source will eventually give up a weak secret. A system that applies progressive delays and blocks after a threshold makes the whole approach uneconomic.

The attack classes named in the SIP standard

SIP’s own security considerations, in Section 26 of RFC 3261, set out a threat model that has aged well. Five attack classes are named, and each maps to something operators still see.

Registration hijacking. An attacker rewrites where a user’s calls are delivered by registering their own contact address. Inbound calls then arrive at the attacker instead of the legitimate endpoint. On a business line this is call interception; on a line used for account recovery it is the first step in a much larger fraud.

Impersonating a server. The attacker persuades a user agent that they are the proxy or registrar, and from that position controls what the endpoint believes about the call. TLS with proper certificate validation is what prevents this, which is why the certificate step in a trunk configuration is not optional decoration.

Tampering with message bodies. SIP bodies carry the session description, including the media addresses and any inline security parameters. Modifying that body redirects the audio without touching the signalling relationship.

Tearing down sessions. An attacker who can observe or guess the dialogue identifiers can inject a BYE and end a call in progress. This is a denial-of-service tool rather than a revenue tool, but it is trivially cheap on an unprotected UDP transport.

Denial of service and amplification. SIP servers can be induced to send more traffic than they receive, which makes them useful as reflectors. From the operator’s point of view the practical effect is that a system under a signalling flood stops processing legitimate calls, and the flood is often cover for something else.

The standard’s own answers are the ones still in use: transport and network layer security, the SIPS URI scheme, digest authentication, and message body protection. In modern deployments that resolves to TLS on the signalling and SRTP on the media, with digest authentication using a current algorithm.

One point deserves emphasis because it causes real confusion. TLS and SRTP protect different things and neither substitutes for the other. TLS encrypts the SIP messages, which contain the calling and called numbers and the authentication exchange. SRTP encrypts the audio. Where SRTP keys are negotiated inline in the session description, running SRTP without TLS puts the keys in the clear inside the very messages the attacker can read.

How a toll fraud incident actually unfolds

Real incidents follow a recognisable shape, and understanding the shape is what makes detection possible.

Reconnaissance runs continuously and independently of you. Your system is found because it answers, not because anyone targeted it.

Credential compromise may take hours or weeks depending on how the secret was obtained. This phase is quiet. Nothing is billed.

Validation is a small number of short calls, often to an ordinary-looking destination, made to confirm that the account works and that calls actually complete. The volume is low enough to look like normal activity. This is the last cheap moment to intervene.

Exploitation starts abruptly and is timed for absence. Friday evening, the start of a public holiday, or the small hours in the operator’s timezone. Concurrency rises to whatever ceiling exists, destinations shift to high-cost ranges, and durations cluster because the traffic is machine-generated rather than conversational.

Payout happens on the terminating side of the chain, in a different jurisdiction, through parties who have no relationship with the victim. By the time anyone notices, the traffic has stopped, the credentials have been abandoned, and the invoice arrives weeks later.

The attack surface that is not your PBX

Focusing entirely on the PBX misses several routes that recur in incident reports.

Voicemail and auto-attendant dial-out. Any feature that lets an inbound caller reach an outbound dial tone is a toll fraud vector. Direct inward system access, voicemail systems that permit outbound transfer, and auto-attendants configured to allow dialling arbitrary extensions all belong in this category. These features are frequently enabled by default and rarely used deliberately.

Call forwarding. A compromised user account with forwarding rights can point a number at an expensive international destination and then generate inbound calls to it. The outbound leg is billed to the account holder. Because the calls arrive legitimately from outside, PBX-side outbound controls may never see them.

Provider portal and API credentials. The portal that manages your account can usually create SIP accounts, change forwarding, and raise limits. That makes it as sensitive as the PBX. Multi-factor authentication on the portal is not a nicety.

Sub-accounts and reseller hierarchies. A wholesale account that provisions downstream customers inherits the weakest security posture among them. One compromised downstream sub-account produces a bill at the top of the chain.

Endpoints on untrusted networks. A softphone on hotel Wi-Fi or a home router with a helper that rewrites SIP packets creates exposure that is invisible from the PBX console. Router SIP helpers cause their own separate class of problem, covered in our guide to SIP ALG.

Caller ID spoofing is a separate problem

Spoofing gets discussed alongside toll fraud, but the mechanics, the victims and the legal position are different.

Presenting a number you are not entitled to present is regulated rather than technically prevented in most of the world. In the United States, the Truth in Caller ID Act and the implementing rule at 47 CFR 64.1604 prohibit knowingly causing a caller identification service to transmit or display misleading or inaccurate information with the intent to defraud, cause harm, or wrongfully obtain anything of value. The prohibition reaches parties outside the United States where the recipient is inside it, and it carries specific exceptions for authorised law enforcement and intelligence activity and for court-authorised use. The intent element is what distinguishes unlawful spoofing from the entirely ordinary practice of a business presenting its main switchboard number on calls from an extension.

In the United Kingdom, the equivalent constraints sit in Ofcom’s treatment of caller line identification misuse rather than in a spoofing statute, and they cover withholding caller ID on marketing calls, presenting numbers that are not valid or authentic, and presenting numbers that cannot be returned.

The practical consequence for a legitimate operator is that spoofing exposure is mostly reputational and regulatory rather than financial. If your numbers are being presented by someone else, the cost lands as call analytics labelling, complaints, and blocked delivery rather than as a bill. That is a different problem with a different fix, covered in our guide to caller ID reputation and spam labelling.

The controls that actually work, in the order they act

There is no single control that stops toll fraud. There is a stack, and its usefulness is determined almost entirely by how early in the attack each layer acts, not by how sophisticated it sounds.

Do not expose SIP to the open internet. This is the highest-value control and the most often skipped. If your provider publishes the addresses of its SIP gateways, allow traffic from those and nothing else. If your endpoints have static addresses, ask your provider to authenticate you by IP address rather than by registration, which removes the password from the attack surface entirely. Where dynamic addresses make that impossible, restrict by country or network range and accept that the control is weaker.

Note the media exception. Signalling addresses are usually a small, stable set. RTP media addresses generally are not, so a firewall rule that permits media from a narrow range is a common cause of one-way audio. Providers usually publish a media port range and expect it to be open more broadly than signalling, and some will supply a media address list on request if your policy cannot allow a wide source range.

Use current digest algorithms and long unique secrets. Per RFC 8760, prefer SHA-256 or SHA-512/256, and remove MD5 support where both ends can manage it. Generate secrets randomly, never derive them from the extension number, and never reuse them across systems.

Turn on TLS, and SRTP where the path supports it. This closes the impersonation and tampering classes from the standard’s threat model, and prevents an on-path observer from reading the numbers and authentication material in your signalling.

Allow-list destinations rather than blocking them. Most organisations call a predictable set of countries. Permitting that set and requiring a deliberate change to add another turns an unlimited loss into a bounded one. Combine it with a separate, tighter policy for premium rate ranges.

Cap what a single account can do. Concurrent channel ceilings, calls-per-second limits, and per-account spend caps convert a catastrophic incident into an annoying one. Prepaid balances have the same effect by a different route: the loss cannot exceed the balance.

Rate-limit authentication and block on repeated failure. Progressive delays and automatic blocking after a threshold make credential guessing uneconomic without inconveniencing legitimate endpoints.

Disable the dial-out features you do not use. Voicemail outbound transfer, direct inward system access, and unrestricted auto-attendant dialling should be off unless there is a named business reason for each.

Separate duties in the portal. Multi-factor authentication on the account portal, restricted rights for staff who do not need to change routing, and alerting on changes to forwarding and account limits.

What to monitor, and how quickly

Detection speed is the whole game. The difference between catching an incident in the first minutes and catching it in the monthly invoice is the difference between a rounding error and a serious loss.

Monitor these signals, in roughly this order of usefulness.

Call attempt rate per account, in real time. A sudden change in attempts per second on an account with a stable historical profile is the single clearest signal.

Destination mix. Calls to countries or prefixes the account has never called before, especially in volume, especially outside working hours.

Duration distribution rather than average. Machine-generated traffic clusters. A large number of calls at nearly identical durations is not conversation.

Concurrency against ceiling. An account pinned at its channel limit that has never previously approached it.

Time of day. Business accounts have a shape. Traffic that does not match the shape deserves attention even when the volume is modest.

Authentication failure rate. A spike in failed registrations from unfamiliar sources is reconnaissance in progress and is worth acting on before anything is billed.

The distinction that matters most is between monitoring signalling as it happens and analysing call records afterwards. Call detail records are accurate, complete and necessary, and they arrive after the calls have completed and billed. Signalling-time analysis is noisier but can act while the attack is running. Both belong in the stack, and only one of them can prevent a loss.

The first hour of a suspected incident

1. Stop the traffic before diagnosing it. Disable the affected SIP account or suspend outbound calling on it. Understanding can wait; the meter cannot.
2. Contact your provider immediately, by phone if the incident is out of hours. Providers can block at the network level faster than you can reconfigure a PBX, and many maintain a 24-hour operations contact for exactly this.
3. Preserve evidence. Export call records for the affected window and capture SIP logs before anything rotates or is overwritten.
4. Rotate every credential on the affected system, not only the one you believe was used. Assume the same list was tried elsewhere.
5. Check for persistence. Look for new SIP accounts, changed forwarding rules, altered dial plans, modified voicemail settings, and raised limits.
6. Review the exposure that allowed it. Which port was reachable, from where, and why. Fix that before restoring service.
7. Discuss the bill early. Liability normally sits with the account holder because valid credentials were used, but providers do sometimes apply commercial discretion, and the conversation goes better when it starts on day one rather than on receipt of the invoice.

Common mistakes

Treating the PBX as the whole perimeter. Portal credentials, forwarding rules and sub-accounts sit outside it and are attacked just as often.

Relying on a country blocklist. The ranges used for revenue share move constantly and are frequently not identifiable as premium rate. Allow-list what you call.

Leaving a permissive rule in place after testing. A temporary any-source rule added during commissioning is one of the most common root causes.

Assuming a monthly invoice review is monitoring. It is reconciliation. By the time it fires, the loss is complete.

Configuring SRTP without TLS. Where keys are carried inline in the session description, this protects the audio while publishing the key.

Assuming a router SIP helper adds security. It does not, and it frequently breaks working configurations in ways that look like faults elsewhere.

Believing that registration is inherently safer than IP authentication. For an endpoint with a static address, IP authentication removes a guessable secret from the internet entirely. Registration is a convenience for endpoints that move, not a security feature.

Not testing the out-of-hours escalation path. Incidents are timed for the moment nobody is watching. Knowing who to call at 02:00 on a Sunday is part of the control, not part of the paperwork.

Where didlogic fits

didlogic operates the voice infrastructure layer, so several of the controls above are things a provider either supports or does not. The relevant ones are documented publicly.

Allow-listing. didlogic publishes the DNS names and addresses of its regional SIP gateways in its FAQ, and recommends building firewall rules against the DNS names rather than static addresses. It also documents the media exception directly: RTP addresses are numerous and change, so the guidance is to permit audio on the published port range, with a supported path for customers whose policy cannot allow a broad media source range.

IP authentication instead of registration. IP-based SIP trunking is supported, using a dedicated SIP account configured for IP authentication rather than a registered credential.

Encryption. TLS is supported on port 5061 with a documented root certificate step, and the platform responds using TLS once an endpoint is configured for it. SRTP is available to encrypt the media itself, including on inbound DID products rather than only on the outbound leg. The encrypted calls documentation sets out the combinations.

Capacity gated on security. This one is worth calling out because it inverts the usual arrangement. Outbound channel and calls-per-second increases beyond the standard thresholds are available after enabling security measures such as two-factor authentication and IP restriction on SIP accounts. In other words, the ceiling that limits the size of a potential incident is raised only once the controls that prevent one are in place.

Account validation. Profile validation is carried out by a compliance review after account creation, which is the provider-side equivalent of knowing who is originating traffic on the network.

Traffic monitoring. For dialler and short-duration traffic, answer-seizure ratio, calls per second and average call duration are monitored around the clock by network operations staff who contact customers when a system is not behaving as expected. Those are the same signals that distinguish a fraud pattern from a legitimate campaign.

What remains with you is everything above the trunk: the PBX or platform configuration, the strength and rotation of credentials, which internal features are enabled, who has access to the portal, and how quickly your own team notices and responds. A provider can constrain the blast radius and can act quickly when told. It cannot see inside your dial plan, and it cannot know that a call to an unusual destination was not something you meant to do.

Frequently asked questions

Who pays for fraudulent calls?
In most cases the account holder, because the calls were placed using valid credentials on the account. Providers may exercise commercial discretion, and contracts vary, but the default position across the industry is that the customer is responsible for traffic originated on their account. This is why prepaid balances and spend caps are meaningful controls rather than administrative details.

Is SIP inherently insecure?
No. SIP defines authentication, transport security and body protection, and Section 26 of RFC 3261 sets out the threat model explicitly. The common failures are deployment choices: exposing the service publicly, using weak or reused secrets, running MD5 digest over unencrypted UDP, and leaving dial-out features enabled. The protocol supports doing better.

Does TLS stop toll fraud?
Not on its own. TLS prevents interception and tampering of the signalling and defeats server impersonation. It does not help if the attacker has valid credentials, because they will simply use them over TLS. Encryption and authorisation solve different problems.

Why do attacks happen at weekends?
Because the constraint on the attacker is detection time, not technical difficulty. A Friday evening start on a long weekend can yield two or three days of unmonitored calling. Time-of-day anomaly alerting is one of the cheapest effective controls precisely for this reason.

Should I block calls to expensive countries?
Allow-listing the destinations you actually call is stronger. Blocklists have to keep pace with number ranges that move constantly and are often not identifiable as premium rate from any public source, whereas an allow-list fails safe by default.

What is the difference between IRSF and Wangiri?
Wangiri is a technique within IRSF. IRSF is the broad category of artificially inflating traffic to international ranges that pay a share of termination revenue. Wangiri does it by provoking the victim into making the call, using one-ring calls that prompt a callback.

Is IP authentication safer than a username and password?
For an endpoint with a stable public address, yes, because there is no secret to guess and no registration to hijack. It is not appropriate for endpoints that move between networks, which is where digest authentication with a strong algorithm and rate limiting remains the right approach.

How quickly should an incident be detectable?
The realistic target is minutes, not hours, and that requires monitoring signalling as it happens rather than reviewing call records afterwards. Call record analysis remains necessary for reconciliation and investigation, but it is a reporting layer, not a prevention layer.

Continue learning

• What is SIP?
• What is SIP trunking?
• SIP response codes explained
• SIP ALG: why it breaks SIP calls and how to diagnose it
• Caller ID reputation and “Spam Likely” labels explained
• What is the PSTN?
• E.164 explained: the international number format