Investigating International Calls Fraud
Hello,
I’m investigating a situation where there was a hundreds of minutes of calls from an internal SIP extension to an 855 number in Cambodia, resulting in a crazy ($25,000+) bill from the phone company. I’m investigating, but can anyone provide some feedback on what’s happened here? I’m investigating how this happened as well as what types of arrangements can be made with the phone company (CenturyLink in Texas).
Some details:
* PBX is located in Texas
* Phone carrier is CenturyLink
* FreePBX distro running asterisk 1.8.14
* source SIP extension is Mitel 5212, firmware 08.00.00.04, default admin password (argh!). Phone is used by many different people.
More PBX setting details:
* inbound SIP traffic is not allowed through the firewall
* internal network is not accessed by many
* FreePBX web interface
*Questions I have at this moment:*
1) how were the calls placed? Was the Mitel SIP phone hacked somehow?
Asterisk PBX?
2) how does this typically get sorted out with the phone company? they are charging $6.25 per minute for the Texas to Cambodia calls. The phone system owners are at fault, but how have these situations worked out in the past?
I’ll be tightening things up, but any feedback is appreciated.
Thanks, Steve
13 thoughts on - Investigating International Calls Fraud
SeKAmXZlIHNlZW4gdGhlIGZvbGxvd2luZyBleHBsb2l0cyBvZiBBc3RlcmlzayAvIEZyZWVQQlgg Ym94ZXM6DQoNCg0KMSkgIERlZmF1bHQgUGxjbVNwSXAgdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGZv ciBQb2x5Y29tIHByb3Zpc2lvbmluZw0KDQoyKSAgSW5zZWN1cmUgU0lQIHVzZXJuYW1lcyBhbmQg c2VjcmV0cw0KDQozKSAgRnJlZVBCWCBHVUkgYWNjZXNzYWJsZSBmcm9tIHRoZSBpbnRlcm5ldA0K
DQo0KSAgT1MgcmVtb3RlIGV4cGxvaXQgKG1heWJlIHNzaC9zc2wgZXhwbG9pdCkNCg0KTWl0aWdh dGlvbiBvcHRpb25zOg0KDQoxKSAgRG9u4oCZdCB1c2UgYW4gZWFzeSB0byBndWVzcyBvciBkZWZh dWx0IHBhc3N3b3JkIG9uIHByb3Zpc2lvbmluZyBzZXJ2ZXJzLg0KDQoyKSAgVXNlIHNlY3VyZSBz ZWNyZXRzLiAgVXNlcnMgbmV2ZXIgZW50ZXIgdGhlIHNlY3JldCBzbyB3ZSB1c2UgYSAzMiBjaGFy IHJhbmRvbSBzdHJpbmcgb2YgY2hhcmFjdGVycyBmb3IgdGhlIHBhc3N3b3JkDQoNCjMpICBEb27i gJl0IGFsbG93IGNvbm5lY3Rpb25zIHRvIHBvcnQgODAgZnJvbSBvZmYtc2l0ZS4NCg0KNCkgIE1h a2Ugc3VyZSB5b3VyIE9TIGFuZCBTU0gvU1NMIGlzIHVwZGF0ZWQgcGFja2FnZXMgYXJlIHVwZGF0
ZWQuDQoNCkNvbnRhY3QgeW91ciBjYXJyaWVyIGFuZCBhc2sgYWJvdXQgYW55IHBvc3NpYmxlIGZy YXVkIGRldGVjdGlvbi4gICAgVmVyaXpvbiBTSVAgc2VydmljZSBoYXMgdGhhdCBmZWF0dXJlLiAg IEkgZG9u4oCZdCB0aGluayBMZXZlbCAzIGhhcy4gICBEb27igJl0IGtub3cgYWJvdXQgQ2VudHVy eUxpbmsuICAgSSBhbHNvIHJlY29tbWVuZCBsb2NraW5nIGRvd24gdGhlIHN5c3RlbSB2ZXJ5IHRp Z2h0IHdpdGggSVAgdGFibGVzIOKAkyBvbmx5IGFsbG93IHdoaXRlbGlzdGVkIHRyYWZmaWMgcmF0
aGVyIHRoYW4gb25seSBibG9ja2luZyBibGFja2xpc3RlZCB0cmFmZmljLg0KDQpGcmF1ZCBpcyBh IGNvbnN0YW50IGlzc3VlIGZvciBldmVyeW9uZS4NCg0KDQpGcm9tOiBhc3Rlcmlzay11c2Vycy1i b3VuY2VzQGxpc3RzLmRpZ2l1bS5jb20gW21haWx0bzphc3Rlcmlzay11c2Vycy1ib3VuY2VzQGxp c3RzLmRpZ2l1bS5jb21dIE9uIEJlaGFsZiBPZiBTdGV2ZW4gTWNDYW5uDQpTZW50OiBXZWRuZXNk YXksIEphbnVhcnkgMjgsIDIwMTUgNDowMyBQTQ0KVG86IGFzdGVyaXNrLXVzZXJzQGxpc3RzLmRp Z2l1bS5jb20NClN1YmplY3Q6IFthc3Rlcmlzay11c2Vyc10gSW52ZXN0aWdhdGluZyBpbnRlcm5h dGlvbmFsIGNhbGxzIGZyYXVkDQoNCkhlbGxvLA0KDQpJJ20gaW52ZXN0aWdhdGluZyBhIHNpdHVh dGlvbiB3aGVyZSB0aGVyZSB3YXMgYSBodW5kcmVkcyBvZiBtaW51dGVzIG9mIGNhbGxzIGZyb20g YW4gaW50ZXJuYWwgU0lQIGV4dGVuc2lvbiB0byBhbiA4NTUgbnVtYmVyIGluIENhbWJvZGlhLCBy ZXN1bHRpbmcgaW4gYSBjcmF6eSAoJDI1LDAwMCspIGJpbGwgZnJvbSB0aGUgcGhvbmUgY29tcGFu eS4gSSdtIGludmVzdGlnYXRpbmcsIGJ1dCBjYW4gYW55b25lIHByb3ZpZGUgc29tZSBmZWVkYmFj ayBvbiB3aGF0J3MgaGFwcGVuZWQgaGVyZT8gSSdtIGludmVzdGlnYXRpbmcgaG93IHRoaXMgaGFw cGVuZWQgYXMgd2VsbCBhcyB3aGF0IHR5cGVzIG9mIGFycmFuZ2VtZW50cyBjYW4gYmUgbWFkZSB3
aXRoIHRoZSBwaG9uZSBjb21wYW55IChDZW50dXJ5TGluayBpbiBUZXhhcykuDQoNClNvbWUgZGV0
YWlsczoNCiogUEJYIGlzIGxvY2F0ZWQgaW4gVGV4YXMNCiogUGhvbmUgY2FycmllciBpcyBDZW50
dXJ5TGluaw0KKiBGcmVlUEJYIGRpc3RybyBydW5uaW5nIGFzdGVyaXNrIDEuOC4xNA0KKiBzb3Vy Y2UgU0lQIGV4dGVuc2lvbiBpcyBNaXRlbCA1MjEyLCBmaXJtd2FyZSAwOC4wMC4wMC4wNCwgZGVm YXVsdCBhZG1pbiBwYXNzd29yZCAoYXJnaCEpLiBQaG9uZSBpcyB1c2VkIGJ5IG1hbnkgZGlmZmVy ZW50IHBlb3BsZS4NCg0KTW9yZSBQQlggc2V0dGluZyBkZXRhaWxzOg0KKiBpbmJvdW5kIFNJUCB0
cmFmZmljIGlzIG5vdCBhbGxvd2VkIHRocm91Z2ggdGhlIGZpcmV3YWxsDQoqIGludGVybmFsIG5l dHdvcmsgaXMgbm90IGFjY2Vzc2VkIGJ5IG1hbnkNCiogRnJlZVBCWCB3ZWIgaW50ZXJmYWNlDQoN
ClF1ZXN0aW9ucyBJIGhhdmUgYXQgdGhpcyBtb21lbnQ6DQoxKSBob3cgd2VyZSB0aGUgY2FsbHMg cGxhY2VkPyBXYXMgdGhlIE1pdGVsIFNJUCBwaG9uZSBoYWNrZWQgc29tZWhvdz8gQXN0ZXJpc2sg UEJYPw0KMikgaG93IGRvZXMgdGhpcyB0eXBpY2FsbHkgZ2V0IHNvcnRlZCBvdXQgd2l0aCB0aGUg cGhvbmUgY29tcGFueT8gdGhleSBhcmUgY2hhcmdpbmcgJDYuMjUgcGVyIG1pbnV0ZSBmb3IgdGhl IFRleGFzIHRvIENhbWJvZGlhIGNhbGxzLiBUaGUgcGhvbmUgc3lzdGVtIG93bmVycyBhcmUgYXQg ZmF1bHQsIGJ1dCBob3cgaGF2ZSB0aGVzZSBzaXR1YXRpb25zIHdvcmtlZCBvdXQgaW4gdGhlIHBh c3Q/DQoNCkknbGwgYmUgdGlnaHRlbmluZyB0aGluZ3MgdXAsIGJ1dCBhbnkgZmVlZGJhY2sgaXMg YXBwcmVjaWF0ZWQuDQoNClRoYW5rcywNClN0ZXZlDQoNCg=
You don’t mention if the phone is remote, or local. Although you do mention it had a default user/pass. If the UI of the phone was/is accessible from the I’net, the GUI does have the ability to place a call from it, that is one way the calls could have been placed.
From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Steven McCann Sent: Wednesday, January 28, 2015 4:03 PM
To: asterisk-users@lists.digium.com Subject: [asterisk-users] Investigating international calls fraud
Hello,
I’m investigating a situation where there was a hundreds of minutes of calls from an internal SIP extension to an 855 number in Cambodia, resulting in a crazy ($25,000+) bill from the phone company. I’m investigating, but can anyone provide some feedback on what’s happened here? I’m investigating how this happened as well as what types of arrangements can be made with the phone company (CenturyLink in Texas).
Some details:
* PBX is located in Texas
* Phone carrier is CenturyLink
* FreePBX distro running asterisk 1.8.14
* source SIP extension is Mitel 5212, firmware 08.00.00.04, default admin password (argh!). Phone is used by many different people.
More PBX setting details:
* inbound SIP traffic is not allowed through the firewall
* internal network is not accessed by many
* FreePBX web interface
Questions I have at this moment:
1) how were the calls placed? Was the Mitel SIP phone hacked somehow? Asterisk PBX?
2) how does this typically get sorted out with the phone company? they are charging $6.25 per minute for the Texas to Cambodia calls. The phone system owners are at fault, but how have these situations worked out in the past?
I’ll be tightening things up, but any feedback is appreciated.
Thanks, Steve
The UI (or anything really) is not open to the internet. The only things open are SSH and RDP (on alternate ports). The freepbx web interface has a strong username/password. The only weakness I see is a weak secret SIP
password, and default mitel admin password used. There is no provisioning server for the Mitel phones right now.
The phone system is on the same subnet/VLAN as the internal network. My guess is some internal computer has a trojan which allowed attackers to do some internal configuration changes. I don’t yet know how they launched an outbound call from the internal extension.
Le 28/01/2015 22:03, Steven McCann a
Do you have DISA setup? We’re seeing lots of attackers running scripts that send digits until they strike a DISA, misconfigured mailbox, etc. (Assuming it wasn’t a stupid employee forwarding an inbound call to a 9xxxxxxx number etc).
Have a look at SecAst (www.generationd.com) – it detects callers sending too many digits, monitors digit dialing speeds, etc. to help identify and block these types of attacks. The free version is better than nothing (but if you’ve already suffered one $25k attack then you probably don’t mind spending a bit of money). Or have a look at http://www.voip-info.org/wiki/view/Asterisk+security for other ideas.
There were some (at least one) critical FreePBX weaknesses discovered this summer (you’ll find them if you google). Even if you don’t expose the management interface to the internet, don’t trust FreePBX security alone.
-MD-
My opinions expressed are my own and do not necessarily reflect those of my employer. However, as an employee of Generation D Systems my opinions are probably biased.
Hi Michelle,
DISA is not in use. I’ll check out the SecAst product you mentioned for rebuilding the server.
I’m digging into the logs to get some more information.
Thanks, Steve
Are you sure the calls weren’t actually made internally? Can you see anything to suggest the ip or mac address of the phone changed? Because for someone to take advantage of the calls (assuming they don’t get cash out of ringing Cambodia) they needed to proxy through to that phone line, which maybe required them leaving some sort of device on the network. Otherwise I am guessing they got onto your PBX somehow.
As suggested logs are important, including DHCP, syslog to see if anything unusual happened.
Did the calls run all day or just at night when no one was around?
Was there more than one call up at a time? (how many calls does the Mitel phone support?)
How long were the calls? Were they varying lengths (more human like) and did they just redial as soon as they were dropped? Or were they automated to trigger as much cost as possible e.g. if the 1st minute is the most expensive then you get a lot of short calls.
Good luck
—
Hmm the calls are made during the day (and sometimes very early in the morning). Right now it looks like someone actually made these calls. If that is the case it’s somewhat comforting to know the system wasn’t compromised. However, the $25,000 phone bill still remains. Yikes. $6.25
per minute to Cambodia seems quite steep to me.
Since the Mitel had a default admin password, it seems possible that somebody accessed its UI over the network, and then accessed and copied its SIP credentials for your Asterisk server.
If that’s the case, the calls might not have been placed through the phone. The miscreant could have configured the purloined credentials into another hardphone, or a softphone app on any PC or tablet or cellphone which was able to access your LAN. The “cloned” phone would not have needed to actually register with Asterisk… it could simply have send an INVITE to place a call, and Asterisk would have challenged it and then accepted the credentials.
If your CDR log shows IP addresses for each call, you might be able to compare these with your DHCP (or whatever) IP registration service, and see if the calls actually came through the phone or not. If not you might be able to identify the device which initiated the calls.
The bad news is, I suspect that you’re probably “on the hook” for the cost of the calls. In the case of an “inside job” it’s often hard to legitimately “disavow” the charges. You may have to pay the bill and then (if you can identify whomever placed the unauthorized calls) attempt to recover the cost from him/her in court. This sort of misused by an insider might be
“theft by conversion”.
The 25000$ @6.25/min means 4000 minutes of calls (or 66H)
Not sure in how many days this has accumulated but i seriously dought this is made from a human accessing the phone. The fact that you get the calls at certain times might have to do with the timezone the calls are going
If you phone has an API (most have) and allows for calls to be made, or the web interface allows calls to be placed from there, and there is no password or the default credentials then this is how the calls are made. Check the call velocity (number of calls per minute) from that phone and if you see multiple calls at the same time frame then its probably not a (single) human doing it but some dialler.
We start seen this way more often than before. i.e using the phone as an attack surface instead of breaking into to pbx. Also there seem to be a lot of javascript “cross-site” scripting attacks on the loose that target voip networks from the inside. I.e using the browser to execute attacks from inside of a secure/firewalled network.
Stelios Koroneos
Jabber : stelios@soldecom.com
—
It’s very unlikely that this was an employee calling Mom for 66 hours (I’m assuming these calls appeared on a single bill). It’s also unlikely that someone “inside” would benefit financially from making these calls. (Follow the money!) Don’t discount the possibility that you’ve overlooked something in the firewall.
Meanwhile, does the client need to do international calling? If not, they may request that international calls be blocked by the carrier; once blocked, any international calls are the carrier’s responsibility, not the client’s.
–Don
—–Original Message—
Did you have a look at the phone it self already?
Is call forwarding activated or something and can you call the phone/extension from externally?
I have seen this in the past where an employee enabled call forwarding on the phone and once at home he or family called the phone which forwarded the call to abroad.
Good luck. Michel.
Op 29-01-15 om 12:51 schreef dk@donkelly.biz:
If you have not done so contact the carrier immediately. Report the fraud. Have them disable international on the account until you have your security issues addressed. Ask them to pull call logs containing Source and destination IP address. for the fraud calls. If you are sure they came from your systems IP address then verify the systems does not have any unauthorized registered endpoints. Verify the source and destination of the calls from any internal logs.
If the calls came from your IP then you are likely on the hook for the calls. If they came from another IP that you don’t own then if you can prove you had no access to that IP than there is some hope the carrier may work with you.
Thanks
Bryant