How VoIP providers get drained in 30 minutes

You open Last Calls on a Monday and a prepaid balance is gone. Or a postpaid account with unlimited credit spent half an hour on satellite, cruise-ship, and premium-rate prefixes. The upstream carrier invoice is the same story, a week later, with a larger number.

SIP scanners find UDP 5060 on any new public IP. Kolmisoft’s Friendly-Scanner post records more than 80 REGISTER requests per second once a box is on a list. Failed storms fill logs and burn bandwidth. Attackers who steal a working account, or hijack a customer PBX that registered to you, originate international, premium, and traffic-pumping ranges.

This checklist is for VoIP operators and ITSPs: the three drain patterns, how to tell which one you have, and the controls that drop the call instead of rating it after the invoice.

Three ways the money leaves

SIP scanners and brute-force registration

Tools such as SIPVicious and Friendly-Scanner probe the public internet for SIP. If they reach you, they try common extensions and weak passwords. A stolen login becomes an outbound trunk to expensive destinations.

Open Last Calls, click Call Info, and read Originator → Source IP. Hangup cause 200 (MOR can’t determine who is calling) means the switch did not match the attempt to a Device or Provider. That is a rejected probe, not a completed call. A flood from one IP means you are on a scanner list.

Keep SIP (UDP/TCP 5060) off the public internet unless you must expose it. Prefer a VPN, an SBC, or IP allowlists from known customer and provider ranges. On a MOR install, Fail2Ban is part of the default security stack: see How to be secure using MOR.

Compromised customer PBX or softphone

Your switch can be locked down and you pay anyway. A customer’s FreePBX, Grandstream, or Yealink sits on a public IP, answers the same scanners, and registers to you with a valid account. PBX security best practices on that customer box: unique passwords, no default extensions, no UPnP forwards that hand the handset a public SIP port.

The source IP belongs to a customer you know, but the destinations, duration, and simultaneous legs do not. Night and holiday windows show up first, along with traffic-pumping NPAs and high-rate international prefixes.

Treat every new customer as a risk until proven. Give postpaid accounts a low credit, run prepaid with a live balance, and block destinations for premium, satellite, and ranges you do not sell. Spend and simultaneous-call alerts catch the account after authentication.

Inbound that costs you money

Toll-free owners see this more than class 4/5 operators: robocalls to 8YY numbers that skip the auto-attendant and rack up per-minute charges. The fix is traceback and carrier filters, not SIP registration bans. Fraud traffic bills faster than a human ticket queue.

Every new public SIP IP gets probed. Keep those probes from becoming paid minutes.

Prevention: lock the edge, bill live, auto-block

An open 5060 with perfect billing eats CPU and logs. A closed edge with unlimited postpaid credit pays for a stolen account. Close the edge first, then put money controls on every account.

Network and SIP

• Keep SIP off the public internet where you can. VPN, SBC, or allowlists from known ranges.
• Disable UPnP and casual port forwards on customer ATAs and phones.
• Use TLS on a non-default port where customers can support it. Keep cleartext SIP for trusted peers.
• Put an SBC or firewall in front of wholesale edges: topology hiding, header control, rate limits.

Credentials and accounts

• Strong, unique SIP passwords. No 1000 / 1000 defaults. Separate credentials per device. Rotate after staff changes.
• Lock the admin GUI: HTTPS, 2FA where available, IP restriction for admin login.
• Start new customers with low credit. Infinite credit on postpaid is risky.

Billing that cuts the call

Rating a CDR after hangup does not stop the current call.

• Prepaid: MOR checks balance every few seconds and ends live calls when the balance nears zero.
• Postpaid credit: calls stop when the balance hits the allowed debt (example: credit 10, cutoff at −10).
• Daily Balance Limit: checked every second; ongoing calls drop and new ones fail with hangup cause 290.
• Warning Balance email (and optional webhook) before the wallet is empty. Emails go out once an hour, so this is an early warning, not a live cut.
• Block or restrict high-cost destination groups for new or untrusted users.

Detection that blocks

