NETRESEC Network Security Blog - Tag : PacketCache

rss Google News

Remote Packet Dumps from PacketCache

PacketCache logo

This blog post describes how to dump a packet capture (pcap file) on a remote computer, which runs the PacketCache service, and retrieve that pcap file using only PowerShell.

PacketCache is a free Windows service that continously sniffs network traffic on all interfaces (Ethernet, WiFi, 3G, LTE etc) and maintains a cache of the most recent traffic in RAM. This enables incident responders to read PCAP data out of a PC's PacketCache, for example when an IDS or anti-virus alerts on something potentially malicious. Unfortunately, there is no central management tool for PacketCache, which means that the PCAP data has to be dumped locally at the PC that triggered the IDS or AV alert.

There are a few workarounds "hacks" available to solve this problem, but the most elegant solution is to leverage PowerShell Remoting / WinRM in order to trigger a remote PacketCache instance to create a PCAP file and then copy the PCAP file through the same PowerShell session. To make things even simpler we've created a PowerShell script that can be used to download a PCAP file from any machine running PacketCache. Okay, maybe not *any* machine, the script only works on PCs that you have admin credentails for. Nevertheless, here's how you run the script from a PowerShell prompt:

PS C:\> .\ReadRemotePacketCache.ps1 DESKTOP-LT4711 Administrator
[*] Dumping PacketCache at DESKTOP-LT4711
[*] Copying PCAP dump from DESKTOP-LT4711
[*] Remote PacketCache data saved to DESKTOP-LT4711_181112_1337.pcap
PS C:\>

The ReadRemotePacketCache.ps1 script can be downloaded from the PacketCache product page.


Configuring Hosts for PowerShell Remoting

If you have not previously set up your environment for PowerShell remoting, then you will need to follow these steps before invoking the "ReadRemotePacketCache.ps1" script as above.

On the remote PC, start PowerShell as administrator and enable PowerShell remoting with the "Enable-PSRemoting" command as shown here:

PS C:\> Enable-PSRemoting -SkipNetworkProfileCheck -Force
WinRM has been updated to receive requests.
WinRM service type changed successfully.
WinRM service started.

WinRM has been updated for remote management.
WinRM firewall exception enabled.
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely
to local users.

PS C:\>

Configuring TrustedHosts for Workgroups

You will also need to set up a trust relationship between the local and remote host. If the remote PC is member of an Active Directory domain, then this trust is already in place. However, if you're in a workgroup or the computers are not in the same domain, then you will need to set the TrustedHosts item like this on both the local PC and the remote PC:

PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts [IP or Hostname of the other PC]
PS C:\> Get-Item WSMan:\localhost\Client\TrustedHosts
PS C:\> Restart-Service WinRM

Note: if you need to dump PacketCache data from several remote hosts, then you can replace the IP/hostname with '*' to trust any PC or supply a comma separated list of individual hostnames or IPs to trust.

If you've configured TrustedHosts correctly, then you should be able to run the "ReadRemotePacketCache.ps1" script as shown previously. However, if the remote PC isn't in TrustedHosts, then you'll most likely get an error message like this:

PS C:\> .\ReadRemotePacketCache.ps1 10.0.13.37 Administrator
New-PSSession : [10.0.13.37] Connecting to remote server 10.0.13.37 failed with the following error message : The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

Automating Remote Artifact Collection

With PowerShell remoting in place you're not limited to just dumping packets from a remote PacketCache service, you can also dump the RAM or copy individual files from the remote computer. This comes in handy in order to implement an automated evidence/artifact collection, for example when a high-severity alert is received by your SIEM.

There are frameworks in place that can help with aquisition of memory and files, such as Matthew Green's Invoke-LiveResponse tool, which can dump memory with WinPMEM and leverage PowerForensics to enable remote raw disk access. Some organizations even start sniffing packets at events like this, but this will only capture the traffic from after a potential compromize. This is where PacketCache comes in, since it can allow you to retrieve packets ranging back as far as a couple of days before the alert.


Credential Theft

It is recommended to use unique passwords for each local account with administrator rights. This practice is extra important if you plan to log into a potentially compromized host using administrator credentails, as described in this blog post. You might also want to lock down the local admin accounts even further in order to minimize the consequences of the admin credentials falling into the wrong hands. See Microsoft's articles on "Local Accounts" and "Attractive Accounts for Credential Theft" for more recommendations regarding how to secure local admin accounts.


PacketCache is Free

CC BY-ND PacketCache is free to use, even commercially. It is released under a Creative Commons Attribution-NoDerivatives 4.0 International License, which means that you can copy and redistribute PacketCache in any medium or format for any purpose. You can download PacketCache here:

https://www.netresec.com/?page=PacketCache

The PowerShell script presented in this blog post is also shared under the same CC license and can be downloaded from the PacketCache product page.


Credits

I'd like to thank Dick Svensson for suggesting the use of PowerShell Remoting to read PacketCache data remotely!

Posted by Erik Hjelmvik on Wednesday, 14 November 2018 08:00:00 (UTC/GMT)

