All of us as a sniffer usually use ready-made programs. However, you can get by with the built-in Windows tools using PowerShell. In addition to the invention of the bike “because we can”, the scripts will be useful in automated traffic analysis scenarios.

Ready options

Before the invention of the bicycle, I will tell (or remind) a little about finished products intended for intercepting network traffic and subsequent analysis. Here are the main programs involved in traffic analysis.

Tcpdump Console and quite famous sniffer for UNIX-systems.


Ping 8.8.8.8 and admire the output of tcpdump.

Wireshark . Perhaps today it is one of the most famous cross-platform sniffers with GUI. You can use the LUA scripting language to expand its capabilities. It is also convenient for the program to analyze traffic captured on other devices in various formats.

We continue to ping 8.8.8.8, but we are already looking at using Wireshark.

Microsoft Message Analyzer (formerly Microsoft Network Monitor). In addition to the functions of the sniffer, it can analyze the messages of programs and devices, system events.

There are many possibilities, and therefore the interface is cumbersome.

Finally WinDump . Analogue tcpdump, but for Windows.

Separately, I note the sniffers on the network equipment. After all, it is much more convenient to watch traffic directly on the border router or switch than to stomp to a problem computer:

1. In Mikrotik routers, you need to look for a sniffer in Tools - Packet Sniffer.
   
   
   Sniffer on Mikrotik.
   ')
   A curious opportunity is streaming (Streaming), which allows sending traffic from a router directly to a computer running Wireshark .

   
   
2. DFL DFL routers also have a sniffer. Search Tools - Packet Capture.
   
   
   Sniffer in D-Link DFL .

Unfortunately, you can’t see the packages through the GUI, but you can download a traffic dump in .cap format and open it with the usual Wireshark analyzer or Microsoft Message Analyzer.

And now let's imagine that for some reason now the sniffer can not be downloaded right now, but the tool is needed - let's start the exercises with PowerShell.

"Powerful shell" to the rescue

The first version of this automation tool came out more than 10 years ago, so the syntax truths will not be repeated. But if you need a memo, I recommend starting with the official Microsoft site , where at the same time there is a gallery of ready-made scripts.

We will catch packages from the command line using the NetEventPacketCapture cmdlet set in Windows 8.1 / 2012R2. For example, let's say that on a computer with the name REIKO, the user is working in a terminal session - we will look at his work using PowerShell.

First, create a connection to the user's computer:

$Cim = New-CimSession -ComputerName 'REIKO' 

After that, create an event handler session:

 New-NetEventSession -Name "Session01" -CimSession $Cim -LocalFilePath "C:\Windows\Temp\Trace.etl" -CaptureMode SaveToFile 

And add an event provider:

 Add-NetEventProvider -CimSession $Cim -Name 'Microsoft-Windows-TCPIP' -SessionName "Session01" 

You can view all possible providers with the logman query providers command.

After that, it remains to run the trace:

 Start-NetEventSession -Name "Session01" -CimSession $Cim 

To stop, in the same command it is enough to replace Start with Stop.

The results can be viewed with the following command:

 Get-WinEvent -Path "\\REIKO\C$\Windows\Temp\Trace.etl" -Oldest 

As a result of the trace, it is clear that from a computer not only work on the terminal server, but also on the computer itself, someone is sitting in a local terminal session.

