BackConnect’s Suspicious BGP Hijacks

September 20, 2016 Doug Madory

Earlier this month, security blogger Brian Krebs broke a story about an Israeli DDoS-for-hire service, vDOS, which had been hacked, revealing “tens of thousands of paying customers and their (DDoS) targets.”  Afterwards, Krebs noticed that vDOS itself was also a victim of a recent BGP hijack from a company called BackConnect, which claims to be the “world’s first and leading open source based DDoS and network security provider.”

Bryant Townsend, CEO of BackConnect, confirmed to Krebs that they had indeed conducted a BGP hijack on vDOS, but claimed that it was for “defensive purposes.”  In an email to the NANOG list, Townsend explained that in doing so they “were able to collect intelligence on the actors behind the botnet as well as identify the attack servers used by the booter service,” implying this was a one-time event.  Krebs then contacted Dyn for some assistance in researching what appeared to be a series of BGP hijacks conducted by BackConnect over the past year.  What emerges from this analysis is that the hijack against vDOS probably wasn’t the first time BackConnect used BGP hijacks in the course of its business.  And via the use of forged AS paths, BackConnect sometimes obscured their involvement in this activity. (Today’s blog post on BackConnect by Brian Krebs can be found here.)

Hijack of vDOS/Verdina

Let’s first take a look at BackConnect’s recent hijack of vDOS that brought this discussion to the fore.  According to our data, BackConnect (AS203959) began announcing 82.118.233.0/24 (Verdina Ltd.) at 07:13:26 UTC on 7 September 2016.  Over half of our peers accepted a BGP route with BackConnect’s ASN as the origin until it stopped announcing the route at 7:49:15 UTC, less than 50 minutes later.  The propagation of this route is depicted in the visualization below, which shows the duration and reach of BackConnect’s route across the hundreds of BGP sources we employ for our analysis.


82.118.233.0_24
As stated by BackConnect’s new Twitter account, this action was performed for the purpose of intercepting Internet traffic destined for this address range.  Supposedly a botnet control node employed by vDOS was hosted in this IP space and by hijacking it, BackConnect could see who was connecting to it, or to put it in their CEO’s own words, “the actors behind the botnet.”

When viewing this BGP hijack in the context of our traceroutes, we can see the new path traffic took as a result of this action.  Prior to the hijack, traceroutes from our server hosted with Amazon Web Servces (AWS) in Ashburn, VA would normally traverse Cogent from Washington DC and on to Sofia, Bulgaria where Verdina is located.  Below is one of those traceroutes the day prior to the hijack.

trace from AWS Ashburn, VA to 82.118.233.12 at 08:19 Sep 06, 2016
1  *
2  *
3  100.65.11.65    RFC 6598 (carrier-grade NAT)                             0.589
4  205.251.245.227 Amazon.com, Inc.                       Ashburn     US    1.421
5  54.239.110.24   Amazon Technologies Inc.               Ashburn     US    1.468
6  54.239.110.7    Amazon Technologies Inc.               Ashburn     US    1.491
7  67.133.224.193  dca2-edge-02.inet.qwest.net            Washington  US    2.009
8  67.14.28.18     dcp-brdr-04.inet.qwest.net             Washington  US    2.554
9  154.54.11.129   be3045.ccr41.iad02.atlas.cogentco.com  Washington  US    1.878
10 154.54.31.109   be2657.ccr42.dca01.atlas.cogentco.com  Washington  US    3.104
11 154.54.40.109   be2807.ccr42.jfk02.atlas.cogentco.com  New York    US    9.058
12 154.54.42.86    be2490.ccr42.lon13.atlas.cogentco.com  London      GB   77.922
13 130.117.51.42   be12488.ccr42.ams03.atlas.cogentco.com Amsterdam   NL   83.648
14 130.117.0.142   be2814.ccr42.fra03.atlas.cogentco.com  Frankfurt   DE   93.298
15 154.54.36.254   be2960.ccr22.muc03.atlas.cogentco.com  Munich      DE  100.592
16 154.54.58.14    be2975.ccr21.vie01.atlas.cogentco.com  Vienna      AT  104.828
17 130.117.1.21    be2046.ccr21.sof02.atlas.cogentco.com  Sofia       BG  125.216
18 *

During the hijack, the traceroute instead went from Amazon to Comcast and on to Voxility (BackConnect’s transit provider of choice, covered by KrebsonSecurity in 2013) to Los Angeles.  Numerous traceroutes from around the world were redirected to Voxility in Los Angeles, as opposed to anything in Bulgaria during the hijack.

