The other day one of our key customer logged a priority incident with regards to a Toll Fraud. Their Carrier alerted them for possible malicious calls originating from their main ISDN number going to The Bahamas. At First I thought this has something to do with their Expressways so I checked Call logs and Events to find out if anything originated from Exp-E and then reached Gateway via CUCM. Customer did provide us the Called number so I went through the call history of Expressways but could not see any abnormal activity.
Customer was not provided the time the malicious activity started so it was left on us to track the activity and also find out the breach. I decided to jump onto RTMT and check call activity starting midnight from Real Time Data. It didn’t took me long to find a particular calling number appearing repeatedly in wee hours when people don’t call that often. I then traced back to the first call and found that the attacker actually called an Internal number and then the call was disconnected. Immediately after that the same calling number called that internal number but this time call was going out to a fraudulent number in The Bahamas 96492396493.
At this point I had an idea as to what went wrong!
The way this works is that a caller/hacker calls to a PSTN number of your organization. The call goes to the user and then on no response goes to voicemail (typical setup). While as a caller you are listening to voicemail, you can enter _ to get into set of options. Unity system then asks to enter your ID followed by #. This is normally used where a caller is calling his own mailbox from outside but can be used by a hacker. The hacker must know how your internal DN structure looks like and the voicemail pin. Once the hacker enters the DN and the pin correctly you are now in user mailbox and will be provided with a menu starting from changing pins and greetings to call forwarding. Hacker can easily enter a malicious number as a call forward and then when the user’s number will be called, the call will be forwarded to the fraudulent number and this is exactly what happened in our case.
The user pin was a trivial 12345 and the hacker either guessed the internal DN structure right or he had some idea of how it is all configured.
But as we all know Unity system do have a restriction table to avoid this kind of toll fraud so why it didn’t work in this case?
Well, this is because the rules which were setup did not stop a number starting with 9 and followed by 10 digits. There was a rule with 9 followed by 11 digits but not 9 and 10 digits which allows National calls. The other issue which the customer had in their configuration was that the voicemail CSS had access to National Route pattern 9.[2-9]XX[2-9]XXXXXX. The number went to gateway as 6492396493 and Carrier treated it as an International call because of 649 (Turks and Caicos Island).
Few important points to consider to avoid Unity toll Fraud:
- Do not allow Trivial pins
- Restriction tables must restrict all combinations
- Do not give Unity CSS access to outbound pattern unless necessary
