Detecting PureLogs traffic with CapLoader

CapLoader includes a feature for Port Independent Protocol Identification (PIPI), which can detect which protocol is being used inside of TCP and UDP sessions without relying on the port number. In this video CapLoader identifies the C2 protocol used by the PureLogs Stealer malware.

The PureLogs protocol detection was added to CapLoader in the recent 2.0 release.

The PCAP file analyzed in the video is from Brad Duncan’s fantastic malware-traffic-analysis.net website.

Indicators of Compromize (IOC):

• mxcnss.dns04.com:7702
• 176.65.144.169:7702

Posted by Erik Hjelmvik on Monday, 09 June 2025 14:26:00 (UTC/GMT)

Tags: #CapLoader​ #malware-traffic-analysis.net​ #PIPI​

CapLoader 2.0 Released

I am thrilled to announce the release of CapLoader 2.0 today!

This major update includes a lot of new features, such as a QUIC parser, alerts for threat hunting and a feature that allow users to define their own protocol detections based on example network traffic.

User Defined Protocols

CapLoader's Port Independent Protocol Identification feature can currently detect over 250 different protocols without having to rely on port numbers. This feature can be used to alert on rogue services like SSH, FTP, VPN and web servers that have been set up on non-standard ports to go unnoticed. But what if you want to detect traffic that isn’t using any of the 250 protocols that CapLoader identifies? CapLoader 2.0 includes a fantastic solution that solves this problem! Simply right-click a flow containing the traffic you want to identify and select “Define protocol from flow”. This creates a custom local protocol detection model based on the selected traffic.

CapLoader’s protocol identification feature may seem like magic, but it actually relies on several different statistical measurements of the traffic in order to build a model of how the protocol behaves. It's possible to define a protocol model from just a single flow, but doing so may lead to poor detection results, which is why we recommend defining protocols from at least 10 different flows. You can do this either by selecting multiple flows or services before clicking “Define protocol from” or by adding additional flows or services to a protocol model at a later point by clicking “Add flow to protocol definition”.

More Malware Protocols Detected

There are several malware C2 protocols among CapLoader’s built-in models for protocol identification. The 2.0 release has been extended to detect even more malware protocols out of the box, such as Aurotun Stealer, PrivateLoader, PureLogs, RedTail, ResolverRAT, SpyMAX, SpyNote and ValleyRAT.

These protocols can now be detected using CapLoader regardless which IP address or port number the server runs on.

QUIC Parser

CapLoader now parses the QUIC protocol, which typically runs on UDP port 443 and transports TLS encrypted HTTP/3 traffic. CapLoader doesn’t decrypt the TLS encrypted HTTP/3 traffic though, it only parses the initial QUIC packets containing the client’s TLS handshake to extract the target domain name from the SNI extension and generates JA3 hashes and JA4 fingerprints of the client’s TLS handshake.

• Merlin C2 JA3: 203c2306834e5bf5ace01fb74ad1badf
• Merlin C2 JA4: q13i0311h3_55b375c5d22e_c183556c78e2

More Alerts

There’s a fantastic service called ThreatFox, to which security researchers, incident responders and others share indicators of compromise (IOC). Many of the shared IOCs are domain names and IP addresses used by malware for payload delivery, command-and-control (C2) or data exfiltration. Various IOC lists can be downloaded from ThreatFox, so that they can be used by a DNS firewall or a TLS firewall to block malware traffic. But the IOCs can also be used for alerting and threat hunting. CapLoader downloads two IOC lists from ThreatFox when the tool is started (the data is then cached for 24 hours, so that no new download is needed until the next day). Analyzed network traffic is then matched against these downloaded offline databases to provide alerts whenever there is traffic to a domain name or IP address that has been reported to be associated with malware.

We’ve also added two additional alert types in this release, one for anomalous TLS handshakes, and one for connections to suspicious domains. Both these alerts are designed primarily for threat hunting, since there’s a considerable risk that they will alert on legitimate traffic. The anomalous TLS handshake alert tries to detect odd TLS connections that are not originating from the user’s web browser or the operating system. The alert is triggered when such odd connections are made to domain names that are not well-known. This alert logic is designed to generically detect any TLS encrypted malware traffic, where the malware is using a custom TLS library instead of relying on operating system API calls for establishing encrypted connections. But this logic might also lead to false positive alerts, for example when legitimate applications use custom TLS libraries to perform tasks like checking a license or looking for software updates. The suspicious domain alert looks for connections to domain names like devtunnels.ms, ngrok.io and mocky.io, which are often used by APTs as well as crime groups.

