Today I was using a combination of dumpcap and Wireshark to run a network forensics investigation against a server that may have been compromised. A couple of malicious files had been reported by the virus scanner, so I had to take a closer look at what it was doing in the network. Actually, dumpcap was already running for a couple of days in front of the firewall using a capture filter set to the server IP, recording everything that the server sent or received to and from the internet. So basically I wanted to separate good from bad traffic, if any, and see what was transferred.

First, I used the conversation statistics to get an idea of who the server was talking to. I had opened the trace and activated Network Name Resolution which I usually do not have enabled, but for an investigation like this it is quite helpful. Especially when most of the connections look like this (actually, it had the public IP of the server in them, but I sanitized the file, replacing the address with “10.0.0.21”):

It basically turned out that most of the connections were just updates for the virus scanner and other components that turned out to be non-malicious. There also was a ton of 1 packet incoming communication attempts that had been dropped by the firewall, which I ignored. So the next thing I did was searching for outgoing connections, especially using the TCP protocol, to see if anything was sent to a destination I didn’t like. The filter I used was “ip.addr==10.0.0.21 and tcp.flags.syn==2” to get all SYN packets coming from the server, and it gave me more of the connections to microsoft, avira and so on. While looking through the filter results I found no trace of the system being compromised, but one packet caught my eye for being not that commonly found in a trace these days:

So, to investigate the packet further – just for the fun of it – I decided to extract the relevant packets to a smaller file by using the “Export specified packets…” option from the file menu and stored them into a new pcapng file. So far so good. But when I tried to open the new file Wireshark told me this:

I was quite surprised for a moment since I had loaded the much larger trace without a problem. Then I realized that I had used dumpcap to write the file, so it had never been saved by Wireshark itself, and thus there was no Name Resolution Block (NRB) in the original file. Name Resolution Blocks contain FQDNs and IP addresses that had been known to Wireshark at the time of saving the file, which is a big advantage of the new PCAPng file format. You can open the file at a different location and still have the name resolution working – but in this case it worked against me.

First, I wanted to check if the error message was telling the truth, so I fired up my own trace file modification tool and checked the file structure in the structure viewer. And there really was an entry in the Name Resolution Block that had an empty FQDN:

Okay, so next thing to do was to find out how that empty FQDN got into the file in the first place. So I started Wireshark again and loaded the original file (without the NRB). Then I started another Wireshark instance and captured what my PC was doing. By the way, if you ever get to the level that you use Wireshark to capture what Wireshark is doing, one thing is certain: you’re not a beginner anymore 🙂

I toggled Network Name Resolution on the first Wireshark, which led to a ton of PTR records being queried from the DNS server. When it was done I stopped the running capture of the second Wireshark to look at the name resolutions, and found the guilty one. It looked like this:

So the answer for the PTR query was a single byte set to zero, which Wireshark seems to take as a “valid” FQDN and write it to the NRB. Which means that it can’t be opened anymore.

So why do I care about something like a stupid PTR query that makes trace files “unreadable”? Well, let’s say I prepare my own DNS server so that it will answer to PTR records with a zero byte for the name just as seen in the trace. I could now spoof sending IP addresses for packets that I send to systems someone is capturing traffic for, and as soon as Wireshark saves the file (which requires manual work, I know, because the dumpcap process will write it without NRB in the first place) it cannot be opened anymore unless someone is leveraging file level hex editing foo. Sort of a “Name Resolution Denial of Service file loading” 🙂

Leason learned: be careful when enabling network name resolution before saving a file, and: always keep the original capture files so that you can go back to square one.

Anyway, I think I’ll head over to bugs.wireshark.org now and open a new bug…

Update: thanks to Guy Harris for fixing the problem! As of build 49854 Wireshark works without a problem.