trace from AWS Ashburn, VA to 82.118.233.12 at 07:41 Sep 07, 2016
1  *
2  *
3  100.65.11.65    RFC 6598 (carrier-grade NAT)                         0.478
4  205.251.245.184 Amazon.com, Inc.                   Ashburn      US   0.668
5  54.239.111.10   Amazon Technologies Inc.           Ashburn      US   1.054
6  54.239.108.209  Amazon Technologies Inc.           Ashburn      US    0.75
7  50.242.148.69   Comcast Cable Communications, LL   Ashburn      US   1.436
8  173.167.58.130  Comcast Business Communications,   Ashburn      US    1.12
9  37.221.173.74   ash-eqx-01c.voxility.net           Ashburn      US   1.283
10 5.254.109.90    lax-eqx-01c.voxility.net           Los Angeles  US  62.358
11 82.118.233.12   Verdina Ltd.                                        62.633

As seen in Dyn’s Internet Intelligence, typical incoming transit for BackConnect has the following form, i.e., BackConnect typically has Voxility as the sole upstream provider for their prefixes.

Screen Shot 2016-09-20 at 7.56.26 AM

In the remaining part of this blog post, we’ll take a look at some of the other interesting BGP routing activity involving BackConnect (AS203959) over the past year.

Forged AS Paths

On 20 February 2016, BackConnect hijacked a route (72.20.0.0/24) belonging to a competing DDoS-mitigation provider, Staminus.  In March, Brian Krebs broke the news that Staminus had been hacked, revealing sensitive customer data.  This sequence of events has led some to believe that BackConnect may have been involved in the Staminus hack.  BackConnect CEO Bryant Townsend was formerly SVP of Business Development at Staminus.

Setting aside that discussion, here’s what the hijack looked like from a BGP perspective.  The prefix 72.20.0.0/24 is a more-specific of 72.20.0.0/19, which is announced by Staminus (AS25761).

72.20.0.0_24
At 08:36:59 UTC, BackConnect began hijacking this address space using the following AS path:
... 3223 203959 53587 53587 53587 53587 134830 134830 134830 203959 203959

Then the AS path changed to the following with InAbate (AS134830) ostensibly as the origin (rightmost ASN):
... 3223 203959 32768 53587 53587 53587 53587 134830 134830 134830

Finally, BackConnect added AS25761 (Staminus) as the origin, taking the form:
... 3223 203959 1229 3257 25761

In every case, the routes passed through BackConnect’s ASN (AS203959) and onto another DDoS-mitigation provider, Voxility (AS3223).  In the third form of the AS path, we can be sure that the last three ASNs in the path were forged.  For one, GTT (AS3257) never had this route in its table at the time.  Also Staminus uses GTT and Telia (AS1299) for transit, so it appears that BackConnect attempted to make it look like the route had passed through these ASNs (AS1229 was likely a typo for Telia’s AS1299), or perhaps they were there to prevent those providers from carrying the route.  Regardless of BackConnect’s intentions, announcing a more-specific hijack with a forged AS path is itself a pretty suspicious act.

On the following day, BackConnect announced 161.123.185.0/24, a more-specific hijack of 161.123.128.0/17 originated by GHOSTnet GmbH (AS12586).  While OpenDNS’s automated BGPstream service spotted this one, it misidentified the actual hijacker.

161.123.185.0_24
During the orange spike in the above graph, the AS path initially had BackConnect as the origin:
… 3223 203959
Then at the very end, the AS path changed to the following.
… 3223 203959 1229 3257 25761

Again AS25761 belongs to Staminus and AS3257 (GTT) and AS1229 (same typo for Telia as above) are the upstreams of Staminus.  That portion of the AS path is clearly forged.  This hijack wasn’t conducted by Staminus, it was BackConnect (AS203959) posing as Staminus via a forged AS path.

BackConnect again used forged AS paths on 21 February 2016 when announcing 146.84.2.0/24 (Tivoli Systems).  At the time, 146.84.2.0/24 was not announced, although it is currently announced by Softlayer.  At 07:58:53 UTC, this route was announced with an origin of 4134 (China Telecom) but exclusively routed through BackConnect and Voxility.  Later it was changed to have an origin of Hurricane Electric (AS6939) and upstreams of AS42708 (Portlane) and AS36236 (Host Virtual), followed by China Telecom (again). It was again routed exclusively through BackConnect.

First AS path format:
... 3223 203959 4134
Second AS path format:
... 3223 203959 4134 42708 36236 6939

