No Wireshark? No TCPDump? No Problem!

No Wireshark? No TCPDump? No Problem!

Have you ever been on a pentest, or investigating a client issue, and the "following step" was to catch parcels on a Windows host? At that point you find that introducing winpcap or wireshark was essentially out of extension or overall not permitted on that SQL, Exchange, Oracle or other host? It used to be that this is the point at which we'd suggest introducing Microsoft's Netmon parcel catch utility, yet and, after its all said and done bunches of IT supervisors would waver about utilizing the "introduce" word in relationship with a discriminating server. Indeed, as is commonly said in systems administration (and security too), there's constantly an alternate way, and this is that way. 

"netsh follow" is your companion. Also yes, it does precisely what it seems like it does. 

Sort "netsh follow help" on any Windows 7 Windows Server 2008 or fresher box, and you'll see the accompanying:

C:\>netsh trace help

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.

Obviously, by and large, following everything on any generation box is not prudent - particularly in the event that its your primary Exchange, SQL or Oracle server. We'll have to channel the catch, more often than not to a particular host IP, convention or comparable. You can see all the more on this here:

netsh trace show capturefilterhelp

One of the examples in this output shows you how t o e.g. 'netsh trace start capture=yes Ethernet.Type=IPv4  IPv4.Address=157.59.136.1'

You could likewise include Protocol=TCP or UDP et cetera.. 

Full punctuation and notes for netsh follow can be found here: https://technet.microsoft.com/en-us/library/dd878517 

Case in point, the accompanying session reveals to me catching an issue with a firewall that I'm taking a shot at. Note that you require administrator rights to run this, the same as any catch device. In a pentest you would likely indicate a yield record that isn't in the clients' index.

C:\>netsh trace start capture=yes IPv4.Address=192.168.122.2

Trace configuration:
-------------------------------------------------------------------
Status:             Running
Trace File:         C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace
.etl
Append:             Off
Circular:           On
Max Size:           250 MB
Report:             Off

When you are done capturing data, it's time to stop it:

C:\> netsh trace stop
Correlating traces ... done
Generating data collection ... done
The trace file and additional troubleshooting information have been compiled as
"C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace.cab".
File location = C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace.etl

Tracing session was successfully stopped.

c:\

The cool thing about this is that it doesn't need a terminal session (with a GUI, cursor keys and so on).  If all you have is a metasploit shell, netsh trace works great!

If this is a capture for standard sysadmin work, you can simply copy the capture over to your workstation and proceed on with analysis.  If this is a pentest, a standard copy might still work (remember, we're on a Microsoft server), but if you need netcat type function to exfiltrate your capture, take a look at PowerCat (which is a netcat port in PowerShell).

Next, open the file (which is in Microsoft's ETL format) in Microsoft's Message Analyzer app - which you can install on your workstation rather than the server we ran the capture on ( http://www.microsoft.com/en-us/download/details.aspx?id=44226 ). Message Analyzer has a surprisingly nice interface and some decent packet parsing, you might be able to wrap up your analysis just in this tool (see below).

On the off chance that you do need an alternate parcel investigation instrument, its anything but difficult to a File/ Save As/ Export, and spare as a PCAP document that Wireshark, tcpdump, SNORT, ngrep, standard python or perl calls, or whatever other standard apparatus can read locally. 


Alternately you can change over to PCAP utilizing PowerShell (obviously you can). A short, straightforward script to do this may look like:

$s = New-PefTraceSession -Path “C:\output\path\spec\OutFile.Cap” -SaveOnStop
$s | Add-PefMessageProvider -Provider “C:\input\path\spec\Input.etl”
$s | Start-PefTraceSession

This Powershell cmdlet is not accessible in Windows 7 - you'll require Windows 8, or Server 2008 or more up to date 

(This script was found at http://blogs.technet.com/b/yongrhee/chronicle/2013/08/16/so-you-need to-utilize wireshark-to-peruse the-netsh-follow yield etl.aspx ) 

On the off chance that 'netsh follow' has tackled a fascinating issue for you, or was the apparatus that got you some intriguing information in a pentest, if its not too much trouble utilize our remark structure to tell us how you utilized it (inside your NDA obviously!)