Editing, adapting and replaying PCAP'ed traffic.

obuno | | 4 min read
Editing, adapting and replaying PCAP'ed traffic.

Today I'll slightly divert from the usual Fortinet articles. I've been recently tasked with the analysis of a 3rd party provided network traffic trace. The task consisted of replaying captured traffic through a FortiGate in order to potentially match and report detected Application Control signatures.

After some researches, I've found out about a few tools which would enable me to do so. And these are the tools: tcpprep, tcprewrite and tcpreplay.

Now, given that the handed over PCAP's traces were captured within a given scheme, with its own actors, I needed a way to change many things within the PCAPs in order to possibly replay them.

  • swap destination MAC addresses Server/Client side
  • swap Server MAC address
  • swap Client MAC address
  • swap Server IP
  • swap Client IP

Frankly, I'm certainly not a Wireshark expert or an everyday network analyst. Though I've found ways to do the needed changes. There might be more efficient and elegant ways getting out with this, although, that's how I managed it.

1st I've used tcpprep in order to establish a "cache" file of the conversations within the PCAP. The purpose of tcpprep is to create a cache file which is used to “split” traffic into two sides (often called primary/secondary or client/server).

This is how I've obtained the cache file of the handed over pcap file.

tcpprep --auto=bridge --pcap=case1.pcapng --cachefile=case1.cache

Rewriting Layer 2

Once we have that cache file, we can start a few in flesh manoeuvres on the given PCAPs. For this purpose, I've been using the tool named tcprewrite:

Running tcprewrite requires you to provide it an input pcap file and the name of the output pcap file (which will be overwritten).

|=-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------=|
|=-------------=[ Server-side router MAC,Client side router MAC ]=---------=[ Server MAC,Client MAC ]=-------------------------------------------------------------------------=|
tcprewrite --enet-dmac=00:09:xx:xx:xx:xx,00:09:xx:xx:xx:xx --enet-smac=11:11:11:11:11:11,22:22:22:22:22:22 --cachefile=case1.cache --infile=case1.pcap --outfile=case1rw-mac.pcap

The most common layer 2 rewriting needs are to change the source and destination MAC addresses of packets so that they will be processed by the correct device. By using the --enet-dmac and --enet-smac options you can specify what the new destination and source MAC addresses should respectively be.

the --enet-dmac in the provided example above reflects to router MAC addresses present on each side of the communications. The important thing here is to remember that the first MAC addresses listed for the dmac/smac flag is for Server traffic and the second addresses are for Client traffic.

tcprewrite offer plenty more L2 options, 99% of which i haven't yet experimented with.

Rewriting Layer 3

tcprewrite supports both IPv4 and IPv6 addresses. There are a number of methods for rewriting IP addresses depending on your needs. When enabling a layer 3 rewrite rule, tcprewrite will automatically re-calculate checksums for you, so there is no need to pass --fixcsum.

Not only do the following options edit the IP header, but in the case of IPv4, it also modifies ARP requests/replies to match as well.

I've chosen to be stateful with my change requests, there might be something more straight forward ( --endpoints ?) although here is what I've requested to tcprewrite:

|=------------------------------------------------------------------------------------------------------------------------------------=|
|=------------------------------------------------------------------------=[ org src IP:new src IP ]=-------=[ org dst IP:new dst IP -=|
tcprewrite --infile=case1rw-mac.pcap --outfile=case1rw-temp.pcap --srcipmap=192.168.1.2:10.2.2.242 --dstipmap=192.168.1.3:10.3.3.242
tcprewrite --infile=case1rw-temp.pcap --outfile=case1rw-ip.pcap --srcipmap=192.168.1.3:10.3.3.242 --dstipmap=192.168.1.2:10.2.2.242

Now the outfile in my example named case1rw-ip.pcap is our final edit and we've changed source MACs, destinations MACs, source IPs, destination IPs.

Splitting our PCAP to Server/Client outputs

The last move we need is now to split our rewritten PCAP file according to each respective communicator. To do so, I found a small Windows based tool called SplitCap. I'm sure there shall be something available and compiled for *nix kernels although, SplitCap made the job for me.

SplitCap -r case1rw-ip.pcap -s mac

This rendered 4 files from my given PCAP, a Server MAC file, each router MACs in two dedicated files and finally the Client MAC extracts.

Replaying the traffic with tcpreplay

Now that everything is in place, we are good to go and replay the given traced packets in our own controlled environment. I've replayed the traffic from two Kali based hosts using both Server and Client PCAPs obtained previously.

kali1#: tcpreplay --pps=5 -v --intf1=eth0 case1rw-ip-111111111111.pcap
kali2#: tcpreplay --pps=5 -v --intf1=eth0 case1rw-ip-222222222222.pcap

The final output of a MultiExec session on both the Kali hosts:

And below is a snippet of what the given traffic has been triggering while hitting a monitor all Application Control Security Profile on the access granting IPv4 FortiGate policy.

In the hope that you've found this useful.

About this ghost blog server

I thought about inserting a comments section on this blog but finally revised my mind. Hence, if you want to contact me, you'll be able to send me good old email, to the address available on my profile.

Thanks,
Obuno

Share:
Show Comments