• January 29, 2015

The Vast World of Fraudulent Routing

As network security engineers have attempted to categorize blocks of IP addresses associated with spam or malware for subsequent filtering at their firewalls, the bad guys have had to evolve to continue to target their victims.  Since routing on the global Internet is based entirely on trust, it's relatively easy to commandeer IP address space that belongs to someone else.  In other words, if the bad guys' IP space is blocked, well then they can just steal someone else's and continue on as before.

In an attempt to cover their tracks, these criminals will sometimes originate routes using autonomous system numbers (ASNs) that they don't own either.  In one of the cases described below, perpetrators hijacked the victim's ASN to originate IP address space that could have plausibly been originated by the victim.  However, in this case, the traffic was misdirected to the bad guy and an unsophisticated routing analysis would have probably shown nothing amiss.

The weakness of all spoofing techniques is that, at some point, the routes cross over from the fabricated to the legitimate Internet — and, when they do, they appear quite anomalous when compared against historical data and derived business relationships and markets, a key data source for our products like Dyn's IP Transit Intelligence.

In this blog post, I review six examples of entities with bogus routing announcements within the past few months—some of which are ongoing—and I discuss some possible remedies in the conclusions. These examples help to illustrate a few things.  First, these are not isolated incidents.  These bogus routes are being circulated at a near constant rate and many separate entities are engaged in this practice, although with subtle differences in approach.  Second, these techniques aren't solely for the (relatively benign) purpose of sending spam.  Some of this host address space is known to circulate malware.

Finally, these techniques offer the perpetrator the ability to communicate on the Internet without revealing his or her true source.  Security analysts should proceed with extreme caution when using IP addresses as identifiers of a bad actor.  In a world where routing hijacking is becoming increasingly common, IP addresses are simply not reliable for attribution.

And with that introduction, I present the following six sources of bogus routing on the Internet.

Case 1: Petersburg Internet Network (AS44050)

The IP-squatting operation I mentioned on the NANOG list back in August has continued unabated into the New Year.  Not surprisingly, the ASNs have changed since I noted the last change on this blog in September.  The latest format for their bogus routes is as follows:

... 44050 131788 198596 (hijacked prefix)

Also new is the fact that the Romanian AS198596 is now being legitimately utilized in Romania and since December 17th has been getting transit from Romanian ISPs Dial Telecom (AS6910) and Teen Telecom (AS34304) — yes, that's their actual name.

A couple of weeks ago, the IP-squatters in Saint Petersburg, Russia hijacked routed address space of the Italian National Institute of Nuclear Physics (Istituto Nazionale di Fisica Nucleare), a popular target of theirs.  Pictured below are the timelines of AS198596's originations of and, which are more-specific hijacks of and, respectively — both normally originated by AS137 (GARR, the Italian Research & Education Network).

90% of our peers see hijacks from AS198596 across AS adjacency 174_39792, namely, Cogent's transit service (AS174) for its customer Anders Telecom (AS39792). If Cogent started blocking routes from the Petersburg Internet Network Ltd.(AS44050) until they clean up their act, it might save everyone a lot of hassles.

This is because those brief hijacks coming from AS198596 aren't the only sketchy thing coming through the Petersburg Internet Network (AS44050) these days. Since December 5th, AS44050 has also been transiting routes from Medix Direct (AS263171): and, which is ostensibly Panamanian address space (commercial geolocation providers take note). This address space hosts hundreds of suspicious mail domains likely used for spam generation such as

(and many more)

Prior to appearing out of Saint Petersburg, Russia in early December, this AS and its prefixes were transited by Petersburg Internet Network USA (AS54985) in Florida. However, AS54985 and its transit relationship to Level 3 (AS3356) vanished on October 27th of last year.

Additionally, from December 12th to January 16th, AS44050's customer AS201593 (Technologii svyazi, LLC) originated a prefix ( which was a more-specific hijack of — a prefix originated by Digital United (AS4780) out of Taiwan. And starting January 8th, another AS44050 customer, namely, Trast Ltd. (AS198747) has been very briefly announcing various ranges of unused IP address space such as (Dougenzaka, JP), (Sybaweb Internet, ZA), and (Chinanet, CN), pictured below.


While all this makes AS44050 perhaps the leading contender for being named the Mos Eisley of the Internet, it isn't the only candidate.

Case 2: Bitcanal (AS197426)

