A Mobile Operator Fraud case study but it could apply to any type of network
In this article this week’s guest editor Manuel Basilavecchia of Netaxis describes a mobile operator fraud – in other words a telecom fraud that impacted a mobile operator. He describes the type of traffic pattern (destinations) and fraudster behaviour. For obvious reasons we are keeping the name of the operator out of it. It could happen to anyone dropping their guard.
The mobile operator in question underwent some planned maintenance work on its network. Few details are available on the nature of the planned work but from a security point of view the activity was a total failure as the following day their switch was accessed from outside their network. We may assume that the planned work cleared the access list on the SBC/firewall.
Once the fraudster had access to the switch, he initiated some test calls. The goal was to check if it was possible to terminate traffic to specific destinations. To avoid detection the tests calls were kept to a low volume.
It is important to note that the hijack and the test phase took place on weekdays. On the Friday evening, fraudster rolled up his sleeves and got on with the real work of sending volume traffic to several destinations.
The traffic pattern was as follows:
- Fake CLI’s used like 1001111,1000001,123456; etc
- Massive calls to Latvia, Lithuania, Moldova, Gambia etc….
- Big volumes generated per CLI
The fraud was detected the next day in the morning by a service provider of the mobile operator. The time elapsed between the beginning of the fraud and the detection allowed the fraudster to generate quite high volumes.
As it was a week-end it was difficult for the SP to get in touch with the mobile operator to inform him about the ongoing fraud and to align on measure that needs to be taken. Again here, few hours lost which benefits the fraudster……
Once the decision to block fraudulent traffic has been taken a game of cat and mouse started. Indeed, when the fraudster identified that a destination was not generating revenues due to barring implemented, he immediately and simply switched to targeting another country. The same principle applied for CLI’s. Any time he noticed that a CLI was blocked he just moved on to another. This game lasted the entire day.
On day two, a major change in the destinations targeted was seen: Nauru, Senegal, Maldives Zimbabwe was now part of the fraud scheme.
Again, barring had to be implemented on the targeted destinations. It is important to note that the barring had to be implemented so as to stop fraudulent traffic but without impacting the legitimate traffic
In parallel, the mobile operator attempted to solve the security breach which took some time. Once the issue solved on the SBC, fraudulent traffic finally stopped.
Lessons learnt:
Security is key to protect a network and in the case where a modification is made to a SBC, a cross check needs to take place after the intervention
Based on the short time between the planned work and the hacking it is clear that networks are scanned by fraudster to find an open door.
Fraud monitoring needs to be made live or near real time to minimize the impact and this 24 x 7
Barring solution must be available to stop fraud. This barring solution needs to be flexible (A number, B number, range, destination).
This is telecom fraud week on trefor.net, edited by Manuel Basilavecchia of Netaxis. Read our other fraud posts this week:
Colin Duffy on “is encryption the answer to data loss”
Manuel Basilaveccia on Missing Trader VAT Fraud
Dave Dadds – “telecom fraud is industry’s problem not the customer’s“