Most toll fraud advice is about prevention. Strong passwords, locked-down ports, restricted dialplans. All correct, all necessary. But prevention is never perfect, and the difference between a minor scare and a five-figure bill usually comes down to one thing: how fast you notice an attack that got through.
This is the detection side. What an attack actually looks like in your logs and call records, and how to catch it while it is happening instead of when the invoice lands.
Phase 1: the scan, in your SIP logs
Before any fraudulent call, there is almost always a scan. Automated tools probe your SIP service looking for valid extensions and weak passwords. The classic one, sipvicious, has historically announced itself right in the User-Agent:
User-Agent: friendly-scanner
More broadly, what you see is a flood of failed registrations from one or a few IPs, hammering extension after extension. In an Asterisk security log it looks like repeated lines along these lines:
SECURITY ... Registration from '<sip:1001@x.x.x.x>' failed - No matching peer found
SECURITY ... Registration from '<sip:1002@x.x.x.x>' failed - No matching peer found
A human does not register a hundred different extensions in ten seconds. A scanner does. That pattern is your earliest warning, and it is easy to act on automatically with fail2ban watching the security log:
# fail2ban filter, matching failed registrations
failregex = SECURITY.*Registration from.*failed.*<HOST>
Ban the source after a handful of failures and most scans die before they ever find anything.
Phase 2: the calls, in your CDRs
If the scan succeeds and an account is compromised, the fraud moves into your call records, and this is where the money actually leaks. The signatures are distinctive enough to alert on:
A spike in concurrent calls from a single account
Calls to high-cost international or premium prefixes you rarely or never use
Long-duration calls to those destinations
A burst of activity outside business hours, especially overnight or on weekends
You do not need machine learning for this. A scheduled query against your CDR table catches most of it. For example, flagging recent calls to a set of high-risk prefixes:
SELECT accountcode, dst, COUNT(*) AS calls, SUM(billsec) AS seconds
FROM cdr
WHERE calldate > NOW() - INTERVAL 15 MINUTE
AND (dst LIKE '00888%' OR dst LIKE '00882%' OR dst LIKE '0053%')
GROUP BY accountcode, dst
HAVING calls > 5;
Or catching a single account suddenly placing an abnormal number of calls in a short window:
SELECT accountcode, COUNT(*) AS calls
FROM cdr
WHERE calldate > NOW() - INTERVAL 5 MINUTE
GROUP BY accountcode
HAVING calls > 20;
Run something like that on a short interval and wire the result to an alert channel a human will actually see. The right thresholds depend on your own traffic. The point is to define what normal looks like for your platform, then fire the moment something clearly is not.
Turn detection into a reflex, not a report
The trap most teams fall into is monitoring after the fact. A dashboard nobody watches, or a monthly report, does nothing when an attack burns through thousands of dollars in an afternoon. Detection only matters if it triggers something quickly.
A workable minimum:
fail2ban on the SIP logs to kill scans automatically
A scheduled CDR check on a short interval for the signatures above
Alerts to a channel that reaches someone out of hours, not an inbox opened on Monday
Ideally an automatic action on a strong signal, suspend the account, so the response does not wait for a human at 3am
Pair that with the prevention basics of good VoIP security (strong auth, IP restrictions, restricted dialing, spend caps) and you get both halves. Fewer attacks get in, and the ones that do get caught in minutes.
If you want the full prevention-and-response picture, including the layered controls across the SBC and softswitch, there is a detailed guide on stopping toll fraud and IRSF on SIP platforms that covers it end to end.
The takeaway is simple. Prevention keeps most of it out. Detection catches the rest before it becomes a bill. You want both, and the detection half is mostly a few log filters and CDR queries away.
Top comments (0)