Massive SIP Attacks with VPN?

The picture

I like to keep an eye on the hourly data statistics of my honeypots just to see if anything interesting pops up. A couple of weeks back I saw something that I just had to take a screenshot of

It screamed automation. I quickly tried to see if it was another round of traffic similar to the proxy relay traffic that happened some time back …… It wasn’t, so I didn’t make too much of it. After all I had too much on my plate at the time.

Call out

It wasn’t until Fred Posner sent out the following tweet that I decided to take a closer look as soon as I had a bit more time.

Looks like most of these are REGISTER attacks… @kwancro may have more info sometime as he’s really good at that ;)

Always a good time to use https://t.co/MUIqeXN5Yd (free thanks to our sponsors). https://t.co/XxITXuXVig

— Fred Posner (@fredposner) August 31, 2022

After all, he did call me out in the tweet :)

Second pass

When I finally carved out some free time to look deeper into this, the brief information I had from Fred’s tweet updates and the hourly honeypot statistics indicating low traffic from multiple IP addresses, I was intrigued because I knew I would be investigating traffic from a level 3 hacker. “Who is a level 3 hacker ?” you ask.

Over time I have come to generally put VOIP hackers into 3 levels:

• Level 1 - Script kiddies: Those who have come across some scripts, do not understand how SIP works and are playing around.
• Level 2 - Wannabies: Those who have played with scripts for a while, think they know what they are doing and start flooding VOIP servers with useless traffic. I just block them for a couple of days so as not to fill up my database with worthless data. Those in this category that have been at it for longer periods have some standard techniques that have worked for them in the past so just keep repeating these techniques with slight changes (attack rate, time of day etc).
• Level 3 - Advanced Learners/Pros: Those that know how SIP works and are building smart tools around SIP. After testing in their labs they use the internet to test how they can scale. They do not send out a lot of traffic. I like coming across their traffic because it helps me learn about their thought process. After they perfect their tools, they disappear only to later appear at their target’s doorstep where they cause damage.

Under the ‘Source IPs’ tab of the hourly honeypot statistic I found examples of multiple source IP addresses with a similar small number of packets(requests). Then a quick glance at the ‘User agent used’ tab showed not only some of the known User-Agents from the usual scanners but a new one 'PolycomSoundPointIP SPIP_550 UA 3.3.2.0413', with a count that could match the multiple IP counts I was seeing. Armed with this 2 data points I queried data in the honeypot backend database. I immediately saw patterns in the packets. An example packet is:

REGISTER sip:X.X.X.X:5060 SIP/2.0
To: <sip:240@X.X.X.X>
From: <sip:240@X.X.X.X>;tag=e5f4a2962531e4f7a240
Via: SIP/2.0/UDP 10.2.2.198:57448;branch=z9hG4bK-d87543-360230173240-1--d87543-;rport
Call-ID: e5f4a296253190e4f7a240
CSeq: 1 REGISTER
Contact: <sip:240@10.2.2.198:57448>
Expires: 3600
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: PolycomSoundPointIP SPIP_550 UA 3.3.2.0413
Content-Length: 0

Notes on findings

As with all automated tools, there is generally a pattern. My findings were:

1. The SIP method used was only REGISTER.
2. One registration attempt was made per extension.
3. The SIP User-Agent used is PolycomSoundPointIP SPIP_550 UA 3.3.2.0413.
4. The last digits of the Call-ID and From tags always match the extension being registered.
5. The IP addresses in the Via header and Contact headers are private IP addresses, indicating no dedicated edge device (more on that later).
6. A new public IP address was used to scan each range of 100 extensions. For example one IP address would be used for the range 2200 - 2299, another for 3500-3599 etc.
7. The extension range scanned across all honeypots at the time of writing was 11 - 4999.
8. Each source public IP had only one matching SIP Contact header IP address (indicating no sharing of public IPs by nodes).
9. Requests are sent generally every 92s but sometimes come in after 184 or 276s (multiples of 92).
10. The source IP range is increasing by the day, over 4300 at the time of writing.
11. The IP addresses used are owned by VPN services.

Initial thoughts

After digging a bit deeper into some of the observations, looking further for answers and patterns I came to the conclusion that:

1. This was obviously an automated process and not stray devices on the internet.
2. The traffic rate and constant use of the same User-Agent to me means that in this case the hacker is more concerned about the automation of the process rather than trying to break into a system undetected. This assumption is further confirmed by the fact that one REGISTER request is sent per extension.
3. Using a VPN and a private IP address is a smart move as it does not expose your public address if you have one, although it could expose your internal network design.

Going deeper

One interesting thing about SIP routing is that the routing information is in the SIP headers. If you have an interconnect with a third party, your internal SIP routing structure can be visible to them. That is the main reason why IT security experts always insist on having an edge device that can conceal the internal IPs within the SIP headers. This edge device is usually a Back-to-back user agent (B2BUA) like Freeswitch, Asterisk or a proxy like Kamailio with one of its topology hiding modules (TOPOH or TOPOS) enabled. In this case since we can see the internal IP of the attacking node, I decided to see if there was a story there as well.

I queried the Contact header IPs to see what pattern I could find and I noticed ..

+-------------+
| contact_ip  |
+-------------+
| 10.0.0.4    |
| 10.1.0.4    |
| 10.2.0.4    |
... 
| 10.2.2.3    |
...
| 10.2.6.60   |
...
| 10.2.10.10  |
...
| 10.2.14.111 |
... 
| 10.2.18.104 |
...
|10.2.22.138  |
...
| 10.4.0.150  |
...

They were nicely created subnets, not like the default ranges given by cloud service providers. Excluding the odd ones, they were generally in the subnet 10.2.0.0/16. That meant that the hacker had a network infrastructure built within their cloud provider. This by itself is not unusual when building a dedicated network or infrastructure for a service. But why would such a dedicated subnet structure be required in this case? Let’s see what each subnet does. Since I previously noticed that each private IP in the SIP Contact header was generally associated with one public IP, I decided to see if they were somehow region specific.

Querying the mysql database for the subnet range ‘10.2.30.%’ I got

+--------------+
| country_code |
+--------------+
| ES           |
| MH           |
| BH           |
+--------------+

What about ‘10.2.34.%’ ?

+--------------+
| country_code |
+--------------+
| MV           |
| IN           |
| FI           |
+--------------+

How about I query per country code, say Ireland (IE)?

+------------+
| contact_ip |
+------------+
| 10.2.2.81  |
| 10.2.2.144 |
| 10.2.2.10  |
| 10.2.2.201 |
| 10.2.2.214 |
| 10.2.2.89  |
....

Oooh subnet 10.2.2.0/24! Each subnet is dedicated to use a specific range of VPN gateways. Interesting!!

Final thoughts

I suspect the hacker behind this traffic is just sharpening their tools/skills. They have built a nice automated infrastructure to create nodes, leverage a VPN service to send traffic through, scan a specific extension range, wipe out the node and repeat the process. This type of automation and scale is nothing new but it is very interesting to see it at work in it’s infancy and understand the build, the idea and its capability to scale. With this they can and are (at the time of writing) gradually increasing their active nodes and obviously tweeking their tools.

Is it an annoyance especially to the RTC community?

YES!!

But as usual, I admire the craftmanship.