146.84.2.0_24
We have several peering sessions with Hurricane Electric (HE) and can report that this route was not in their routing table at this time, let alone with HE as the origin.  We also have peering in China that doesn’t support China Telecom as the origin either.  If China Telecom were really carrying this route, it would have been seen by other upstreams of China Telecom and not just BackConnect.  These facts support the conclusion that this AS path was also forged by BackConnect.

What was BackConnect’s purpose of hiding the origin of a route of unused address space?  As stated by Bryant Townsend in a post to the NANOG mailing list explaining their hijack of vDOS, “No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future”, implying this was a one-time event, rather than a pattern of behavior.

On 16 April 2016, BackConnect began transiting a new route that was a hijack of routed address space.  The route (161.123.172.0/24) was a more-specific hijack of 161.123.128.0/17 originated by GHOSTnet GmbH (AS12586).  Was this another case of BackConnect (AS203959) forging the origins to obfuscate their involvement in this hijack?

The AS path first took the form
... 3223 203959 27176
and was then changed to
... 3223 203959 29073

So the origin appeared to be DataWagon (AS27176) and then Ecatel (AS29073), but the paths always traversed BackConnect (AS203959), and, of course, Voxility.

161.123.172.0_24_1460764800_1460851200
Looking at FQDNs resolving to this space, we observed the following very odd ones over the past year:
161.123.172.0 blastonetst74.top
161.123.172.1 occurcblal89s.top
161.123.172.2 lowcblamah90s.top
161.123.172.12 vrtlmqdowl.xyz
161.123.172.25 flatten135mail.top
161.123.172.136 rthesel.racing
161.123.172.245 uintoh.racing
161.123.172.246 aautumnn.racing

Other BackConnect hijacks of note

Soon after BackConnect’s ASN (AS203959) appeared in the routing table last fall, it had conducted its first BGP hijack.  For about 20 minutes, it announced 85.203.15.0/24, a more-specific of 85.203.0.0/18 announced by Falco Networks (AS31251).

85.203.15.0_24
One might wonder if this incident could be chalked up to a typical BGP-based DDoS mitigation, such as Akamai’s Prolexic service.  The short duration of the hijack and the lack of global propagation makes this less likely.  If a sizable portion of the Internet’s routers do not carry a route to a DDoS mitigation provider, then the attack traffic won’t end up at the provider’s traffic scrubbing centers, thus limiting the efficacy of any mitigation.  In addition, DDoS attacks often last more than 20 minutes.  Alternatively, short-lived announcements could be more effective with reconnaissance than with mitigation, as we reported back in 2013, when man-in-the-middle traffic redirection was first observed.   The routing is clear; the motivations of the actors are not.

On 4 December 2015, BackConnect hijacked address space belonging to Russian DDoS-mitigation provider DDoS-Guard.

186.2.169.0_24_1449187200_1449316800-2
A couple of weeks later, BackConnect began routing one of its own prefixes (191.101.191.0/24) via DDoS-Guard.  Below is a visualization of the upstreams of BackConnect (AS203959) for this route.

191.101.191.0_24
On 7 January 2016, BackConnect hijacked 66.85.48.0/24 (Sauce Labs) for about 5 minutes.  Since the normal origin (AS62537) didn’t stop announcing the route, there was no apparent coordination between the two parties, suggesting that this was an uninvited action.

66.85.48.0_24
On 19 February 2016, BackConnect briefly announced eight routes that were all more-specific hijacks of 161.123.128.0/17, a prefix normally announced by GHOSTnet (AS12586)
161.123.171.0/24
161.123.173.0/24
161.123.175.0/24
161.123.177.0/24
161.123.179.0/24
161.123.181.0/24
161.123.183.0/24
161.123.185.0/24

 

161.123.171.0_24_1455861600_1455890400 161.123.177.0_24_1455861600_1455890400

Many suspicious FQDNs were seen resolving to this address space in the past year, including …
161.123.171.10 vtzeqpzrpv.xyz
161.123.171.37 dbootse.kim
161.123.171.88 abilx.xyz
161.123.171.135 gintob.racing
161.123.171.137 bthenj.racing
161.123.171.138 xworkd.racing
161.123.171.244 eothers.racing
161.123.171.246 ugivem.racing
161.123.171.247 iwhenx.racing

On 17 April, BackConnect announced 89.248.162.0/24 which was a more-specific of 89.248.160.0/21 announced by Ecatel (AS29073).

89.248.162.0_24
Many suspicious FQDNs were seen resolving to this address space in the past year, including …

