Using BGP data to find Spammers

It’s long been assumed that Spammers use a technique called IP squatting to get around IP reputation lists and to make it harder to find the real source of the spammers. In this blog we’ll take a closer look at Spam operations and their techniques. IP Squatting We’ve all read the reports about IPv4 running out of free address space and while that is certainly true there’s still a lot of address space that has been allocated but is not actually routed on the Internet today. A significant portion of that space are prefixes that were allocated a long time ago and folks are no longer using these allocations, forgot about it or have other reasons to not use their IP address space on the Internet. IP squatters look for space that hasn’t been routed for a while and will claim ownership of the space. This can then be used for things such as Spamming. There is vast range address space that is not currently announced on the Internet and it is not uncommon for IP squatters to cycle through this space using one or more prefixes at a time for a brief period. Below we’ll expose two actual Spam operations that used this technique. Case #1 Russian spam One of the techniques to find IP squatters is by looking at the networks that consistently announce new address space. Using this method we find a few Russian networks that show up in the top 10 and all are somehow related. One example is AS43239 SpetsEnergo Ltd which was also subject of some discussion on Nanog recently. As part of that discussion it became clear that this space was not in use by the actual owner and was now listed on spamcop, indicating that it had been used for sending Spam. Using BGPmon.net data we generated a report that shows all short lived announcements by AS43239. We’ve shared the complete list here for your reference: Looking at the Autonomous Systems involved, this operation seems to be running out of Russia. Another interesting observation is that most of the new announcements start at ~5am UTC, which is 9AM Moscow time. “So John, how was your weekend?” “Hold on, let me launch this campaign first” When we look at the details we note that the AS paths have the following pattern in common: It started with:

57756 57792 43239

Then

39792 57756 43239

Later:

44050 57756 43239

This shows us that 43239, 57756 and 57792 are all somehow related. Using our data we ran the same report for both 57756 and 57792. AS57756 follows the same pattern but only with one prefix. AS57756 announced 103.24.140.0/22 (allocated to a network in New Zealand) for 20 minutes in June. If we look at AS57792 we see the same pattern again but for over 200 prefixes between September 2013 and february 2014. In this case it’s again all mainly space that’s allocated to a variety of organisations globally but not currently routed. In all cases the duration is several hours to a few days. Another russian based Autonomous system that has been used by most likely the same organization is AS197329 (Rusnak Vasil Viktorvich). As of July 2014 this AS originated about 200 new prefixes for several hours each. Just as SpetsEnergo, AS197329 relies solely on AS57756 for upstream connectivity. Case #2 Playing the Internet Route Registries (IRR) While looking at the data for short lived BGP announcements, one of the Autonomous Systems quickly caught our attention as it announced approximately 1,000 new prefixes in the last few weeks all for a short duration, typically less than a day. After being absent from the routing table since January 2011 AS15078 Telelatina made its return to the global routing table in the spring of 2014. The graph below nicely shows the unique pattern. First we note the number of new prefixes announced every day is typically 8 each interval. Secondly the lifetime of each of these events is roughly the same, each prefix appears and disappears at the exact same time, they last for a few hours and is followed by a new sequence of events, with 8 new prefixes. If we look at the prefixes that are being announced by AS15078 we see that it is announcing unused IP address space from a variety of organisations. When we look at how AS15078 connects to the Internet we see that it relies solely on Hibernia AS5580 for IP Transit connectivity. Hibernia uses strict IRR-based filtering on all of it’s customer-facing BGP sessions. With that in mind, how then is it possible that AS15078 is able to announce routes that are obviously not allocated to them? The only reason this could work is if they were able to create valid route objects. Internet Route Registry and RADB Internet Route Registries (IRRs) are used to document routing policies and allow providers to automatically create filters based on the route objects in these databases. The IRR setup is a great help in automating BGP filter management but it is also far from perfect. First of all, the data contained in IRR can be of very low quality, and secondly: one of the most popular databases allows you to register arbitrary route objects without any authorization. In this case AS15078 Telelatina, registered a route objects for all of its announcements in RADB. An example can be found below. $ whois -h whois.radb.net 192.243.38.0/24 route: 192.243.38.0/24 descr: route object origin: AS15078 mnt-by: MAINT-AS262916 changed: omarsotres@intermatsa.com.mx 20140823 #23:21:13Z source: RADB RADB and several other IRR databases allow any user to create any route object for any prefix. Given the wide usage of RADB and is recognition as an authoritative source for IRR data, it is the ideal place for adversaries to register route objects. Now that there is a valid route objects in RADB, Hibernia AS5580 will use these during automatic generation of their BGP filters. This highlights an interesting scenario: The origin has created a valid route object and its provider follows best current practices and accepts the announcement. This is exactly how things are supposed to work today. The problem here is that AS15078 Telelatina was able to register all these route objects without any restrictions since there’s no link between authorisation to create route objects and and actually owning a resource in RADB. The RIPE database for example does have this functionality and does not allow users to create route objects for prefixes that are not allocated or assigned to the user. It’s not all bad though, we can use the data in the route objects to our advantage and use it as a tool to further find related incidents. Looking at the route object above we can see it was added on August 23rd, by user (Maintainer) MAINT-AS262916 with email address marsotres@intermatsa.com.mx. A few days later on August 27th, the prefix for that route object started to make its appearance for about 10 hours, before it disappeared. Using the RADB database we can find out more information regarding MAINT-AS262916.

