Subscribe to receive notifications of new posts:

DDoS Packet Forensics: Take me to the hex!


4 min read

A few days ago, my colleague Marek sent an email about a DDoS attack against one of our DNS servers that we'd been blocking with our BPF rules. He noticed that there seemed to be a strange correlation between the TTL field in the IP header and the IPv4 source address.

CC BY 2.0 image by Jeremy Keith

The source address was being spoofed, as usual, and apparently chosen randomly, but something else was going on. He offered a bottle of Scotch to the first person to come up with a satisfactory solution.

Here's what some of the packets looked like:

$ tcpdump -ni eth0 -c 10 "ip[8]=40 and udp and port 53" > x.x.x.x.53: 65098+ > x.x.x.x.53: 65101+ > x.x.x.x.53: 65031+ > x.x.x.x.53: 65072+

$ tcpdump -ni eth0 -c 10 "ip[8]=41 and udp and port 53" > x.x.x.x.53: 65013+ > x.x.x.x.53: 65019+ > x.x.x.x.53: 64925+ > x.x.x.x.53: 64914+

$ tcpdump -ni eth0 -c 10 "ip[8]=42 and udp and port 53" > x.x.x.x.53: 64439+ > x.x.x.x.53: 64271+ > x.x.x.x.53: 64182+ > x.x.x.x.53: 64442+

I've removed the destination IP address, but left in the DNS ID number (the number with the plus after it), the spoofed source IP, and port. There are three different TTLs represented (40, 41, and 42) by filtering on ip[8].

Stop reading here if you want to go figure this out for yourself.

Into the hex

I couldn't resist Marek's challenge, so I did what I always do with anything involving packets: I went straight for the hex. Since Marek hadn't given me a pcap, I manually converted the first few to hex.

The reason hex is useful is that bytes, words, dwords, and qwords are the real stuff of computing and looking at decimal obscures data.

Taking the first three (one for each TTL), I saw this pattern:

Converted to hex they are

It's immediately obvious that the 'random' source port is the first two bytes of the random IP source address reversed: has source port b501.

A little bit of tinkering revealed a relationship between the TTL and the first byte of the IP address.

TTL = first byte >> 1 + 40

This relationship was confirmed by a later packet that had a TTL of 150 and a source IP of The shift right also explained why the same TTL was used when the first byte differed by one (see the third group above for an example: 4.x.x.x and 5.x.x.x have the same TTL).

I then spotted that the DNS ID field was also related to the IP address. > x.x.x.x.53: 65098+

Converted to hex: > x.x.x.x.35: fe4a+

It's probably not obvious at first glance (unless you're a hex-level hacker), but fe4a is the one's complement of 01b5. So the DNS ID field was simply the one's complement of the first two bytes of the source IP.

Finally, Marek gave me a pcap, and I had one more relationship to find. The ID value in the IPv4 header was also related to the random source IP address—in fact, it was just the first two bytes of the IP address.


One mystery remains (and there's a CloudFlare T-shirt for person with the most convincing explanation): How are the random source IPs being generated?

The answer might be boring (i.e. it might just be reading bytes from /dev/random), but given the author's love of relationships between fields, perhaps there's something else going on. We've seen IP addresses get reused which leads us to think that there's something to discover here.

Here's a sequence of actual source IPs seen:

We have no real guarantee that the attacker generated them in this order, but perhaps there's an interesting way these are being generated.

Answers in comments if you manage to figure it out!

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.

Follow on X


Related posts

June 23, 2023 1:00 PM

How we scaled and protected Eurovision 2023 voting with Pages and Turnstile

More than 162 million fans tuned in to the 2023 Eurovision Song Contest, the first year that non-participating countries could also vote. Cloudflare helped scale and protect the voting application, built by using our rapid DNS infrastructure, CDN, Cloudflare Pages and Turnstile...