Understanding VoIP Hackers
Ever since I realized how easy it was to detect potential VoIP fraudsters using the SIP User Agent header , I got more and more interested in finding out how to detect them and more importantly figuring out their thought process. I believe that there is a lot you can learn from looking at the smart techniques fraudsters are using rather than just assuming what they are up to.
How best to learn, apart from looking through your logs after you have been hacked, than to create a honeypot, gather data and learn from it.
Questions
The questions I wanted to answer were:
- SIP User Agent detection is a simple blocking mechanism, how creative are fraudsters getting?
- How aggressive do fraudsters get? Are they working around rate limiters?
- Which cloud service is mostly used by fraudsters?
- Fraudsters call a number they own in order to confirm hack success. What regional numbers are mostly called?
- Are there any creative SIP method types being used?
Honeypots
Initial Assumptions
I started by assuming the following…
- Some fraudsters might stick to specific countries - Solution: Have honeypots in different regions
- Frausters might tag an IP as a honeypot and never come back - Solution: Keep rotating server IPs
- Fingerprinting a honeypot is easy - Solution: Keep changing honeypot signaling behaviour.
Deployment
The configurability and flexibility of the Open Source SIP server Kamailio made it the obvious choice for the honeypot SIP server application. So I set off dockerizing my honeypot application and deploying it globally using Terraform. All 7 of them reported back to a centralized API server written in Golang that stored the data in MariaDB. Before sharing the data, I would like to discuss my findings as of the time of writing this post.
Answers
User Agent
The SIP User Agent has historically been a quick way of filtering out fraudsters because almost all of them used the famous sipvicious toolset that had ‘friendly-scanner’ as the SIP User Agent. My assumption was that just blocking out ‘friendly-scanner’ was no longer a reliable method because it is very easily changed. Strangely enough, I did not find that to be entirely true. Although fraudsters are now pretending to be popular desk and softphone clients like ‘Avaya IP Phone 1120E’, ‘Avaya one-X Deskphone’ and ‘Grandstream GXP1200 1.2.3.5’, at the time of writing, ‘friendly-scanner’ always ranked amongst the top 3 User Agents used.
💡 Although using the User Agent can be useful, it is just a game of ‘whack a mole’.
Aggressiveness
One parameter I am storing in the database is the time difference (time_diff) in seconds between requests from an IP address so I can observe any pattern in the rate of requests being sent.
I noticed that generally fraudsters gradually crank up their attacks in an attempt to detect rate limiters. Below are examples from 3 different IP addresses showing the time difference between requests and the number of requests sent.
+-----------+----------+ +-----------+----------+ +-----------+----------+
| time_diff | count(*) | | time_diff | count(*) | | time_diff | count(*) |
+-----------+----------+ +-----------+----------+ +-----------+----------+
| 0 | 3441 | | 0 | 1072640 | | 0 | 36398 |
| 1 | 425 | | 1 | 254950 | | 1 | 8729 |
| 2 | 5 | | 2 | 60 | | 2 | 43 |
| 3 | 5 | | 3 | 9 | | 3 | 14 |
| 4 | 1 | | 4 | 6 | | 4 | 6 |
| 5 | 3 | | 8 | 1 | | 5 | 7 |
| 6 | 1 | | 10 | 2 | | 6 | 1 |
| 7 | 4 | | 11 | 5 | | 7 | 3 |
| 8 | 3 | | 15 | 18 | | 8 | 1 |
| 9 | 4 | | 16 | 4 | | 213 | 1 |
| 10 | 4 | | 67 | 1 | | 3298 | 1 |
| 11 | 2 | | 207 | 1 | | 3388 | 1 |
| 12 | 2 | +-----------+----------+ | 3430 | 1 |
| 14 | 2 | | 3448 | 1 |
| 15 | 3 | | 3473 | 1 |
| 17 | 2 | | 3493 | 1 |
| 18 | 2 | | 3563 | 1 |
| ... | . | +-----------+----------+
| ... | . |
| 999 | 1 |
+-----------+----------+
When they notice an absence of a rate limiter on the server, they release the brakes and hit it hard.
💡 This shows that fraudsters are aware of rate limiters and are equipped to work around them.
IP Address
This is always a sensitive topic because it usually ends with finger pointing. Luckily I am providing live data publicly (link below) so anyone can check and make their own conclusion at any time. Based on over 2 months of observing this data I can say that, yes, some of the IP addresses are owned by some of the popular cloud service providers but generally the source IP addresses of the heavy hitters are from smaller cloud service providers. I actually got to know quite a few companies from tracing the IP addresses 😄
Feel free to look at the data (link below) and comment or contact me if you find anything interesting.
Calling Number
Back in the day tricking the fraudsters meant routing the call locally and playing either a ringback tone or an announcement to make the fraudsters think they have a connection. Well this no longer works. Fraudsters now own the numbers they are dialing so that they can confirm that the call actually went through. The numbers dialled are countries like the US, UK, Sweden, Israel, Slovakia. Destinations that would not generally be on your block list. Interestingly, Googling one of the top dialled numbers at the time of writing, gave a result dating back to July 2019, to a post in the freePBX community forum where the owner of the number abused the trust of the community by seeking help for the setup of his platform.
💡 Using access codes for outbound calling should also be avoided because fraudsters are up to that as well. It is interesting seeing all the creative codes being used when making call attempts. All combinations of symbols (*,^,-,_,.,$,#) and numbers are used to prefix the outbound calls.
Methods
SIP OPTIONS are generally used for the initial scanning to confirm the existence of a SIP device before SIP REGISTER or INVITE attempts are made. REGISTER is still by far the biggest request type being made because of the use of brute force to compromise accounts/extensions. If credentials in the backend are pulled using an API, LDAP or database lookups, having such a high volume could impact the performance of small PBXs. I am currently not doing any password analysis or am I attempting to regenerate the rainbow tables being used for the registration attempts.
💡 Although I noticed some ACKs and CANCELs, I was not able to find any interesting attack vectors being used by these methods.
My Thoughts
Unless you are a know company or online service specifically targeted by fraudsters, most SIP services are detected by scanning IP addresses on the public internet primarily using OPTIONS pings and then, on detecting a SIP server, they switch to either REGISTER or INVITE and gradually increase the rate of their requests in an attempt to stay undetected by rate limiters.
Although there are various ways of detecting and blocking the source IPs, I believe the best method of mitigation is to go undetected. That might be difficult if you are for example allowing your employees working from home to connect to your company’s PBX. However, with the Open Source project APIBAN started by LOD, this is no longer the case. The idea behind the project is simple, the IP addresses of fraudsters are collected from globally deployed honeypots and are made available through an API. To simplify the process even further, there are clients, provided by the same project, that can automate the process for you and update your linux server iptables firewall. There are also ways to integrate with other SIP/VoIP servers like Kamailio and Drachtio. There is even talk about integration with Cisco devices ( you did not hear this here 😉 )
I have been a long time supporter of the project by building and deploying honeypots and, yes, the set of honeypots gathering the publicly available statistics I am providing are also feeding data into APIBAN so if you are already using the free service then you are protected from these IP addresses as well.
Other methods of blocking IP addresses is by fronting your PBX with a SIP server like Kamailio and putting in some blocking or rate limiting logic. Also another popular option is to use Fail2ban or similar software, to scan log files and update firewall rules to block IP addresses with multiple failed authentication attempts. By using these methods, you would have however already made your presence known so your defence would be relying on things like your authentication methods, rate-limiting, auto banning on failed attempts, bandwidth and CPU power.
I have been able to provide myself answers to the questions I initially had, but with the constant data coming in, this is going to be an ongoing research.
Access to Honeypot Data
The data being gathered by the honeypots can be seen here or in the link on the top menu bar of the blog. It is currently being summarized into 5 groups. Source IPs, User agent, Method, Number and a world heat map showing where attacks are currently coming from. All data apart from the world heat map is limited to the top 15 values. The data is updated every hour and is summarized into the past hour, 24 hours, 7 days and 30 days. If there is any interest in showing more data than the top 15, I can easily change that.
I hope this data is somehow useful to others as well.