Metrics for VPN Detection

CapLoader 2.0 displays the TCP MSS values on the Hosts tab. This value can help with determining if a host is behind a VPN. An MSS value below 1400 indicates that the host’s traffic might pass through some form of overlay network, such as a tunnel or VPN. Other indicators that can help identify VPN and tunnelled traffic is IP TTL and latency, which CapLoader also displays in the hosts tab.

Improved User Experience

A lot of effort has been put into improving the user interface and general user experience for this new CapLoader release. One very important user experience factor is the responsiveness of the user interface, which has been significantly improved. Actions like sorting and filtering flows, services or alerts in CapLoader now complete around 10 times faster than before, which is very noticeable when working with multi-gigabyte capture files. Another improvement related to working with large capture files is that CapLoader now uses significantly less memory.

The transcript window in CapLoader has also received a touch-up. There is now, for example a search box that allows you to quickly find a particular keyword in a TCP or UDP transcript (thanks to Allan Christensen at SektorCERT for the idea). Actions in the transcript window, such as changing encoding or flipping up/down between flows, now also complete much faster than before.

CapLoader automatically saves the packets from selected flows or services to a pcap file in the %TEMP% directory every time the selection changes. This pcap file can be accessed from the “PCAP” icon in the top-right of the user interface. Simply drag-and-drop from CapLoader’s PCAP icon to Wireshark or NetworkMiner to open the filtered traffic. Several users have requested the ability to also perform this drag-and-drop operation directly from the selected rows. I’m happy to say that this is now possible, but you have to perform the drag-and-drop with the middle mouse button (such as the scroll wheel). Users without a middle mouse button can drag-and-drop selected rows by holding down the Ctrl key while drag-and-dropping with the right mouse button instead.

Free Trial vs Commercial Version

Many of CapLoader’s features, such as port-independent protocol identification, are only available in the commercial version of CapLoader. But the free trial version of CapLoader does include new features like the QUIC parser and alerts for suspicious domains and alerts whenever a domain name is listed on ThreatFox.

Updating to CapLoader 2.0

Users who have already purchased a license for CapLoader can download a free update to version 2.0 from our customer portal or by clicking “Check for Updates” in CapLoader’s Help menu.

Posted by Erik Hjelmvik on Monday, 02 June 2025 13:47:00 (UTC/GMT)

Tags: #CapLoader​ #QUIC​ #Threat Hunting​ #ThreatFox​

Comparison of tools that extract files from PCAP

One of the premier features in NetworkMiner is the ability to extract files from captured network traffic in PCAP files. NetworkMiner reassembles the file contents by parsing protocols that are used to transfer files across a network.

But there are other tools that also can extract files from PCAP files, such as Wireshark and Zeek. The file extraction support in these alternative solutions sometimes complement and sometimes overlap with that of NetworkMiner. Either way it is good that there are multiple tools that are designed to perform the same task. This allows us to compare the output from the different implementations, for example if the results from one tool seems strange or is suspected to be incorrect or incomplete.

Tools that can reassemble and extract files from network traffic or PCAP files:

