One of the things that drives me nuts in the Windows community, articles found in help web sites included, is the idea that to solve any problem you need download something and run it. And ideally something off a shady site that must be run in Admin mode. Packet capturing is one example.
Yes, I do know of Wireshark, I like it a lot and think it is a brilliant program; the fact you can run it in Linux, OSX, and Windows is a nice touch. But, like everything else it has its place. So, where is that in my opinion? I think it is great for:
- Packet inspection in a nice visual way
- Following all the packets that make a stream. Ex: if you found a file being transfered, you can find every single packet involved.
- Packet filtering. yes, you can do that in tcpdump, but doing it visually and colourfully is so much nicer. Looking for a rogue DNS in a haystack of data? Just tell wireshark to mark any DNS response in purple!
- The massive list of non-TCP/UDP traffic (say, USB) it can handle.
- Deploying a tap or switch port mirror.
- Lots
- Having in your handy pentest/security laptop.
Now, where do I think it should not be used? Servers. The way I was taught in kitty school is that you should only install in the server the programs you need to provide the services said server is supposed to offer (and to secure that). For instance, some good explaining is required to justify running a VPN service in a web server specially in this age of containers. About normal packet capturing, I understand the occasional need for that in a server, but why installing wireshark in it? If its operating system is Linux, there is a perfectly good tcpdump avaiable: you install it, do what you need, and then remove it after the task is done; there is no need for leaving it in the server "just in case." But, what about a Windows server? There is no tcpdump port on it, so wireshark is the logical alternative.
Or is it? What if I told you Windows has a built-in solution?
Enter netsh trace, which allows you to record network traffic without downloading an extra program. It is not as sophisticated as tcpdump but if all we want is to capture packets, it work just fine. It is command line, but I think we can handle that. Here are the avaiable options:
PS C:\Users\user> netsh trace ? The following commands are available: Commands in this context: ? - Displays a list of commands. convert - Converts a trace file to an HTML report. correlate - Normalizes or filters a trace file to a new output file. diagnose - Start a diagnose session. dump - Displays a configuration script. help - Displays a list of commands. show - List interfaces, providers and tracing state. start - Starts tracing. stop - Stops tracing. To view help for a command, type the command, followed by a space, and then type ?. PS C:\Users\user>
Recording
The way I usuall start recording network traffic is (and, yes you need to run it as an Admin)
netsh trace start persistent=yes capture=yes tracefile=packets.etlWhere
- persistent: Keep on logging after a reboot. Default is persistent = no
- start: Start packet capture. To stop it, netsh trace stop.
- tracefile: Is the name (and path) of the file the packets will be saved to. If you just enter the filename, it is saved in the same directory/folder you ran the command from. It is comparable to the -w flag in tcpdump. I strongly suggest to save this file somewhere only you (or the Admin) has access to; there are very few times when having a packet capture file available for all makes sense.
Other useful options:
- maxsize: max size of log file before it gets overwritten. maxsize=250 (MB) is the default; if you set maxsize = 0 it would not stop filling it up until running out of disk space (unlimited).
Inspecting
When you finish capturing you will notice that you now have two new files:
Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 4/24/2017 3:59 PM 650033 packets.cab -a---- 4/24/2017 3:58 PM 524288 packets.etl
For this discussion we will only care about packets.etl. Next step is to take the file out of the server to a system where we can analyze it with wireshark (the right tool for the job). Unfortunatelty Wireshark as of the time this article was created (April 2017) can't read a .etl file; more info on a wireshark bug report that started on 2011 and was last updated 2 years ago. The only way I know to convert is using the Microsoft Message Analyzer, which means you need to install it, import packets.etl, and then export it (Save As->Export) as a .cap file. You could argue that if we have Microsoft Message Analyzer, there is no reason to add wireshark, but while I know how to use wireshark I only know how to use the Microsoft product to convert the packet to a format wireshark can use. I do wish there was a way to do this step from the command line; if someone knows, do post in the comments.
What about real time monitoring?
Do you remember the part about tap or switch port mirror? That is what I would do before putting wireshark in the server. If you have to install wireshark in the Windows server, do keep track of the extra programs you also need to install and ensure they are all removed after you are done.
