Multiple banking IP traffic hijacked

On 24 July a significant number of Internet Protocol (IP) addresses that belong to US banks suddenly were routed to somewhere else 

An IP address is how packets are routed to their destination across the Internet.

BGP mitm and multiple banking addresses hijacking is real

Why is this important you ask? Well, imagine the Internet suddenly decided that you were living in the middle of Asia and all traffic that should go to you ends up traveling through a number of other countries to get to you, but you aren’t there. You are still at home and haven’t moved at all. All packets that should happily route to you now route elsewhere.

Emails sent to you bounce as undeliverable or are read by other people. Banking transactions fail. HTTPS handshakes get invalid certificate errors. This defeats the confidentiality, integrity, and availability of all applications running in the hijacked address spaces for the time that the hijack is running.

In fact, this sounds like a nifty way to attack an organization, doesn’t it? The question then would be how to pull it off, hijack someone else’s address? The Autonomous System (AS) in question is owned by NedZone Internet BV in the Netherlands.

This can be found by querying whois for the AS 25459. According to RIPE this AS originated 369 prefixes in the last 30 days, of these 310 had unusually small prefixes.

Typically, a BGP advertisement is at least a /24 or 256 unique Internet addressable IPs. A large number of these were /32 or single IP addresses. The short answer is that any Internet Service Provider (ISP) that is part of the global Border Gateway Protocol (BGP) network can advertise a route to a prefix that it owns. It simply updates the routing tables to point to itself, and then the updates propagate throughout the Internet. If an ISP announces for a prefix, it does not own, traffic may be routed to it, instead of to the owner.

The more specific prefix, or the one with the shortest apparent route wins. That’s all it takes to disrupt traffic to virtually anyone on the Internet, connectivity and willingness to announce a route that does not belong to you. This is not a new attack, it has happened numerous times in the past, both malicious attacks and accidental typos have been the cause.

The announcements from AS 25459 can be seen at bgp.tools

A sampling of some of the owners of the IP addresses that were hijacked follow:
1  AMAZON-AES – Amazon.com, Inc.
2  AS-7743 – JPMorgan Chase & Co.
1  ASN-BBT-ASN – Branch Banking and Trust Company
2  BANK-OF-AMERICA Bank of America
1  CEGETEL-AS Societe Francaise du Radiotelephone S.A
1  FIRSTBANK – FIRSTBANK
1  HSBC-HK-AS HSBC HongKong
1  PFG-ASN-1 – The Principal Financial Group
2  PNCBANK – PNC Bank
1  REGIONS-ASN-1 – REGIONS FINANCIAL CORPORATION

Some on the list were owned by that ISP, the prefix size is what was odd about them. The bulk of the IP addresses were owned by various hosting providers. So, the question is:

What happened?

Makes you wonder about the fundamental (in)security of this set of experimental protocols we use called the Internet, doesn’t it?

Routing Security and traffic engineering scenario

The hum of the data center is a peculiar kind of silence. To the uninitiated, it is a wall of white noise—the mechanical respiration of ten thousand servers keeping the modern world exhaling data. But to those of us who live in the architecture of the “backbone,” that hum is a pulse. And on a Tuesday afternoon in early April, I watched that pulse skip a beat.

I was sitting in a darkened operations center, the glow of six monitors reflecting off a lukewarm cup of coffee, when the geography of the internet began to melt. It didn’t happen with a crash or a siren. It happened with a whisper in the Border Gateway Protocol (BGP)—the digital equivalent of a highway robber quietly swapping the road signs on the Interstate while the world was driving at eighty miles per hour.

To understand what I saw on my screen that day, you have to understand the fundamental fragility of how we move information. We tend to think of the internet as a solid, physical thing—cables under the ocean, satellites in the sky. But the “map” that tells data how to navigate those cables is based entirely on a series of polite, unverified conversations between routers.

The Protocol of Blind Trust

