Akamai Diversity

Akamai Security Intelligence
& Threat Research

Hoffmeister.br Amplification Attacker: Sparks Inside the Network

Looking at the hoffmeister.be data (yes, our previously identified attacker fixed a typo in the TLD) and recent attempts at large-scale amplification attacks, I noticed a surprising absence of spoofed source addresses. My first thought was that the ISP forces the correct IP onto packets entering the network, but that is not common practice (illegal source address packets are dropped if you implement BCP38, SAVI and/or unicast RPF).

amp graph

The Y-axes represents the percentage of all queries that we observe; 0.11 means that at the peak, close to 11% of our sample of the queries worldwide were made to this amplification domain with ANY query.

Any source address validation is more effective than the ThreatAvert amplification attack protection from the targets perspective. If the carrier network allows spoofed addresses and the target is within the carrier's network, we do protect the target with Threat Avert. This should be a rare case. If the target is outside such a carrier's network, a properly set up CacheServe will drop all spoofed queries and protect the target even without ThreatAvert. So why use ThreatAvert? More importantly, why are we still seeing the queries and why do we see large amounts of them even in otherwise protected networks?

It turns out home routers are the reason. A spoofed packet that is sent to a router with address translation (NAT) will in most cases be forwarded with the router's outside address as source.

To test this I set up a UDP responder on a public system with netcat in a terminal window:

nc -4lu 5555

and for good measure listened to the traffic to that port. On a local system inside a NAT network I trick netcat to spoof a different address than the one assigned to the LAN interface:

ifconfig en0 alias
nc -u -s public.example.com 5555

This allows me to enter characters on the local system and receive them on the public server, and vice versa. So to summarize, public server is public.example.com, local router WAN interface is, internal legitimate network address is and internal spoofed address is The home router knows nothing of the network.

The result of the local system sending "test" to the local router with the spoofed source address

15:24:20.661842 IP > public.example.com.5555: UDP, length 5

which the router gladly does network address translation for, and we see the following packet arrive at the public system:

15:24:20.716712 IP > public.example.com.5555: UDP, length 5

Typing a similar message on the public system is lost, since the local router lacks a route for the network:

15:53:27.348626 IP public.example.com.5555 > UDP, length 5

with no traffic seen at the local machine.

It does, however, make it's way back to the router where it is seen on the WAN interface:

15:53:27.401464 IP public.example.com.5555 > UDP, length 5

Had this been an amplification attack domain, the actual payload sent to (and dropped by) the home router would be around 4k per query, and you only need around 30 thousand of those queries per second to fill up a Gigabit link . If your subscribers are connected with anything less than that, they will be miserable much sooner.

So even when a carrier implements all best common practices, and configure our (or other) resolvers correctly, there is still a significant amount of amplification attack data bouncing around inside the carrier network. It's not reaching it's intended target but it bypasses all other countermeasures, still fills up internal links with useless traffic and effectively DoS-ing the carrier's own (infected) customers. Ideally, home routers should not do NAT on addresses outside of the configured local network, but until that's fixed by the manufacturers, ThreatAvert will limit the impact on both the network and the subscribers - and as an added benefit also identify infected clients that would otherwise be invisible.

Leave a comment