$ whois -h whois.radb.net MAINT-AS262916
mntner:     MAINT-AS262916
descr:      TV de Uruapan, S.A
admin-c:    Omar Orozco
tech-c:     Omar Orozco
upd-to:     omarsotres@intermatsa.com.mx
mnt-nfy:    omarsotres@intermatsa.com.mx
auth:       CRYPT-PW HIDDENCRYPTPW
mnt-by:     MAINT-AS262916
changed:    omarsotres@intermatsa.com.mx 20140112  #04:17:48Z
source:     RADB

More interestingly we can track and predict what other prefixes they will announce. By looking at RADB data we see that this maintainer has route objects for thousands of prefixes and several Origin ASns. The list below shows Autonomous Systems for which the Maintainer added route objects in RADB. Our data shows hundreds of short lived BGP announcements involving most of these Autonomous Systems, suggesting that these have been used in similar campaigns. AS15078 Telelatina S.A. ( ~1000 events) AS28490 TELEVISION POR CABLE DEL NORTE DE SONORA S.A. DE C.V. ( ~500 events) AS32579 eVolution Technology Group, LLC. Found ( ~200 events) AS19894 Novel, Inc (novelscs.com) ( no events) AS10516 Orb-bit Design Group (few events) AS10760 CS Wireless Systems, Inc. (one attempt visible via 1 peer only) December holidays As a sharp reader you may have noticed the Maintainer ID is MAINT-AS262916 which would suggest AS262916 is also related to this campagne. So let’s take a look at the data for AS262916. Indeed we find that the same exact pattern is visible for AS262916 between Dec 2013 and february 2014. Again, a handful of prefixes announced per cycle and only visible for a few hours. This pattern is clearly visible in the graph below. Interestingly there two gaps in this graph. The first one is between Dec 24th and Dec 26th the second one on January 1st. Indicating that the IP squatting briefly stopped over the holidays and that some manual action is required to make all of this work. There’s relatively little overlap between the announcements indicating there’s very little reuse of prefixes between the Autonomous systems used. For the ones that do overlap there are indeed two route objects, each one with a different origin AS. One such example is for 192.153.42.0/24

$ whois -h whois.radb.net 192.153.42.0/24
route:          192.153.42.0/24
descr:          route object
origin:         AS15078
mnt-by:         MAINT-AS262916
changed:        omarsotres@intermatsa.com.mx 20140823  #05:07:27Z
source:         RADB

route:          192.153.42.0/24
descr:          route object
origin:         AS28490
mnt-by:         MAINT-AS262916
changed:        omarsotres@intermatsa.com.mx 20140817  #18:34:06Z
source:         RADB

Conclusion In this post we looked at two separate IP squatting campaigns where what looks like two distinct organizations each used several Autonomous Systems to announce thousands of unused prefixes for a period of several hours or a few days. The first campaign is very much oriented around the Russian network AS57756 (PE Gaftkovich Irina Valer'evna). The second campaign uses a variety of Autonomous systems and primarily Hibernia and PCCW as transit networks while relying on route objects to get announcements accepted. The transit providers are typically being told that the customer is a DDOS mitigation company, they use this as a cover and explanation for why they announce a variety of different prefixes over time for a short duration. Most of the announced address space was not routed at the time of the incidents. The data does however show a few cases where actively routed address space was announced by the Spam networks, making this a hijack. It is also worth noting that there could be cases where address space is actively used by the legitimate owners but not visible in the global routing tables. One example is the Peering Lan prefix for Internet Exchanges. We did indeed observed a hijack for IP space allocated to an Internet exchange point. These ranges are typically not routed for security and stability reasons. A hijack in the form of a more specific BGP route for an Internet Exchange peering LAN will cause serious stability issues for an Internet exchange and its connected networks. By working with some of the upstream providers involved and by looking at Spam lists we concluded that this space was indeed used for spamming activities. One of of the upstream providers involved confirmed that a 100% of the outbound traffic was SMTP primarily towards Hotmail, Charter and Verizon. IP squatting is not new, but we hope that these two examples provide more insight and some quantitative data that demonstrate the scale and frequency of these events.   Special thanks to Job Snijders for his help in researching these incidents.