In the diagram I often use to train new analysts—the one currently pinned to my corkboard—the process starts simply enough. Look at the Green Path (Step 1). Under normal circumstances, an organization’s network, whether it’s a .com retailer or a .org non-profit, announces its presence to its Internet Service Provider (ISP). The ISP’s Border Router then tells the rest of the world: “I know where this organization lives. If you have a packet for them, give it to me.”

It is a system built on a 1980s-era handshake. When the internet was a small neighborhood of academic and military researchers, everyone knew everyone. You didn’t need to check an ID; you trusted that if a router said it owned a certain block of IP addresses, it was telling the truth.

But as I watched my monitors that Tuesday, I saw a Red Bolt (Step 2) strike that trust.

Somewhere, thousands of miles away, an Attacker’s Border Router began to scream. It wasn’t sending a virus or a brute-force login attempt. It was simply lying. It issued a BGP announcement to the global table that said: “Actually, I have a much faster, much shorter path to that organization’s network. Ignore the legitimate ISP. Send everything to me.”

In the world of networking, routers are programmed to be efficient above all else. They are like water; they always seek the path of least resistance. When the attacker’s ISP began to broadcast this “forged path,” the Rest of the Internet—the massive, cloud-shaped heart of our global connectivity—believed the lie. Within minutes, the digital traffic meant for a major financial hub began to veer off course.

The Invisible Interception

This is the moment where the terror of a BGP attack sets in. If a hacker breaks into your house, you might hear the glass shatter. If they hijack your BGP route, they haven’t broken into your house—they’ve convinced the post office that your house is now located in an abandoned warehouse on the other side of town.

As the traffic was diverted through the Attacker’s ISP Network, it hit Step 3: The Interception. On my screen, I could see the latency spikes. The data was no longer traveling in a straight line. It was being sucked into a vacuum.

The attacker, sitting behind a terminal represented by that hooded figure in the diagram, wasn’t just stopping the traffic. They were “grooming” it. Because the attacker now sat in the middle of the stream, every piece of data passed through their hands before being forwarded to its actual destination—the Outsourced Cloud Services.

This is the “Man-in-the-Middle” nightmare. When a user typed their password into what they thought was their company’s cloud portal, that password traveled through the attacker’s router first. The attacker could read it, copy it, and then pass it along to the real server so quickly that the user never even saw a loading wheel. It was a perfect, invisible heist.

When the Cloud Dissolves

But as the caption on my diagram warns: it gets worse. We have spent the last decade moving our lives into the cloud. We don’t just host websites there; we host our internal payroll systems, our private legal documents, and our encrypted communications. By forging the path between an organization and its cloud providers, an attacker doesn’t just steal a few passwords. They can deny access entirely.

Imagine a hospital that can no longer reach its patient records because a rogue router in a foreign country has “black-holed” the route. Imagine a government agency that can’t access its own internal email because the BGP path has been forged to lead to a dead end. In that moment, the organization is effectively erased from the internet. They are still there, their servers are still humming, but the “map” no longer includes them.

On that Tuesday, we managed to catch the hijack within twenty minutes. We coordinated with “upstream” providers to ignore the malicious announcements and re-establish the legitimate route. But those twenty minutes felt like hours. In that window, thousands of data packets—each containing a piece of someone’s digital life—fell into the hands of someone they were never meant to meet.

The Fragile Backbone

I often look at that diagram and think about how much we rely on the civility of machines. We have built a multi-trillion-dollar economy on a foundation of “Border Routers” that are essentially gossiping with one another about where to go.

The “BGP Attack” is a reminder that the internet is not a fortress; it is a series of interconnected villages. If one village elder decides to start giving bad directions, the entire traveler’s map becomes a work of fiction.

As I closed my terminal that night and finished my now-cold coffee, I couldn’t help but feel a sense of profound vertigo. We talk about “cybersecurity” in terms of firewalls and antivirus software—the locks on our doors. But BGP hijacking reminds us that the very ground our houses are built on can be moved if someone shouts a lie loud enough for the rest of the world to hear.

Комментарии

Leave a Reply

Your email address will not be published. Required fields are marked *