Skip to content

Packet Sniffing with Microsoft’s Network Shell (Netsh)

Let’s say you land on a box that has multiple users logged in (Citrix, RDS, etc). You’re either an admin, privesc to admin, or <DOMAIN>\Domain Users is part of the local Administrators group (yes, this actually happens).

Even though you’re an admin on the box, you’re trying to stay low key, but still want to perform passive recon to gather data. And since this is a high-traffic server, there’s a good chance that credentials are being used across plaintext protocols that could expand your access.

The good news is that there’s probably already a tool installed that does what you’re looking for. Network Shell (Netsh.exe) has been included with Windows operating systems since Windows 2000, and is a command-line utility that allows admins to view or modify the network configuration of a local or remote system. In short, there’s a lot it can do, but we’re going to focus on the trace function in this post.

C:\WINDOWS\system32>netsh trace start help

Defaults:
capture=no (specifies whether packet capture is enabled
in addition to trace events)
capturetype=physical (specifies whether packet capture needs to be
enabled for physical network adapters only, virtual switch
only, or both physical network adapters and virtual switch)
report=no (specifies whether a complementing report will be generated
along with the trace file)
persistent=no (specifies whether the tracing session continues
across reboots, and is on until netsh trace stop is issued)
maxSize=250 MB (specifies the maximum trace file size, 0=no maximum)
fileMode=circular
overwrite=yes (specifies whether an existing trace output file will
be overwritten)
correlation=yes (specifies whether related events will be correlated
and grouped together)
perfMerge=yes (specifies whether performance metadata is merged
into trace)
traceFile=%LOCALAPPDATA%\Temp\NetTraces\[sessionname]NetTrace.etl
(specifies location of the output file)
providerFilter=no (specifies whether provider filter is enabled)
sessionname='' (specifies a name for the trace session so that
simultaneous traces can be collected.

There’s a few options to tinker with, but to keep it simple for this example, we can start and stop a capture with:

- netsh trace start capture=yes persistent=no tracefile=%LOCALAPPDATA%\temp\tracetest.etl
- netsh trace stop

Netsh captures and stores the data into a trace log with an ETL extension. There’s a few ways to view the data; each requiring the installation of Microsoft Message Analyzer (MMA) on your system or a VM.

  • You can open the file in in MMA and just use MMA to view the data. Fair warning: it’s clunky and slow.
  • You can open the file in MMA, then export it as a .cap by going to File > Save As > Export, then open the .cap in Wireshark.
  • You can use PowerShell to convert the .etl to a .cap using the following snippet:
Import-Module PEF
$x = New-PefTraceSession -Path “C:\output\path\out.cap” -SaveOnStop
$x | Add-PefMessageProvider -Provider “C:\input\path\in.etl”
$x | Start-PefTraceSession

Once converted, open the .cap in Wireshark and apply filters like you normally would to view the data:

The only downside to this is that it requires admin privileges on the system. But don’t dismiss it just because of that; it’s still a great way to quietly perform recon, capture creds, etc.

Enjoy!

Published inUncategorized

Be First to Comment

Leave a Reply

Your email address will not be published.