PBX under attack — incident-response runbook

A compromised PBX is the worst infrastructure incident a small business can have. International toll fraud runs up bills in the thousands of dollars per hour; you find out from your carrier or your bank, not from monitoring. This article is the runbook for the first 60 minutes after you notice something is wrong.

Symptoms of an active incident

• Carrier portal shows unusually high outbound volume to international destinations (often premium-rate numbers in Cuba, Latvia, North Korea, Maldives).
• SIP traffic volume to/from your VPS is well above normal.
• asterisk -rx "core show channels" shows many active calls you didn't initiate.
• Carrier sends fraud alert email or calls you directly.
• Sudden $500+ charge appears in your carrier dashboard.

Step 1: stop the bleeding (under 5 minutes)

Goal: stop the PBX from making outbound calls IMMEDIATELY. Don't worry about diagnosis or evidence preservation — stop the outflow first.

# Option A: stop the SIP service entirely
systemctl stop asterisk
# or for FreeSWITCH:
systemctl stop freeswitch

If you can't stop the service (because legitimate calls are in progress and you don't want to drop them — debatable in an active fraud incident):

# Option B: block outbound SIP at the firewall
# nftables:
nft add rule inet filter output ip protocol udp udp dport 5060 reject
nft add rule inet filter output ip protocol udp udp dport 5061 reject

If you have an authentication-based trunk (most carriers), the simplest stop-bleeding is to:

Call your carrier's emergency line and have them disable outbound on your account. They will. Takes a phone call to a human who picks up at 3 AM. Their fraud department deals with this constantly.

Step 2: assess (next 15 minutes)

Once the bleeding is stopped, find out what happened:

# Recent CDR — last 24 hours
mysql asteriskcdrdb -e "SELECT calldate, src, dst, disposition, duration FROM cdr WHERE calldate > NOW() - INTERVAL 24 HOUR ORDER BY calldate DESC LIMIT 100;"

# Asterisk auth failures recent
grep -E "Failed|password" /var/log/asterisk/full | tail -100

# SIP scanning traffic
grep "INVITE sip:" /var/log/asterisk/full | head -50

Common patterns:

• Bruteforced extension password — attacker SIP-scanned, guessed an extension's weak password, registered as that extension, dialed out via your trunk.
• Default credentials left in place — admin / admin GUI password, or extension PINs left at default.
• Dialplan injection — pattern in your outbound route matched things you didn't intend (commonly: international prefix not explicitly blocked).
• Compromised admin account — credentials stolen via phishing, attacker logs into the GUI and changes routing.

Step 3: contain (next 30 minutes)

• Reset all extension passwords. Generate strong random ones, push to phones via your endpoint provisioning system if you have one.
• Reset the GUI admin password.
• Reset the trunk auth credentials if your carrier uses password auth (or rotate the IP-allowlist if IP-based).
• Disable any outbound routes that allow international or premium-rate destinations until you've confirmed they're needed.
• Add country-allowlist or destination-prefix restrictions to outbound routes (only allow US/CA destinations unless an extension is specifically authorized for international).

Step 4: investigate the entry point

Don't restart service until you know how they got in. Otherwise they'll be back in within hours.

• Check all admin accounts in the GUI. Any accounts you don't recognize? Remove.
• Check fail2ban logs — was the attacker rate-limited but ultimately broke through? Tighten maxretry and bantime.
• Check the PBX's logs from before the incident started. SIP scanners typically probe for weeks before finding a vulnerability.
• Check that ports 5060/5061 aren't publicly exposed — most operators should restrict SIP source IPs to their carrier's ranges only.

Step 5: restore service

Once you have:

1. Stopped active fraud.
2. Identified entry vector and closed it.
3. Rotated all credentials.
4. Tightened outbound routes.
5. Reviewed fail2ban / firewall rules.

Restart Asterisk® or FreeSWITCH®, then make a few test calls. Monitor for the next 24 hours — if anything was missed, it'll show up again.

Step 6: deal with the carrier bill

Carriers vary:

• Some (Telnyx, Twilio) have fraud-protection caps that auto-blocked further outbound after a threshold — you may only owe up to that cap. Read your contract.
• Some will waive charges from confirmed fraud incidents, especially first-time. Ask. Be cooperative; share what you learned in your investigation.
• Some will hold you to the full bill. Reading the fine print of your carrier's fraud-liability policy AT SIGN-UP is the cheap thing; doing it AFTER an incident is expensive.

Prevention going forward

See the hardening-public-pbx article for the systemic preventions. The shortlist:

• SIP source IP restrictions to carrier IPs only.
• Outbound destination allowlist (only countries you actually call).
• Daily spending caps at the carrier (most have this).
• fail2ban with aggressive thresholds.
• Strong extension passwords; rotate at suspicion of leak.
• Monitoring on outbound call volume — alert when an hour exceeds the daily average.