Then there is Bitcanal (AS197426) of Portugal, which we mentioned in September as an outfit announcing the address space of the State Attorney General of Texas (, as well as unused Syrian address space (  They have kept busy routing suspicious routes in the months since.

In the past couple of weeks, AS197426 gained a new downstream customer, AS18254, which routes a lot of address space from Asia.  For several days it announced more-specific hijacks of routes typically announced by Tata's domestic ASN, AS4755. and were also routed in a similar manner and were hijacks of routed Indian address space.  To someone familiar with BGP routing, it might seem odd that these routes were only seen by about 40% of our BGP sources.  Given that they are more-specifics, it would be reasonable to expect global propagation.  However, a quick analysis of AS paths reveals that for these prefixes, AS197426 didn't announce them to its transit providers, namely, NTT (AS2914), Colt (AS8220), Level 3 (AS3549) and Refer Telecom (AS29003).  It only announced them to peers, allowing for more limited propagation and non-corrupt paths out to its transit providers.

More recently, Bitcanal gained a new customer with very similar proclivities towards hijacking IP space (both routed and unrouted): Indonesian AS 24196 (PT Global Cibubur Access).  Over the course of four days in the past week, AS24196 announced several suspicious routes, including (a more-specific hijack of, originated by Korea Telecom, AS4766) and (unused address space registered to an organization in Kuching, Malaysia) pictured below. Like the routes originating from AS18254, these prefixes were only announced through Bitcanal's peers and not their transit providers resulting more limited propagation.

Other routes originated by AS24196 in the past week include: Equinix Singapore Pte Ltd Singapore  Pakistan Telecommuication company limited Karachi  Asia Pacific Network Information Centre  Asia Pacific Network Information Centre

Case 3: H3S median services (AS59790), Sky Capital Investments Ltd. (AS201509), Marcel Edler (AS197043), Andreas Sebastian Fahl (AS197890)

Unlike the examples above, this group generally prefers to briefly announce unrouted AfriNIC address space, such as some recent route originations depicted below by AS59790.

However, squatting on unused African IP address space isn't all AS59790 does.  It also hijacks IP address space of major US carriers as well.  In November, it routed unused IP address space from AT&T and a more-specific hijack of Comcast's route.

In December, a downstream ASN of AS59790 appeared for a few days (AS201509, Sky Capital Investments Ltd) and began announcing some of the same bogus routes that AS59790 had been announcing.  It was ostensibly passing these routes through AS59790 in the following form.

… 174 59790 201509 {hijacked prefix}

AS201509 only existed downstream of AS59790 from 14 — 27 December 2014.  Then, on December 27th, it reappeared announcing more bogus African routes through AS197043 (Marcel Edler), an ASN with a well established reputation for circulating malware.  In fact, Google's Safe Browsing diagnostic page for AS197043 states that it hosted "content that resulted in malicious software being downloaded and installed without user consent" and that "this network has hosted sites that have distributed malicious software in the past 90 days". AS201509 then disappeared on 6 January.

Since then, Andreas Sebastian Fahl (AS197890) began briefly announcing this unused AfriNIC address space, albeit through AS197043 (Marcel Edler) to a much smaller set of providers.

Case 4: Business Torg (AS60937)

I'm not the only one to encounter AS60937 circulating some suspicious routes. On and off for several weeks last year, they announced 12 prefixes along an unlikely AS path:

… 60937 12389 16509 6461 1273 {prefixes}

This sequence would suggest that AS1273 (Cable & Wireless, now Vodafone) was originating these routes, passing them to AS6461 (Abovenet), then to Amazon (AS16509), Rostelecom (AS12389), Business Torg (AS60937) and on to those who were peering with AS60937.  Two of the routes were hijacks of routed address space, shown in red below.

Several others were squatting on unused IP address space:

Also announced in a similar manner were the following ranges of unrouted IP address space: (Axtel, MX) (Axtel, MX) (Pegaso PCS, MX) (Triara.com, MX) (AfriNIC Ltd) (AfriNIC Ltd) (Microlink Technologies Ltd, ZM) (Datora Telecomunicações, BR)

Of course, AS1273 never really originated these prefixes.  Otherwise, we would have seen more sensible AS paths for them — not one whose sequence requires us to believe that Amazon (AS16509) is leaking these routes from Abovenet to Rostelecom only.  This case illustrates how difficult it can be to assign reputations to ASNs, since AS paths seen in routing announcements are easily manipulated.  If AS1273 were tagged as an unsafe ASN as a result of these forged paths, would the world then start blocking legitimate traffic from Vodafone?  Any simplistic approach taken by defenders will surely be circumvented by the attackers to continue operations and perhaps even be exploited to attack victims.  Inferring legitimacy from the complex global routing table is a difficult undertaking.

Case 5: FOP Obuhov Oleg Gennadiyovich (AS197923)

The previous example wasn't the only case of falsifying origins in routing announcements. On June 30th of last year, we saw AS197923 appear as the first and only customer of LLC Telecontur (AS47951) — a provider in Ufa, Russia that typically originates three prefixes.  Beginning on August 1st of last year, we saw AS197923 begin to transit prefixes from some unlikely sources.  On that day, AS3300 (BT Infonet) first appeared downstream of AS197923 transiting (BT Infonet). is unused IP address space that is registered to the same company employing AS3300, namely, British Telecom's BT Infonet.  This represented a real escalation in the war on Internet routing, namely, a falsified but quite plausible origin for hijacked routes.

Over the next couple of months until November, AS197923 routed more prefixes from plausible origins.  This phenomenon illustrates that the hijackers have upped their game and that simply checking that the origin of a route appears valid isn't good enough.  These routes were originated by very reasonable origins.  It was their transit pattern that jumped out at us.  British Telecom routes aren't transited through a small provider from Ufa, Russia.  That just doesn't happen.

Falsely originated by AS3300 (BT Infonet), AS197923 transited the following prefixes.  Boehringer Ingelheim Pharmaceuticals, Inc. Ridgefield CT US  Boehringer Ingelheim Pharmaceuticals, Inc. Ridgefield CT US British Telecommunications plc BE   British Telecommunications plc NL  INFONET Services Corporation El Segundo CA US    INFONET Services Corporation El Segundo CA US   INFONET Services Corporation El Segundo CA US INFONET Services Corporation El Segundo CA US  INFONET Services Corporation El Segundo CA US

Falsely originated by AS5400 (British Telecom's primary ASN), AS197923 transited the following prefixes.   Akzo Nobel Coatings NL   Akzo Nobel Coatings NL   KIS Information Services GmbH DE African Network Information Center - (AfriNIC Ltd) Lagos Lagos NG

Of the routes above, is a less-specific of an existing route — originated by Interoute (AS8928).  In the month of October last year, a handful of suspicious domains appeared:


These domains resolved to, an IP in the /16, but not in the /24. This while was being routed along 197923_5400.

Falsely originated by AS5427 (Primus Telecommunications Europe), AS197923 transited the following prefixes. Primus Telecommunications Europe DE  Primus Telecommunications Europe DE    Primus Telecommunications Europe DE

Except for, which is originated by AS15968 and is a more-specific of, all three prefixes are unrouted IP address ranges.

Falsely originated by AS20570 (T-Systems International GmbH), AS197923 transited the following prefixes.  CAE Electronics Saint-Laurent QC CA  Actebis Holding GmbH Frankfurt Am Main Hessen DE   TNT Express GmbH Frankfurt Am Main Hessen DE  T-Systems International GmbH Frankfurt Am Main Hessen DE  T-Systems International GmbH Frankfurt Am Main Hessen DE  T-Systems International GmbH Hannover Niedersachsen DE   T-Systems International GmbH Frankfurt Am Main Hessen DE    T-Systems International Frankfurt-Niederrad Hessen DE   T-Systems International GmbH Frankfurt Am Main Hessen DE

And finally, falsely originated by AS37053 (RSAWEB of South Africa), AS197923 transited, unused routed address space registered to RSAWEB.

All of the routes involved in this route squatting operation took the following form (AS3216 is Vimpelcom of Russia):

... 3216 47951 197923 {3300, 5400, 20570, 5427, 37053} hijacked_prefix

Unlike some of the other Russian IP squatting operations, these routes stayed up for days or weeks at a time. On November 5th of last year, I had seen enough of this behavior and started investigating it in earnest.  I began using Dyn Internet Intelligence to launch on-demand traceroutes from all over the world into the hijacked routes to help explore where hijacked traffic ended up.  The results confirmed that the traffic to these routes was being redirected into Russia.  However, while I was running these traceroutes, AS197923 and all its bogus routes disappeared.  It has not returned since.

Case 6: Comfort Air (AS200080) and 2Slink GmbH (AS60025) ASNs have had an interest in routing Iranian address space in the past year.  During December, AS200080 originated out of Bulgaria for about two weeks.  This route is a more-specific hijack of (Parsun Network Solutions) that is typically originated by AS31732 out of Iran.  Based on our DNS logs, between 22 — 28 December we observed DNS queries to the following suspicious FQDNs resolving to a single IP ( in this range from a few hosts in the United States.

barehuva.uyqwiewqeou.rocks 2014-12-22
hedamuva.uyqwiewqeou.rocks 2014-12-22
u8a4aja2.uyqwiewqeou.rocks 2014-12-22
vuza4enu.uyqwiewqeou.rocks 2014-12-22
yhalajed.uyqwiewqeou.rocks 2014-12-22
yjege5ym.uyqwiewqeou.rocks 2014-12-22
zyzujy4u.uyqwiewqeou.rocks 2014-12-22
4are8avu.uyqwiewqeou.rocks 2014-12-23
5a9uqesy.uyqwiewqeou.rocks 2014-12-23
5urygebu.uyqwiewqeou.rocks 2014-12-23
8umuhamy.uyqwiewqeou.rocks 2014-12-23
apuzydy2.uyqwiewqeou.rocks 2014-12-23
dygavu5e.uyqwiewqeou.rocks 2014-12-23
e5e5ezu8.uyqwiewqeou.rocks 2014-12-23
etyju3u5.uyqwiewqeou.rocks 2014-12-23
ezadutud.uyqwiewqeou.rocks 2014-12-23
gyhugyze.uyqwiewqeou.rocks 2014-12-23
lezezu9a.uyqwiewqeou.rocks 2014-12-23
qyhe6yzy.uyqwiewqeou.rocks 2014-12-23
  sy3yny6e.uyqwiewqeou.rocks 2014-12-23
ugygeweq.uyqwiewqeou.rocks 2014-12-23
uqe5y9e5.uyqwiewqeou.rocks 2014-12-23
y4y3avys.uyqwiewqeou.rocks 2014-12-23
yxese4y7.uyqwiewqeou.rocks 2014-12-23
yzeqyvep.uyqwiewqeou.rocks 2014-12-23
zuveqyva.uyqwiewqeou.rocks 2014-12-23
uvu2ubu7.uyqwiewqeou.rocks 2014-12-26
xyvulabu.uyqwiewqeou.rocks 2014-12-26
e8ymy8as.uyqwiewqeou.rocks 2014-12-27
esetesap.uyqwiewqeou.rocks 2014-12-27
gyja4amy.uyqwiewqeou.rocks 2014-12-27
te7ydy5u.uyqwiewqeou.rocks 2014-12-27
vu4y4esy.uyqwiewqeou.rocks 2014-12-27
ydegygyl.uyqwiewqeou.rocks 2014-12-27
5erupavy.uyqwiewqeou.rocks 2014-12-28
hytuguva.uyqwiewqeou.rocks 2014-12-28
te7ydy5u.uyqwiewqeou.rocks 2014-12-28
ujymymeq.uyqwiewqeou.rocks 2014-12-28

While these *.uyqwiewqeou.rocks FQDNs still resolve to as of this writing, Dyn has not handled any queries for these FQDNs since the hijack disappeared.  What these FQDNs delivered to these hosts in the United States is unknown.  However, Vince Berk of Flowtraq (a network traffic flow analytic tool) informed me that one of their customers observed the following pattern taken from a packet capture:

[8b chars].uyqwiewqeou.rocks/[something]/[something]?sqi=[integer]


As lengthy as this blog post is, the list of hijacking examples given here is in no way exhaustive.  Our point in providing all of this detail is to illuminate a now constant and worrying trend on the Internet.  The criminals have discovered route hijacking and are exploiting this high-ground of global Internet trust on a daily basis. Having shown that, what is there to do?

Network operators like Cogent could consider dropping routes to entities like AS44050 that have a long history of being the source of spam and malware. Additionally, if you are peering with Business Torg (AS60937), Bitcanal (AS197426) or Marcel Edler (AS197043), you might want to review the routes you are receiving through them, or reconsider having the connections at all.

For security analysts reviewing alert logs, it is important to appreciate that the IP addresses identified as the source of incidents can and are regularly spoofed. For example, an attack that appeared to come from a Comcast IP located in New Jersey may have really been from a hijacker located in eastern Europe, briefly commandeering Comcast IP space. It is interesting to note that all six cases discussed above were conducted from either Europe or Russia.

Also, it is important to recognize that naive approaches for detecting nefarious routing behavior that rely on origin validation simply aren't enough anymore.  The Ufa, Russia example shows that the perpetrators have advanced to the point of using plausible AS origins for their IP squatting.  A cryptographic solution like BGPSEC is needed, but progress is slow going. Since routing isn't going to be secured any time soon, consider that the same Dyn Internet Intelligence that tracks Internet performance around the world also offers extensive and detailed real-time BGP routing alarms as one of its many features. Ultimately the solution must include the routing community. Last year's Mutually Agreed Norms for Routing Security (MANRS) document is worth everyone's attention and should grow to include thousands of additional signatories.

I will be reviewing these and other routing-based incidents at the Kaspersky Security Analysts Summit in sunny Cancun, Mexico next month. If you are in attendance at that event, please stop by and introduce yourself.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha