QuickPcap – Capturing a PCAP with PowerShell

Earlier today I was asked for a ‘quick and easy’ PowerShell to grab a packet capture on a Windows box. I didn’t have anything on hand so I set off to the Google and returned with the necessary ingredients.

The star of the show is netsh trace, which is built into Windows. If we wanted to capture for 90 seconds, start the trace, wait 90 seconds, and stop it the syntax would be:

netsh trace start capture=yes IPv4.Address=192.168.1.167 tracefile=c:\temp\capture.etl
Start-Sleep 90
netsh trace stop
  • Note there are 3 lines (the first may wrap depending on windows size)

Like Wireshark, you need to specify what interface you want to capture traffic from. In the example above 192.168.1.167 is the active interface I want to capture. But what if I want to use this for automation and won’t know in advance what the active IP address will be?

We can grab the local IPv4 address and save it as a variable.

#Get the local IPv4 address
$env:HostIP = (
    Get-NetIPConfiguration |
    Where-Object {
        $_.IPv4DefaultGateway -ne $null -and
        $_.NetAdapter.Status -ne "Disconnected"
    }
).IPv4Address.IPAddress

Now putting the two together:

$env:HostIP = (
    Get-NetIPConfiguration |
    Where-Object {
        $_.IPv4DefaultGateway -ne $null -and
        $_.NetAdapter.Status -ne "Disconnected"
    }
).IPv4Address.IPAddress
netsh trace start capture=yes IPv4.Address=$env:HostIP tracefile=c:\temp\capture.etl
Start-Sleep 90
netsh trace stop

Perfect. Automated packet capture without having to install Wireshark on the host. The only item you should need to adjust will be the capture (sleep) timer.

But wait, the request was for a pcap file. Not a .etl. Lucky for us there’s an easy conversion utility etl2pcapng. Execution is as simple as giving the exe the source and destination files.

./etl2pcapng.exe c:\temp\capture.etl c:\temp\capture.pcap

That’s it. We’re now able to collect a packet capture on Windows hosts without adding any additional tools. We can then take those collections and convert them with ease to everyone’s favorite packet analyzer.

I’ve combined everything above into QuickPcap.ps1 available on my GitHub site.

QuickPcap.ps1

In this case the capture and conversion are running as one contiguous process, but it’s easy to imagine them as separate automation elements being handled through scripting by different processes. After all, we all build our Lego’s differently, don’t we?

“The Game is On!”

Magnet Weekly CTF: Week 10 Solution Walk Through

This weeks challenge was another round of memory forensics. As with the previous weeks challenge most* of my solves were done using a REMnux VM. REMnux includes both Volatility 2.61 (SSL support deprecated) and the beta of Volatility 3.

Challenge 10, Part 1: At the time of the RAM collection (20-Apr-20 23:23:26- Imageinfo) there was an established connection to a Google Server. What was the Remote IP address and port number? format: “xxx.xxx.xx.xxx:xxx”

Using the netscan plugin for Volatility and then filtering for “established” we see 4 open connections. A whois lookup on the addresses indicates that 172.253.188 is affiliated with Google. The communications were traversing port 443.

Flag 1: 172.253.63.188:443

Challenge 10, Part 2: What was the Local IP address and port number? same format as part 1

Looking at our earlier output from netscan we see the source address was 192.168.10.146:54282

Flag 2: 192.168.10.146:54282

Challenge 10, Part 3: What was the URL?

So we know we’ve got an open connection to a remote host going on at the time the memory was captured. Looking at Passive DNS for the Google IP address I could see that it’s principally been associated with Google Chat related assets.

I ran the memory sample through Bulk Extractor to carve out a PCAP of any of the networking artifacts that were present in the image.

bulk_extractor to pcap

Once the pcap was carved I opened it with Wireshark.

Looking through the pcap we see that the client computer had received a DNS response for mtalk.google.com at 172.253.63.188

The question was looking for a URL so… https://mtalk.google.com – yes! [Flag 3]. Originally this answer wasn’t accepted. I later received an email that it was accepted as an alternate solution and to resubmit.

Challenge 10, Part 4: What user was responsible for this activity based on the profile?

The getsids Volatility plugin quickly yields the active user account.

Flag 4: Warren

Challenge 10, Part 5: How long was this user looking at this browser with this version of Chrome? *format: X:XX:XX.XXXXX * Hint: down to the last second

This one had me stumped for a while. I first tried calculating the delta between when the chrome process was started to the time the image was acquired. (Nope)

Eventually I succumbed and took the hint which had to do with “FOCUS”. Another clue that I’d heard on Discord was that this was ‘VERY easy to solve in Axiom.’

Sure enough, stacking filters for Chrome and Focus and restricting the search to the Memory evidence yields a Registy artifact indicating that the focus time for Chrome was 3:36:47.301000. Oh but don’t just copy paste here without checking the question for the flag format. There’s only 5 places after the last decimal. So for Flag 5 the answer is 3:36:47.30100.

I was victorious in getting all 5 flags, but this has been just as much about learning as it has been about the friendly competition. So now that I knew the answer and where relatively it could be found in the evidence, I wanted to see if I could solve it just with REMnux as I had the other challenge elements.

I ran the timeliner Volatility plugin and exported the output file to .xlsx. format.

This took a few minutes to process. Once complete, I opened timeliner.xlsx.

Flag 5 (alternate) 3:36:47.30100

If we filter the Item column for Chrome and the Details column for Focus – there again the same result – 3:36:47.30100. Don’t forget to drop the last zero for the Flag.