89.248.162.209 az3desau.bodyrci.top
89.248.162.209 mail.bodyrci.top
89.248.162.210 mail.keeprci.top
89.248.162.210 ol8ku7ntre.keeprci.top
89.248.162.211 mail.iicould.top
89.248.162.211 xse4vujur.iicould.top
89.248.162.214 dew3iqauji.iicanal.top
89.248.162.214 mail.iicanal.top
89.248.162.215 mail.iicrown.top
89.248.162.215 wed4gutai.iicrown.top
89.248.162.217 ce5tgiqayu.assumek.top
89.248.162.217 mail.assumek.top
89.248.162.218 mail.absentz.top
89.248.162.218 sicre5buiy.absentz.top
89.248.162.219 mail.sprainz.top

BackConnect’s Routing Leak

BGP routing leaks (especially peering leaks) occur in some form nearly every day.  But for a company that has confirmed that it has manipulated BGP routes in order to intercept traffic, what may otherwise be viewed as simply an innocent BGP leak involving BackConnect might now be viewed in a different light.  At 09:08:28 UTC on 28 May 2016, BackConnect leaked over 13,000 BGP routes from various peers to its transit provider Voxility. Below are visualizations depicting the duration and the degree of route propagation by BackConnect as an upstream for four of these routes.

64.6.21.0_24 198.71.216.0_22
140.186.100.0_23 92.30.0.0_15

As part of our continuous global Internet latency and path monitoring, many hundreds of traceroutes were redirected through Voxility and presumably BackConnect on their way to their various destinations.  Below is an example of a server in London with Level 3 transit, tracing out the path it took to Opal Telecom, also in London, the day before the leak.

trace from London to 92.27.98.182 at 12:01 May 27, 2016
1  *
2  212.187.201.89 xe-9-1-1-205.edge3.London2.Level3.net    London  GB  0.315
3  *
4  *
5  4.68.111.26    GTT-level3-100G.London15.Level3.net      London  GB  0.595
6  213.200.79.10  talktalk-communications-gw.ip4.tinet.net London  GB  0.673
7  78.144.12.253  host-78-144-12-253.as13285.net           London  GB  0.939
8  78.144.11.228  host-78-144-11-228.as13285.net           London  GB  5.222
9  78.151.228.83  host-78-151-228-83.as13285.net           London  GB  2.001
10 62.24.254.204  host-62-24-254-204.as13285.net           London  GB  1.856
11 92.27.98.182   mail.wla.co.uk                           London  GB 25.141

Then during the leak, a traceroute with the same source and destination was redirected to Voxility PoP in Miami, Florida before being passed back to London to reach Opal Telecom.

trace from London to 92.27.98.182 at 09:11 May 28, 2016
1  *
2  212.187.201.89 xe-9-1-1-205.edge3.London2.Level3.net London     GB    0.303
3  4.69.166.130   ae-115-3501.edge3.London1.Level3.net  London     GB    0.388
4  4.68.63.150                                          London     GB    0.652
5  195.22.199.179 et9-3-0.miami15.mia.seabone.net       Miami      US   98.385
6  195.22.199.179 et9-3-0.miami15.mia.seabone.net       Miami      US   98.173
7  89.221.41.111  voxility.miami15.mia.seabone.net      Miami      US  104.161
8  5.254.114.98   mia-nap-01c.voxility.net              Miami      US  106.383
9  5.254.109.85   ash-eqx-01c.voxility.net              Washington US  137.884
10 *
11 *
12 78.144.11.110  host-78-144-11-110.as13285.net        London     GB  142.411
13 78.151.234.97  host-78-151-234-97.as13285.net        London     GB  143.289
14 62.24.254.204  host-62-24-254-204.as13285.net        London     GB  143.391
15 92.27.98.182   mail.wla.co.uk                        London     GB  166.841

It is safe to assume that a lot of Internet traffic passed through Voxility en route to BackConnect on 28 May 2016.

Conclusions

What we can conclude from all of this is that BackConnect has a history of hijacking BGP routes and, while this is not uncommon for DDoS mitigation services, their hijacking pattern is unusual to say the least.  With limited propagation of routes, very short duration hijacks, deliberate attempts at obfuscation, and apparent lack of coordination with the impacted parties, these traffic interceptions seem completely unlike typical services between consenting parties.

As readers of this blog will certainly know, the DDoS threat is growing ever more “frequent, persistent, and complex.”  The more we can learn about the actors and their methods of operation, the better we can defend ourselves and the health and operation of the global Internet.  Regardless of BackConnect’s intentions, the larger question for the community is to what lengths are we willing to go in that struggle and under whose authority?


DDoS Mitigation Firm Has a History of Hijacks https://t.co/XtTdUrdTVh < many hours of research. meanwhile, my site remains under attack

— briankrebs (@briankrebs) September 20, 2016