• Chaosreader (hasn't been updated since 2014)
• NetworkMiner
• Suricata
• tcpflow (-e all)
• Wireshark's Export Objects
• Zeek's extract-all-files.zeek

All of these tools can extract files from HTTP and FTP, but when it comes to other protocols the support varies. The following table summarizes which protocols each tool supports:

I’ve been quite forgiving when compiling the table above. Tools are listed as supporting a protocol even if they only work under very specific conditions. I don’t want to name-and-shame any tool, but I strongly recommend that you verify the tools you’re using by comparing what they extract to one or two alternative tools. As an example, some tools only support a few specific commands for the protocol they claim to support. Additionally, some tools only support file extraction in one direction for protocols like HTTP or FTP, even though these protocols are regularly used to download as well as upload files.

Posted by Erik Hjelmvik on Monday, 05 May 2025 16:05:00 (UTC/GMT)

Tags: #Extract​ #PCAP​ #NetworkMiner​ #Suricata​ #tcpflow​ #Wireshark​ #Zeek​ #FTP​ #HTTP​ #IEC-104​ #IMAP​ #LPD​ #LPR​ #njRAT​ #POP3​ #SMB​ #SMB2​ #SMTP​

Decoding njRAT traffic with NetworkMiner

I investigate network traffic from a Triage sandbox execution of njRAT in this video. The analysis is performed using NetworkMiner in Linux (REMnux to be specific).

About njRAT / Bladabindi

njRAT is a Remote Access Trojan (RAT) that can be used to remotely control a hacked computer. It has been around since 2013, but despite being over 10 years old it still remains one of the most popular backdoors used by malicious actors. Anti virus vendors usually refer to njRAT as Bladabindi.

njRAT Artefacts Extracted by NetworkMiner

NetworkMiner has a built-in parser for the njRAT Command-and-Control (C2) protocol. This njRAT parser kicks in whenever there is traffic to a well-known njRAT port, such as TCP 1177 or 5552, plus a few extra ports (like TCP 14817 that was used by the analysed sample). You’ll need NetworkMiner Professional to decode njRAT traffic to other ports, since it comes with a port-independent-protocol-identification (PIPI) feature that automatically detects the protocol regardless which port the server runs on.

As demonstrated in the video, NetworkMiner can extract the following types of artefacts from njRAT network traffic:

• Screenshots of victim computer
• Transferred files
• Commands from C2 server
• Replies from bot
• Stolen credentials/passwords
• Keylog data

Covered njRAT Commands and Plugins

These njRAT commands and plugins are mentioned in the video:

• CAP = Screen Capture
• ret = Get Passwords
• inv = Invoke Plugin
• PLG = Plugin Delivery
• kl = Key Logger
• Ex = Execute Plugin
• Ex proc = Process List
• Ex fm = File Manager

IOC List

• Sample (a.exe): cca1e0b65d759f4c58ce760f94039a0a
• C2 server: 5.tcp.eu.ngrok[.]io:14817
• njRAT inv (dll): 2d65bc3bff4a5d31b59f5bdf6e6311d7
• njRAT PLG (dll): c179e212316f26ce9325a8d80d936666
• njRAT ret (dll): ac43720c43dcf90b2d57d746464ad574
• Splitter: Y262SUCZ4UJJ

Posted by Erik Hjelmvik on Monday, 28 April 2025 06:00:00 (UTC/GMT)

Tags: #njRAT​ #NetworkMiner​ #REMnux​ #Video​ #videotutorial​​

How to Install NetworkMiner in Linux

This guide shows how to install the latest version of NetworkMiner in Linux. To install an older NetworkMiner release, prior to version 3.0, please see our legacy NetworkMiner in Linux guide.

STEP 1: Install Mono and GTK2

Mono is an open source cross-platform implementation of the .NET framework, it is needed to run NetworkMiner non-Windows machines. GTK2 is not required, but it provides a more consistent look to the user interface.

Ubuntu / Linux Mint / Kali Linux / Raspberry Pi OS:

Fedora:

AlmaLinux / RHEL:

Arch Linux:

STEP 2: Install NetworkMiner

STEP 3: Run NetworkMiner

Follow these steps to analyze live network traffic:

• Click File, Receive PCAP over IP [Ctrl+R]
• Click Start Receiving and note the listen TCP port (default is 57012)

Then run this command to sniff network traffic and send a real-time stream of captured packets to NetworkMiner:

Change 57012 in the command above if NetworkMiner is listening on a different TCP port.

This PCAP-over-IP technique can also be used to read a real-time packet stream from a remote device. It is also possible to sniff packets from Mikrotik routers by clicking File, Receive TZSP Stream.

STEP 4 (optional): Create Shortcut Command

NetworkMiner can now be started like this:

Linux Distros with NetworkMiner

NetworkMiner comes pre-packaged on some Linux distributions, such as REMnux, Security Onion Desktop, CSI Linux and BlackArch.

Static Download Link

The https://www.netresec.com/?download=NetworkMiner download link always delivers the latest release of NetworkMiner. If you prefer a static link, that points to a specific version of NetworkMiner, then please use this one: https://download.netresec.com/networkminer/NetworkMiner_3-0.zip

Posted by Erik Hjelmvik on Thursday, 10 April 2025 07:30:00 (UTC/GMT)

Tags: #NetworkMiner​ #Linux​ #Ubuntu​ #Kali​

Online Network Forensics Training

UPDATE - Training Canceled

The training event in May has been canceled. We are sorry for the inconvenience.

Posted by Erik Hjelmvik on Monday, 07 April 2025 06:25:00 (UTC/GMT)

Tags:

NetworkMiner 3.0 Released

I am very proud to announce the release of NetworkMiner 3.0 today!

This version brings several new protocols as well as user interface improvements to NetworkMiner. We have also made significant changes under the hood, such as altering the default location to where NetworkMiner extracts files from network traffic.

Some of the major changes in this new release are:

• New protocols: QUIC, CIP (EtherNet/IP), UMAS and Remcos RAT.
• Improved passive OS fingerprinting.
• Additional filtering capabilities.
• User interface adapted for Linux.

Filtering of Displayed Artefacts

A tooltip text is temporarily displayed when a filter is activated. The tooltip shows the number of visible items after the filter is applied. This tooltip can also be shown at a later point by hovering with the mouse over the filter text or the Apply button.

Right-clicking on an item or artefact in any of NetworkMiner’s tabs brings up a context menu. We’ve now added an “Apply as Filter” option to this context menu, which can be used to let NetworkMiner automatically generate a filter based on the clicked item. This feature saves time for the analyst and reduces risk of misspellings.

We have also added a keyword filter to the Credentials tab and updated the image filename filter to ignore case.

Other User Interface Improvements

The File Details window, which shows metadata and contents of an extracted file, now has a “Show as” menu that can be used to preview the contents of a file as ASCII, Hex, Unicode or UTF-8.

This file details window can now also be accessed directly from the Images tab by right-clicking on a thumbnail of an extracted image.

NetworkMiner 3.0 extracts Maximum Segment Size (MSS) values from TCP handshakes and show them under Host Details for each respective IP address. This value can help with determining if a host is behind a VPN. An MSS value below 1400 indicates that the traffic might have passed through some form of overlay network, such as a tunnel or VPN.

Other indicators that can help identify VPN and tunnelled traffic is IP TTL and latency, which NetworkMiner already extracts.

The screenshot above also shows that the operating system was identified as Windows, both with help of p0f as well as based on the client’s web browser user-agent. The user-agent based OS fingerprinting is a new feature that we added in NetworkMiner 3.0. This is a nice complement to the TCP and DHCP based OS fingerprinting features that NetworkMiner already performs. We’ve configured this feature to also detect operating systems of user-agent strings sent over UPnP/SSDP.

The text on a few of NetworkMiner’s buttons were not visible on some Linux distros, depending on how much button padding the respective window manager and theme added. Button sizes have therefore been increased in this release to reduce the risk of text not being visible when NetworkMiner is run in Linux.

New Protocol: QUIC

NetworkMiner 3.0 parses initial packets from the QUIC protocol (RFC 9000), which is the UDP based protocol used to transport HTTP/3. The QUIC parser allows NetworkMiner to extract TLS handshakes from UDP 443 traffic, from which the server’s hostname can be read if the client uses the SNI extension. The extracted TLS handshakes from QUIC are also used to generate JA3 and JA4 fingerprints for clients.

New Protocol: CIP and EtherNet/IP

We added parsers for the industrial control system protocols CIP and EtherNet/IP. The implementation does not cover all of the CIP and EtherNet/IP specifications, instead we focused on extracting device information, such as product vendor, product name, bulletin name, serial number and hostname. Such device information is crucial when performing passive asset identification of PLC’s and other industrial devices on OT/ICS networks, such as in factories and power plants. The CIP parser also supports extraction of tag data from Rockwell's proprietary version of CIP.

New Protocol: UMAS

A parser for the industrial control system protocol Modbus/TCP was added to NetworkMiner 2.0 back in 2016. In today’s 3.0 release we’ve enhanced the Modbus implementation to also parse out commands from Schneider Electric's proprietary UMAS protocol, which runs on top of Modbus by using the special function code 90 (0x5a). Our implementation unfortunately doesn’t have full coverage of UMAS, since we don’t have a protocol specification for this proprietary protocol. Nevertheless, our implementation recognizes 40 different UMAS commands (aka UMAS function codes) and can extract fields and parameters from at least 6 of them. The parsed UMAS commands can be viewed in NetworkMiner’s Parameters tab.

New Protocol: REMCOS C2

We started adding parsers for proprietary malicious Command-and-Control (C2) protocols, like StealC, njRAT, BackConnect and RMS, to NetworkMiner a couple of years ago. These malware C2 and backdoor protocol parsers enable security researchers to study what actions threat actors perform when accessing victim computers or honeypot systems.

We’re continuing on our endeavour of creating parsers for malicious protocol by adding support for the Remcos RAT C2 protocol to NetworkMiner 3.0.

Naturally, NetworkMiner’s Remcos parser can’t extract the C2 comms if Remcos uses TLS. Another limitation is that the free version of NetworkMiner is only able to parse Remcos traffic when the C2 server is running on a standard port like TCP 2404. The port-independent-protocol-identification feature in the Professional edition of NetworkMiner, however, identifies and parses Remcos traffic regardless of which port the C2 server listens on (the C2 server in the screenshot above was running on TCP port 1961).

Improved Protocol Parsers

We have also improved several of NetworkMiner’s existing protocol parsers. NetworkMiner’s parser for the trojan/backdoor njRAT (Bladabindi) protocol has, for example, been extended to reassemble full desktop screenshots from njRAT’s Remote Desktop feature.

NetworkMiner’s parser for Modbus has also been extended to support additional function codes and the NTLMSSP parser (for SMB/SMB2) is now better at extracting hostnames to NetworkMiner’s Hosts tab.

Bugs Fixes

A bug in NetworkMiner’s timestamp comparison code previously caused items to be sorted incorrectly when the Timestamp column header was clicked. This bug has now been fixed. We have also fixed a bug relating to extraction of parameters sent in JSON encoded HTTP POST requests.

Breaking Changes

Some of the changes introduced in the 3.0 release might require some users to adapt their workflow. One such change is that the default output path for extracted files and captured packets has changed from NetworkMiner’s directory to %LocalAppData%\NetworkMiner\ in Windows and ~/.local/share/NetworkMiner/ in Linux. This means that you no longer need to add write permissions to the NetworkMiner application directory or subdirectories thereof, since NetworkMiner no longer creates or modifies files there.

Another breaking change is that we have removed the Anomalies tab from the user interface. Windows users can still see alerts by starting NetworkMiner with --filelog, while Linux can use --debug to print debug, warning and error messages to stderr. Use --loglevel warning to suppress info and debug messages.

A change that only affects users of NetworkMiner Professional is that the command line tool NetworkMinerCLI now requires a Corporate License. If you currently have a single-user license, then you will still be able to use the command line tool in your 2.x version of NetworkMiner Professional, but not in the new 3.0 release.

NetworkMiner Professional

There are several improvements in the 3.0 release that only affect users of NetworkMiner Professional. One noteworthy update is that the Pro release has become significantly faster, especially for capture files containing many short TCP sessions. NetworkMiner Professional now saves around two milliseconds in parsing time for every TCP session. This might not sound as much, but it actually makes a huge difference when parsing capture files containing thousands of small TCP sessions.

NetworkMiner’s support for the TLS fingerprinting method JA4 has also been extended even further in the 3.0 release. NetworkMiner Professional now leverages FoxIO’s JA4 database to identify operating systems as well as applications based on client TLS handshake packets.

Other improvement of NetworkMiner Professional include:

• Network operator and AS number displayed on Hosts tab.
• File OSINT lookup includes Censys body_hash lookups.
• IP and domain OSINT lookups added to NetworkMiner’s DNS tab.
• PcapNG packet comments displayed in the Parameters tab.

Upgrading to Version 3.0

Users who have purchased NetworkMiner Professional can download version 3.0 from our customer portal, or use the “Check for Updates” feature from NetworkMiner's Help menu. Those who instead prefer to use the free and open source version can grab the latest release of NetworkMiner from the official NetworkMiner page.

Posted by Erik Hjelmvik on Friday, 04 April 2025 10:53:00 (UTC/GMT)

Tags: #NetworkMiner​ #QUIC​ #JA3​ #JA4​ #njRAT​

How to set PCAP as default save file format in Wireshark

Did you know that there is a setting in Wireshark for changing the default save file format from pcapng to pcap?

In Wireshark, click Edit, Preferences. Then select Advanced and look for the capture.pcap_ng setting. Change the value to FALSE if you want Wireshark to save packets in the pcap file format. You have to double-click the “TRUE” text to change it into “FALSE”.

This setting can also be accessed from the Capture tab in Preferences.

I recently learned about this setting from Sake Blok when he commented on my feature request to have Wireshark use pcap as default savefile format instead of pcapng. I have a feeling that this feature request will not be accepted though, since it has received several downvotes. That’s why I’m trying to spread the word about this setting instead, so that everyone who prefers the pcap file format over pcapng can change the default behavior in their own Wireshark installation.

This setting doesn’t affect command line tools, like dumpcap, tshark, mergecap etc. So if you want to capture packets with dumpcap to a pcap file then you need to use the -P switch like this:

Other command line tools in the Wireshark suite, like tshark and mergecap, require that you instead specify -F pcap like this:

What’s Wrong with PCAP-NG?

Why all this fuss about using PCAP instead of PCAP-NG? Well, it turns out that most Wireshark users are happily unaware of just how much metadata there is in the pcapng files they share online. This metadata typically contains information about the CPU of their computer, the exact version and build of their operating system as well as the name of the network interface on which the capture was performed. For Windows users the network interface details even contain a GUID that usually is a world-unique identifier.

I was once even able to identify a person, who had anonymously shared a pcapng file online, by inspecting metadata in the shared capture file github.pcapng. Here's the metadata in that capture file:

This screenshot shows the output from the “Show Metadata” functionality in NetworkMiner Professional. There's also a great way to show pcapng metadata in Wireshark: Open the pcapng file, click View, Reload as File Format/Capture (Ctrl+Shift+F).

Mergecap

The previously mentioned command line tool mergecap, which joins multiple capture files into one, outputs pcapng files by default. In fact, if it is tasked to merge two pcap files (having no metadata), it then creates a pcapng file containing the packets from the two input pcap files enriched with metadata about the computer running mergecap. This metadata is typically information about the operating system as well as the version of mergecap that was used.

Providing an output file with the “.pcap” suffix to mergecap will not help, mergecap still generates a pcapng file. You have to use the -F pcap switch to have it generate a pcap file without metadata about your operating system.

What do Wireshark Users Want?

I recently conducted two unscientific polls, where I asked which savefile format Wireshark should use as default.

In total the polls got 86 votes, where 51 voted for pcap and 35 preferred pcapng. I don't want to draw any real conclusions from these results though, primarily due to the low number of participants but also because there might be a bias among the people who were reached by these polls.

Looking Ahead

I reach out to people I know every now and then when I notice that they are sharing pcapng files containing potentially sensitive metadata. They then have to decide if they are okay with this or if they want to go through the process of replacing the pcapng files with pcap files. In many cases they choose the latter, which can be quite tricky if that involves removing files from GitHub.

I eventually got tired of doing this, especially when I realized that even very skilled Wireshark users often don’t know that pcapng files store metadata about their computers. Reminding people to select the “pcap” format every time they save a capture file doesn’t seem to be the solution. I therefore hope that this blog post can help Wireshark users avoid accidentally sharing unnecessary metadata in the future.

For more information about the pcapng format, please visit pcapng.com.

Posted by Erik Hjelmvik on Tuesday, 25 February 2025 10:33:00 (UTC/GMT)

Tags: #wireshark​ #PCAP​ #pcap-ng​ #dumpcap​ #metadata​ #ASCII-art​