• Fail2Ban on SIP registration, SSH, and GUI/API abuse. MOR defaults (from How to be secure using MOR): 5 failed SIP registrations in 10 minutes (ban 10 minutes); 20 hangup-cause-200 attempts in 10 minutes (permanent); scanner User-Agents such as sipvicious and friendly-scanner (permanent).
• Blocked IPs in the GUI (SETTINGS → Security → Blocked IPs) and via API. Manual rows show MOR-BLOCKED-IP-FROM-GUI. Fail2Ban scanner bans show fail2ban-AST_CLI_Attack.
• Blocked Countries for markets you do not sell to. Core security; no Monitorings Addon. ipdeny.com lists are not perfect, so whitelist interconnect IPs that get caught.
• A trickle of hangup-cause-200 probes is normal. A flood from one IP belongs on Blocked IPs after you confirm it is not a client or provider.

Spend and behavior alerts

Firewalls miss an account that looks legitimate and then spends. Configure alerts that disable the user.

The Monitorings Addon is optional. Prepaid cut-off, credit, Daily Balance Limit, Fail2Ban, Blocked IPs, and Blocked Countries are on the core stack. Alerts in the addon catch behavior that looks like a valid account:

• Raise on PRICE SUM and disable the user. Example: spend ≥ 50 EUR in 24 hours.
• Raise on SIMULTANEOUS CALLS and disable the user. Example: ≥ 2 parallel legs to the same destination, stay disabled until a human clears it.
• Watch ASR / ACD / PDD on providers. Fraud and bad routes show as quality collapse before finance does.
• Notify a contact group by email and by webhook when severity is high.

Daily hygiene

• Skim Active Calls for odd destinations every morning, and after holidays. Reconcile upstream invoices against CDRs each week.
• Write a short incident runbook: who gets the alert, how to block an IP or user, how to open an upstream dispute. Keep the platform and OS patched.

How those controls sit in MOR

Ask vendors these three questions:

1. Can you cut a live call when balance or policy says stop?
2. Can you disable a user on spend or simultaneous-call thresholds without waiting for a human?
3. Are IP/country blocking and registration-abuse protection in day-one ops, or added after the first invoice shock?

A first-hours sequence for a new public IP

When a softswitch IP becomes public, scanners arrive. Treat the first hours as a security job:

1. Confirm SIP is not world-open, or restrict it to allowlists.
2. Confirm Fail2Ban is running and writing bans.
3. Set conservative credit and Daily Balance Limits on every test account. No infinite credit.
4. Create at least two alerts: 24h PRICE SUM cap, and unexpected simultaneous calls. Disable the user on both.
5. Block countries outside your market.
6. Make a failed registration from an external IP and confirm it lands in Blocked IPs.
7. Point real customers at the system after those six checks.

High-risk wholesale edges need an SBC in front of the switch. If spend is on the wire: hang up the Active Calls, disable the user, block the source IP, restrict the destination group, then open the upstream dispute with CDRs. The runbook should name who does each step at night.

FAQ

Is hangup cause 200 a sign the switch is hacked?

HGC 200 means MOR rejected an unidentified caller. A trickle is normal on any public SIP IP. Confirm the source IP is not a customer or provider, then leave it, Fail2Ban it, or block it. See 200 MOR can’t determine who is calling.

Will Fail2Ban ban real customers?

It can, if a phone retries with a wrong password past the jail. MOR’s SIP-registration jail is 5 failures in 10 minutes, then a 10-minute ban. Put known office and provider IPs on the Fail2Ban ignoreip list (How to add Fail2ban exception for my IP).

Check the controls before you put customers on the box

A public SIP IP will be probed. Weak credentials plus no live money controls turn that probe into a drain. Lock the edge, bill in real time, alert on behavior, and disable the account when a threshold trips. Do that before you scale marketing.

Open the MOR online demo and walk SETTINGS → Security → Blocked IPs plus ADDONS → Monitorings → Alerts. The demo is the admin UI; it does not place live calls. Related reading: SIP Attack: Friendly-Scanner, PBX Security Best Practices, FRAUD: False Answer Supervision (FAS).