KrebsOnSecurity worked with Doug Madory at Dyn on research in today's post about BackConnect and vDOS. Their take: https://t.co/Q61RlQXHFU

— briankrebs (@briankrebs) September 20, 2016

 

Appendix:  Additional BackConnect BGP routing activity

Author’s note: For the sake of completeness, we have added additional descriptions of routing activity involving BackConnect below.

3 December 2015:  172.81.129.0/24

In December, BackConnect announced 172.81.129.0/24, a more-specific hijack of 172.81.128.0/21, which is announced by AS48884 (VolumeDrive).  This hijack lasted a couple of days and eventually achieved global propagation.  Such a pattern is more consistent with BGP-based DDoS mitigation.

172.81.129.0_24_1449100800_1449532800
7 January 2016:  66.85.47.0/24 & 172.93.120.0/24

On 7 January 2016, BackConnect briefly appeared upstream of Host4Geeks LLC (AS393960) for two of its routes.  If this was DDoS mitigation, it wouldn’t have been very effective considering its brevity, limited route propagation, and lack of coordination between the different parties announcing the routes.

66.85.47.0_24_1452135600 172.93.120.0_24_1452146400

March – July, 2016:  1.3.3.7

In the past year, http://1.3.3.7 has been the location of a hacker forum.  It was initially originated by DataWagon (AS27176) on 15 November 2015.  Soon after it would appear that origin had changed, when in reality DataWagon had simply falsified part of the AS path to make it appear as though it was coming from elsewhere.

1.3.3.0_24b-3

The new AS path was the following:

... 174 27176 6939 3257 4134 8655

If this path were to be believed, it would suggest that AS8655 (an unused ASN) was the origin, which supposedly sent this route exclusively to China Telecom (AS4134), who then sent it exclusively to GTT (AS3257), Hurricane Electric (AS6939) and on to DataWagon (AS27176).  This route would cycle through other origins with falsified AS paths over the following months until it sputtered out in July.

In March, DataWagon had returned to being the origin of 1.3.3.0/24 and continued to do so until 21 July 2016 when it was withdrawn.  However, the route reappeared the following day, again originated by DataWagon (AS27176) (pictured below left), but this time with BackConnect as its exclusive upstream instead of DDoS mitigation provider ProTraf (AS63990) (pictured below right).

1.3.3.0_24_1468886400_1469664000 1.3.3.0_24_1468886400-2

24 March 2016:  31.220.31.0/24

While the following hijack didn’t involve BackConnect, it did involve the DDoS mitigation provider (Voxility) exclusively used by BackConnect in a hijack of Staminus (31.220.31.0/24) occurring on 24 March 2016.  The private ASN (AS65421) seen in many AS paths appeared just after Voxility’s ASN.  Since Staminus didn’t stop announcing this route during this incident, this doesn’t appear to be consistent with consensual DDoS mitigation.

31.220.31.0_24_1458813600_1458864000
23 April 2016:  101.96.129.0/24

OpenDNS’s BGPstream claimed a BackConnect hijack of 101.96.129.0/24 on 23 April 2016.  Technically speaking, this was not a hijack as the victim’s prefix (101.96.128.0/18) had ceased being routed at about 11:00 UTC the previous day (22 April). Having said that, 101.96.128.0/18 appears to have been announced by IP squatter Bitcanal (AS197426) using a phony origin ASN, AS55830 (Indonesia Digital Media).  Suspicious routing from Bitcanal has been mentioned on multiple occasions in this blog.

101.96.129.0_24 101.96.128.0_18_1461283200_1461398400

20 May 2016:  191.86.129.0/24

On 20 May 2016, BackConnect announced 191.86.129.0/24 which was a more-specific hijack of 191.86.128.0/19, announced by AS26615 (Tim Celular of Brazil).  BackConnect explained to Brian Krebs that this hijack was simply a typo as one of their routes differs by a single digit (191.96.129.0/24).

191.86.129.0_24

Read more...

About the Author

Doug Madory is a Director of Internet Analysis at Dyn where he works on Internet infrastructure analysis projects. Doug has a special interest in mapping the logical Internet to the physical lines that connect it together, with a special interest on submarine cables.

Follow on Twitter More Content by Doug Madory
Previous Article
War-torn Syrian city gets new fiber link
War-torn Syrian city gets new fiber link

The northern Syrian city of Aleppo is one of the key battlegrounds of that country’s on-going civil war as ...

Next Article
Syria goes to extremes to foil cheaters
Syria goes to extremes to foil cheaters

Early this morning in Syria, the Internet was almost entirely down for four hours.  It was the ninth such o...