Hacked extension checklist

1) [via the cli] On all PBX nodes (node001 and node002), run the call count script to see has an abnormally high amount of calls active.   Scammers treat a compromised extension as a sip trunk so you’ll see one extension having 50 +/- calls up.  By comparison, our heavy use customers generally only have 20-30 tops (asheville womens)

Here’s what a normal day might look like:

# sudo /rfbin/ringfree-showcallcount 
1900056  fourseasonscfl-001.ringfree.biz     10 active calls

Here’s what a hacked extension on fourseasonscfl would look like:

# sudo /rfbin/ringfree-showcallcount 
1900056  fourseasonscfl-001.ringfree.biz     64 active calls

2) [via the web gui] Log into that PBX’s pbxadmin interface.  Go to the cdr and identify which extension has been hacked.  It will be immediately apparent as you’ll see the same extension making calls within seconds of each other.

3) [via the web gui] Change the SIP secret for the hacked extension.  Submit and Apply Changes.

4) [via Sansay] You have a good two minute period where call sessions and the hacked extension’s registration will still be shown in the Sansay.  Go to Monitoring > Subscriber Stats.  Filter by PBX hostname.  Generally single office companies will all be coming from the same Source IP.  Make a note of all registration Source IPs for the hacked extension.  If there are many extensions you can further filter by extension.

5) [upstream provider] Hacked extensions can drain balances very quickly which will halt traffic until it’s paid.  If you do not have access to the upstream carrier, find David, John or Molly.  It is imperative that the outbound carrier isn’t shut off for long due to a fraud alert suspension.

6) [determine attack vector by accessing customer’s router and calling customer] Next is to determine attack vector.  The most common method used to compromise extensions is by exploiting the extension’s SIP endpoint.  This occurs by someone gaining access and identifying the endpoint’s web configuration interface during an automated scan.  If you’ve ever opened up a port to access a customer’s web interface on their Polycom, you are opening them up to this form of attack which is why you should always remove the port forward when done (or preferably, use a screen sharing application to access the phone without opening it up to the web).

Less commonly, but what occurred on Monday, is a phone that has been hooked up directly to the internet via a modem where in most topologies you would usually place a router with a firewall.  This presents the phone’s easily compromised web interface directly to the internet where it will be exploited and credentials stolen.

7) [on p.ringfree.biz] grep the hacked extension’s Source IP that was not shared from all available /var/log/xferlog* files.  It is important to verify that the ftp server wasn’t compromised.  If you see that the hacker’s ip has access the ftp server, and you’re sure the IP you’re searching for did not originate from a customer’s office or location, turn off the ftp service until it can be further analyzed.  Do not do this unless you get a match.  It’s not a common attack vector and has occurred only once with an ftp account whose username and password was set up in matching numerics only.

[root@ppt / ]# service vsftpd stop

8) [with the customer] Bringing the phone back online should not be done until a) the SIP secret has been changed, b) port forwards to that phone’s registration were check to be disabled and c) the phone has been verified not to be registering over the internet without a firewall in place.

The majority of this can be done within 5 minutes within first notification of account suspension.