Tags: #Netresec#PCAP#PowerShell#PacketCache#Windows

Share: Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=18B9747


Reading cached packets with Wireshark

Would you like to sniff packets that were sent/received some minutes, hours or even days ago in Wireshark? Can't afford to buy a time machine? Then your best chance is to install PacketCache, which allows you to read OLD packets with Wireshark. Wireshark reading from PacketCache

We recently released a free tool for keeping a cache of recently sent/received network traffic in Windows. The tool, called PacketCache, is actually a Windows service that saves a copy of recent packets in RAM. The cached packets can be read simply by connecting to a named pipe called “PacketCache”, for example by using a PowerShell script as shown on the PacketCache page.

After talking to some Wireshark core developers at SharkFest Europe last week we managed to get Wireshark to read packets from PacketCache's named pipe stream. However, you will need to use Wireshark 2.3 or later to properly read from a named pipe. Unfortunately version 2.3 isn't scheduled for release until next summer (2017), so until then you'll have to use one of the automated builds instead. I usually go for the latest WiresharkPortable build, since it doesn't require installation. You can download the portable version of Wireshark 2.3 here:
https://www.wireshark.org/download/automated/win32/

Look for a file called “WiresharkPortable_2.3.[something].paf.exe”.

Follow these steps in order to read packets captured by PacketCache:

  1. Make sure you have Wireshark 2.3.0 (or later)
  2. Start Wireshark with admin rights (right-click > “Run as administrator”)
  3. Run Wireshark as administrator
  4. Press: Capture > Options
  5. Click “Manage Interfaces...”
  6. Select the “Pipes” tab
  7. Press the “+” button to add a named pipe
  8. Name the pipe “\\.\pipe\PacketCache” and press ENTER to save it
  9. PacketCache pipe interface added in Wireshark
  10. Press “OK” in the Manage Interface window.
  11. Wireshark with a PacketCache pipe interface
  12. Press “Start” to read the packets from PacketCache

Wireshark reading from PacketCache

The status field in Wireshark will say “Live capture in progress”, which is somewhat true. Wireshark will be updating the GUI live as packets are read from PacketCache, but the packets displayed can be several hours or even days old depending on when they were captured by PacketCache. The “live” capture will stop once all packets have been read from the PacketCache.

Posted by Erik Hjelmvik on Friday, 28 October 2016 14:50:00 (UTC/GMT)

Tags: #Netresec#PCAP#PacketCache#Wireshark#named pipe#SharkFest

Share: Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=16A1b89


PacketCache lets you Go Back in Time

PacketCache logo

Have you ever wanted to go back in time to get a PCAP of something strange that just happened on a PC?
I sure have, many times, which is why we are now releasing a new tool called PacketCache. PacketCache maintains a hive of the most important and recent packets, so that they can be retrieved later on, if there is a need.

Network forensics and incident response is performed post-event, but requires that packet have already been captured during the event to be analyzed. Starting a network sniffer after a suspected intrusion might provide useful insight on what the intruders are up to, but it is much better to be able to go back in time to observe how they gained access to the network and what they did prior to being detected. Many companies and organizations combat this problem by setting up one or several solutions for centralized network packet capturing. These sniffers are typically installed at choke-points on the network, such as in-line with a firewall. However, this prevents the sniffers from capturing network traffic going between hosts on the same local network. Intruders can therefore often perform lateral movement on a compromised network without risk getting their steps captured by a packet sniffer.

Logo for Back to the Future series logo - public domain

USB broadband modem, credit: Game Gavel (cc-by-sa-3.0)
Image by Game Gavel
We're now trying to improve the situation for the defenders by releasing PacketCache, which is a free (Creative Commons licensed) Windows service that is designed to continuously monitor the network interfaces of a computer and store the captured packets in memory (RAM). PacketCache monitors all IPv4 interfaces, not just the one connected to the corporate network. This way traffic will be captured even on public WiFi networks and Internet connections provided through USB broadband modems (3G/4G).

By default PacketCache reserves 1% of a computer's total physical memory for storing packets. A computer with 4 GB of RAM will thereby allow up to 40 MB of packets to be kept in memory. This might not seem like much, but PacketCache relies on a clever technique that allows it to store only the most important packets. With this technique just 40 MB of storage can be enough to store several days worth of “important” packets.

The “clever technique” we refer to is actually a simple way of removing packets from TCP and UDP sessions as they get older. This way recent communication can be retained in full, while older data us truncated at the end (i.e. only the last packets are removed from a session).

PacketCache services in services.msc

To download PacketCache or learn more about this new tool, please visit the official PacketCache page:
https://www.netresec.com/?page=PacketCache

PCAP or it didn't happen!

Posted by Erik Hjelmvik on Wednesday, 28 September 2016 11:45:00 (UTC/GMT)

Tags: #PacketCache#PCAP#NSM#forensics#Windows#sniffer#memory#DFIR

Share: Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=169d0d2

X / twitter

NETRESEC on X / Twitter: @netresec

Mastodon

NETRESEC on Mastodon: @netresec@infosec.exchange