To automate the process of such a trace (hello to colleagues from the IB), the Dan Franciscus system administrator wrote an Invoke-PSTrace script.

 #requires -Modules NetEventPacketCapture function Invoke-PSTrace { [OutputType([System.Diagnostics.Eventing.Reader.EventLogRecord])] [CmdletBinding()] param( [Parameter(Mandatory=$true)] [string]$ComputerName, [switch]$OpenWithMessageAnalyzer, [pscredential]$Credential ) DynamicParam { $ParameterName = 'ETWProvider' $RuntimeParameterDictionary = New-Object System.Management.Automation.RuntimeDefinedParameterDictionary $AttributeCollection = New-Object System.Collections.ObjectModel.Collection[System.Attribute] $ParameterAttribute = New-Object System.Management.Automation.ParameterAttribute $ParameterAttribute.Mandatory = $true $AttributeCollection.Add($ParameterAttribute) $arrSet = logman query providers | Foreach-Object {$_.split('{')[0].trimend()} | Select-Object -Skip 3 | Select-Object -SkipLast 2 $ValidateSetAttribute = New-Object System.Management.Automation.ValidateSetAttribute($arrSet) $AttributeCollection.Add($ValidateSetAttribute) $RuntimeParameter = New-Object System.Management.Automation.RuntimeDefinedParameter($ParameterName, [string], $AttributeCollection) $RuntimeParameterDictionary.Add($ParameterName, $RuntimeParameter) return $RuntimeParameterDictionary } begin { $ETWProvider = $PsBoundParameters[$ParameterName] } process { #Remove any existing sessions Get-CimSession -ComputerName $ComputerName -ErrorAction SilentlyContinue | Remove-CimSession -Confirm:$False Get-NetEventSession -Name "Session1" -ErrorAction SilentlyContinue | Remove-NetEventSession -Confirm:$False Remove-Item -Path "C:\Windows\Temp\$ComputerName-Trace.etl" -Force -Confirm:$False -ErrorAction SilentlyContinue #Create new session try { $Cim = New-CimSession -ComputerName $ComputerName -Credential $Credential -ErrorAction Stop New-NetEventSession -Name "Session1" -CimSession $Cim -LocalFilePath "C:\Windows\Temp\$ComputerName-Trace.etl" -ErrorAction Stop -CaptureMode SaveToFile | Out-Null } catch { Write-Error $_ Break } Add-NetEventProvider -CimSession $Cim -Name $ETWProvider -SessionName "Session1" | Out-Null Start-NetEventSession -Name "Session1" -CimSession $Cim | Out-Null if (Get-NetEventSession -CimSession $Cim) { Read-Host 'Press enter to stop trace' | Out-Null } Stop-NetEventSession -Name 'Session1' -CimSession $Cim Remove-NetEventProvider -Name $ETWProvider -CimSession $Cim Remove-NetEventSession -Name 'Session1' -CimSession $Cim Remove-CimSession -CimSession $Cim -Confirm:$False if ($ComputerName -ne 'LocalHost') { Copy-Item -Path "\\$ComputerName\C$\Windows\Temp\$ComputerName-trace.etl" -Destination 'C:\Windows\Temp' -Force } Get-CimSession -ComputerName $ComputerName -ErrorAction SilentlyContinue | Remove-CimSession -Confirm:$False if ($OpenWithMessageAnalyzer) { Start-Process -FilePath 'C:\Program Files\Microsoft Message Analyzer\MessageAnalyzer.exe' -ArgumentList "C:\Windows\Temp\$ComputerName-trace.etl" } else { Get-WinEvent -Path "C:\Windows\Temp\$ComputerName-trace.etl" -Oldest } } } 

When you run the script, you can specify the name of the remote machine, the event provider, and, if necessary, open the trace in Microsoft Message Analyzer.

An example of the script.

Since you can use the .NET toolkit in PowerShell, even before the NetEventPacketCapture set of cmdlets appeared, the Get-Packet sniffer script appeared in the community. You can familiarize yourself with one of the variants of the modified script in the blog of the author, I will give an example of his work.

We ping and watch traffic with a PowerShell script.

Due to the use of methods, .NET works much faster than cmdlets, but creating it “on the knee” and without access to the Internet will not be easy. Nevertheless, this is a good alternative to proprietary programs.

Old CMD also does not miss

If you also like batch files, as I love them, you may be interested in tracing, without any PowerShell, the usual netsh.exe tools. In addition to creating, you can also convert the trace file from the .etl format into convenient formats like .txt and .html.

 @echo off rem   netsh trace start InternetClient provider=Microsoft-Windows-TCPIP level=5 tracefile=trace.etl > nul rem  5  timeout 5 > nul rem   netsh trace stop > nul rem   .etl   .txt,    Microsoft Message Analyzer netsh trace convert input=trace.etl output=trace.txt dump=txt > nul rem ,     RDP type trace.txt | findstr "3389" rem    del trace* 

More details on the netsh syntax for collecting traces can be found in the Microsoft documentation.

With CMD, the biggest disadvantage is that without additional utilities, it is not so easy to run the script, so PsExec.exe or the WMIC command should be kept at hand:

 wmic /user:"username" /password:"password" /node:"computer" process call create "sniffer.bat > log.txt" 

As a “homework”, I suggest that readers start collecting traces on a file server or a print server using the Microsoft-Windows-SMBServer event provider. Particularly interesting results come out if both SMB v1 and SMB v2 and later clients work with the server.