When looking through packet captures, I like to look for packets with strange characteristics. Odd header values, packets that are very big, maybe too small, unexpected replies, or other oddities are very interesting to me. A couple of months ago I was reviewing some pcap files and noticed some very small ICMP echo request packets.

The above tcpdump command reads (-r) the interesting.pcap file, suppresses port and address name resolution (-n) and I've limited this output to 10 packets (-c10). The BPF (Berkeley Packet Filter) is looking in the second byte offset from zero of the IP header for two bytes (offsets 2 and 3) and checking to see if the value is less than 40. This is the IP total length field which is the total packet length, including the IPv4 header.

It is suspicious to me to see ICMP echo requests with a payload this small. Nmap and some packet crafting tools will default to no payload but those would also be suspicious unless coming from an approved host. There are some Domain Controller to Domain Controller ICMP echo requests that only have a single byte payload ("?") but this is internal to external IPs.

So, what is normal? With Linux and BSD style systems, I generally expect to see a payload that includes a set of incrementing hex values like:

For normal Windows hosts, I would expect the payload to be characters "a" through "w" followed by "a" through "i" like:

The hosts generating the odd echo requests are Windows systems but the payload looks nothing like above:

This payload is only two null bytes or 0x0000. This is calculated by taking the total length of 30 bytes minus the IP header length of 20 bytes minus the ICMP header length of 8 bytes (30 - 20 - 8 = 2). The additional 16 zero bytes are the result of padding because this frame did not meet the minimum Ethernet length of 64 bytes. Interesting…but knowing these are Windows hosts, check out the IP TTL in offset 8 of the IP header (ip[8]):

Twenty-eight. Isn't that odd? These hosts are two hops away from this capture point which would make this an initial TTL of 30. The TTL of 30 was also confirm during research when trace files were pulled off some of the suspicious hosts. Windows systems generally have a default TTL of 128. Yes, there are Windows version like Win95, NT3.51, and NT4SP1+ that have an initial TTL of 32 but these hosts are Windows 10. 😁

So, we have Windows hosts sending two byte ICMP echo requests with odd TTL values towards the internet…but wait, there's more…did you notice a peculiar pattern in the source and destination IP addresses? Before pointing it out, let's run through normal ICMP echo request behavior.

ICMP echo requests (type 8, code 0) are sent from a source IP address to a destination IP address and replies (type 0, code 0) reverse the source and destination IPs sending the same payload back to the original sending IP. In addition to the type, code and checksum fields, the ICMP echo request header also contains an identifier and sequence number. The identifier and sequence numbers may (the word "may" is from RFC-792) help match the sent echo request with the reply. The pattern is normally a single source IP to a single destination IP with an identifier that stays the same for the set of packets. The sequence number increases for each request sent in the set which makes it possible to see if a particular request or reply didn't return. For example, notice the IPs and identifier stay the same but the sequence number increases for each sent request:

The operating system would be able to tell which reply didn't make it back based on the missing sequence number. Can you see the odd pattern in the suspicious echo requests now? Let me help:

For each ICMP echo request sent, these systems are sending to three different destination IP addresses but utilizing the same identifier and the sequence numbers are incrementing like a single session. That is very strange to me.

All of the observed destination IP addresses were Microsoft addresses. Trace data was pulled from some of the suspicious hosts and the applications generating these packets were Office 365 products. This reminded us that this team was in the process of migrating some services to O365. It was still odd but less concerning. The trace files, packet captures and a write up were bundled up and a Microsoft case was created. After a couple of months going back and forth, Microsoft did confirm these packets are for their Footprints telemetry data. The intention is to help measure latency. The Office 365 rich clients (Excel, Outlook, etc) call the Footprint SDK API on a background thread which is why the trace data showed Excel crafting packets. 🤭

What kind of strange packets are on your network? You are looking, right?

Andy Laman, a principal consultant with A4 InfoSec, has more than 25 years of information technology and security experience in multiple industries. Andy is a course contributor and teaches SEC503: Intrusion Detection In-Depth, for the SANS Institute. In addition to the CISSP, Andy holds multiple GIAC certifications including the prestigious GIAC Security Expert (GSE #142) certification as well as multiple other industry certifications.