In the previous article, we investigated how to use PKTMON to conduct real-time troubleshooting on the command line. At other times, we might need to analyze the captured frames offline. Such an analysis could involve loading a capture file into tools such as Wireshark.
Traditionally in Windows, to capture network frames on a live system, the administrator would first be required to install 3rd party software, e.g., Wireshark, and filter drivers, such as PCAP or NPCAP.
Often, an organization’s change-control policies will not allow software installation without the stipulated procedures of approval. In Windows Server 2019 and 2022, as well as on client system Windows 10 and 11, a native tool is included in the operating system for out-of-the-box packet capturing. This tool is called PKTMON.
This tool can be used to display frames live on the command line, explained here, or to collect packets into a file that can later be imported into Wireshark on a secondary system.
This article will describe the process of capture to a local file and then convert into a Wireshark readable format.
To capture data for offline analysis, four prerequisites must be met:
1. Correct filters applied.
2. The internal ID number for the network interface card acquired.
3. Knowledge of the correct command-line parameters to initiate the capture into the file.
4. Use the command line to convert the captured data to the PCAP format.
Start an elevated Command Prompt or Powershell Window.
Before proceeding to conduct any packet capture, ensure you have a solid understanding of how to construct filters. Please see this article for all details.
Add the filters suitable for the upcoming capture.
Note, it is possible to capture without any filters applied. However, the result is highly likely to be overwhelming, e.g., including all the RDP packets of the administrative session itself. Nevertheless, situations could occur where a no-filter approach is required, for example, if we lack any clues on what kind of traffic/ports a specific application uses.
Secondly, we must locate the internal ID for the network adapter where the capture will occur. If omitting this step, we will experience multiple duplicates of each network packet captured.
This ID could be found by the command:
pktmon comp list
Make a note of the ID number to the left of your network adapter. This number can change between server reboots and is not guaranteed to be persistent.
Ensure not to use C:\Windows\System32 as the working directory in the Command Prompt / Powershell.
Temporary files will be created. We should not insert those into the critical System32 folder.
Navigate to a proper location in the filesystem, e.g., CD \tmp.
If no temporary folder exists, create a new one with a proper name.
Verify that the proper filters are loaded with the command:
pktmon filter listDecide upon the filename for the new capture file. The initial file format must be the ETL format. We will convert this file type into Wireshark format after the capture.
The filename could be, for example, “capture-1.etl“.
Start the capture with the following command-line parameters:
pktmon start -c --pkt-size 0 -f capture-1.etl --comp <interface>(If the output states that PKTMON is already running, use: pktmon stop )
Explanations for the command-line parameters:
-c Enable the capture.
––pkt-size By default, only the first 128 Bytes of each frame are obtained. To be able to properly analyze the packet content, the entire frame must be acquired. With the specified size of zero, the entire frame is collected, no matter the size.
-f The filename for this capture. By default, this name will be pktmon.etl. However, this will result in the files being overwritten if multiple captures are conducted. If specifying unique file names, no data will be lost.
––comp The network interface where the capture is applied. The number is obtained by the command “pktmon comp list“. If omitting this parameter, duplicates of packets will be captured, leading to confusion and a more difficult analysis process.
Ensure the capture starts. Note that the command prompt is “released” while the capture is running. The administrator can run arbitrary commands while still capturing packets.
To investigate whether packets have yet occurred that match any of the filters, run the following command:
pktmon countersIf the output informs you that the counters are zero, no hits have yet occurred.
Once at least one packet has been found that matches the current filters, the output will display the number of incoming (RX) and outgoing (TX) packets.
If you want to, it is possible to watch the counters increase live. Run the following command:
pktmon counters --live --refresh-rate 1Exit the live view with CTRL+C. Note that this will not end the packet capture itself.
When it is likely that the relevant data has been captured, stop the recording by the command:
pktmon stop
pktmon etl2pcap capture-1.etl -o capture-1.pcapNote that the first filename is the name of your file specified in the initial capture command. The second parameter is the output file, which could be named any arbitrary filename with the PCAP suffix.
The new PCAP file is often more compact in size.
Note that currently, the conversion from the ETL format into PCAP is only possible for packets captured on a wired Ethernet interface, but not wireless. If converting from a wireless capture, the result will, unfortunately, not be readable in Wireshark.
For convenience, you can omit the -o parameter. If so, the new file will be created with the same file name as the first file, but with the new extension. Note, that if the destination file already exists, the previous one will be overwritten.
pktmon etl2pcap capture-1.etlThe original ETL file is not removed by the conversion.
The new PCAP file could now be copied to a secondary machine with the full Wireshark application installed. Here it can be loaded and analyzed in depth with all the great capabilities of Wireshark.
Additional options:
By default, while recording, the capture file can increase up to a maximum of 512 MB. When this size is reached, the default behavior is to overwrite the oldest entries. If the capture runs long enough, data loss will occur.
To paraphrase the alleged quote: “512 MB ought to be enough for anybody“.
Most often, the default capture log size of 512 MB should be sufficient for the number of frames required for troubleshooting. However, if required, additional log size could be retrieved by the following options:
Option 1: Add the parameter -s with the desired number of Megabytes. For example:
pktmon start -c --pkt-size 0 -f capture-1.etl --comp <interface> -s 1000The capture file can now increase in size up to 1000 MB before the oldest entries are overwritten.
Option 2: Give PKTMON the ability to create additional log files if required.
This option is enabled by adding the option ––log-mode multi-file to the command line.
Note that this option must be used with caution. Once the log size reaches its maximum, new files will automatically be created. If the capture is left unattended, the log files could potentially consume all space on the server’s hard drive.
Note that logging off the active user will not stop a running capture.
Always ensure to properly stop any started capture. You can halt the capture with:
pktmon stopIf, in any given point in time, being uncertain whether a capture is currently running, use:
pktmon statusFor any questions or remarks, please leave a comment below.
To view network counters live on the command line, see the next part of the series.