VoIP toll fraud: what to lock down

VoIP toll fraud is unauthorized use of a business phone system to place billable calls. The attacker may compromise a cloud-PBX administrator, SIP trunk, extension, voicemail feature, forwarding rule, session border controller, or carrier account. The technology changes; the invoice still belongs to somebody.

Controls reduce the likelihood and size of a loss, but none guarantees prevention or that a carrier will waive charges. Confirm responsibilities, limits, and reporting procedures in the actual service agreement.

Map every way a call can leave

Start with a simple call-flow inventory:

• Carrier and SIP trunk accounts
• Cloud PBX or unified-communications tenants
• Session border controllers, gateways, ATAs, and desk phones
• Softphones and mobile applications
• Auto attendants, call queues, voicemail, and remote call-out features
• Call forwarding, simultaneous ring, and after-hours routing
• Contact-center integrations, APIs, and automation accounts
• Emergency and analog lines that sit outside the main platform

For each component, identify the owner, admin accounts, authentication method, public network path, permitted destinations, concurrent-call limit, alert recipient, call-detail record location, and carrier emergency contact.

Do not assume a fully hosted system eliminates customer configuration. The provider may secure its platform while the customer still controls administrators, dialing policies, forwarding, devices, and alert contacts.

Restrict the dial plan to business need

Treat outbound calling like a spend-capable service.

Disable destinations that nobody uses. Block international, premium-rate, satellite, and other high-cost destinations by default where the provider supports it. Allow only countries and number types tied to a documented role or workflow. The FCC’s older but still relevant toll-fraud consumer alert recommends asking the carrier about restricting international calls and disabling unused remote-access features.

Limit who may place expensive calls. Apply policies by user, extension, location, or group instead of granting every lobby phone the same route as the executive team. Require an authorization mechanism for exceptional dialing, and protect its code like a credential.

Cap the possible burst. Ask the provider about concurrent outbound-call limits, per-extension limits, daily spend thresholds, destination blocks, and automatic suspension behavior. Set the cap from normal call volume plus a justified margin, not the platform maximum.

Review forwarding separately. An extension blocked from direct international dialing may still forward to an expensive destination depending on the platform. Test the effective policy for voicemail, auto attendants, queues, mobile clients, and delegated users.

Protect the control plane

Phone administration deserves the same discipline as email or finance systems.

• Require MFA for carrier, PBX, registrar, and management accounts wherever available. CISA’s small-business MFA guidance recommends starting with administrative and remote access.
• Use named admin accounts and least-privilege roles. Keep daily calling identities separate from administrative access.
• Store emergency and shared credentials in a managed vault, not a spreadsheet or phone-system note. See our shared admin secrets guide.
• Remove former staff, installers, and vendors promptly. Make vendor access time-bound when possible using a just-in-time access pattern.
• Change default device, provisioning, voicemail, and remote-access credentials. Disable unused accounts and features.
• Protect API keys, provisioning URLs, recovery codes, and carrier account PINs; rotate them after personnel or provider changes.
• Require an out-of-band verification step for number porting, trunk changes, payment changes, and new administrators.

MFA does not fix weak dial permissions or an exposed SIP credential. It protects one layer of a system that needs several.

Reduce unnecessary network exposure

Avoid publishing phone, gateway, provisioning, or PBX management interfaces directly to the internet. Restrict management to approved paths, and limit SIP peers to documented provider addresses or authenticated connections where the architecture supports it.

Use a supported session border controller or provider design rather than opening large static port ranges without understanding the media flow. NIST’s VoIP security guidance is old enough to predate modern cloud PBXs, but its principles remain useful: broker voice traffic through appropriate firewalls, separate security zones, authenticate components, and account for dynamic media traffic.

Segment voice devices from ordinary workstations where practical. Patch supported PBXs, SBCs, gateways, phones, and provisioning systems; remove abandoned devices and stale DNS or firewall rules. Document every required rule and review changes using the same discipline as other firewall changes.

Use encrypted signaling and media when the full provider-and-device path supports it, but do not confuse encryption with authorization. An encrypted fraudulent call is still fraudulent.

Make call anomalies visible

Call-detail records and change logs need to be available before an incident. Retain them according to business, contractual, privacy, and legal requirements, and make sure more than one authorized person can export them.

Alert on behavior that is unusual for the organization:

• First-time or blocked destination countries
• Calls outside expected business hours
• Sudden increases in concurrent calls, duration, or spend
• Repeated authentication or registration failures
• New forwarding destinations or dial-plan changes
• New administrators, devices, trunks, or API tokens

Route alerts to a monitored channel with an after-hours escalation path. Test the alert by making an approved call that crosses a low test threshold. A notification buried in the former office manager’s inbox is not a control the business can operate.

Review a sample of call and admin activity regularly. Baselines change when a company opens a location, adds a contact center, or begins calling a new region; update rules deliberately instead of disabling noisy alerts.

Have a containment runbook

If toll fraud is suspected:

1. Contact the carrier or hosted provider through the documented emergency path and restrict outbound routes, destinations, trunks, or affected accounts.
2. Preserve call-detail records, authentication logs, admin changes, forwarding configuration, invoices, timestamps, and relevant device logs before routine retention removes them.
3. Revoke active sessions and rotate compromised admin, SIP, API, device, provisioning, voicemail, and recovery credentials as applicable.
4. Review forwarding, auto attendants, remote call-out, new devices, carrier-account changes, and firewall exposure.
5. Notify the internal incident lead and finance. Follow provider, insurer, law-enforcement, legal, and regulatory reporting advice appropriate to the event.
6. Re-enable calling narrowly after the entry path is understood, then monitor closely and document the lessons learned.

Use the broader incident first-hour checklist so the phone response does not happen separately from identity, endpoint, network, and communications work.

Do not delete evidence in the rush to reset everything, and do not promise that a disputed charge will be reversed. Preserve the facts and follow the carrier’s process quickly.

Bottom line

The useful VoIP toll-fraud baseline is constrained dialing, limited administration, hardened network paths, usable call records, staffed alerts, and a tested carrier escalation route. Design the phone system so one stolen credential cannot create unlimited calls to every destination. The controls cannot guarantee prevention, but they can make abuse harder to start, faster to detect, and easier to contain.