FlowCarp Identifies Protocols

I am thrilled to announce the release of a brand new tool called FlowCarp!

FlowCarp is a simple command line tool that performs a very complicated task. It identifies the application layer protocol in network traffic without relying on port numbers, static signatures or code that tries to parse the application layer protocols. Instead, FlowCarp simply computes some statistical measurements on the traffic it sees and compares those measurements to models of known protocols. This allows FlowCarp to identify even proprietary and undocumented protocols, including malware C2 protocols.

FlowCarp Demo Service

There’s a demo FlowCarp web service running on demo.flowcarp.com, which accepts PCAP or PcapNG data via HTTP POST requests. The demo service returns a data structure, which follows the Suricata Eve JSON format, containing flows and alerts. I’d like to stress, however, that the returned flow and alert data is generated by FlowCarp and NOT by Suricata. The Suricata Eve JSON format supports pretty much everything we look for in a good flow and alert output format, which is why we decided to use their format instead of inventing yet another JSON based log format.

Let’s give the FlowCarp demo server a spin to see what it can do! I’ll start by downloading the PcapNG file from a suspected Mirai sample execution on Recorded Future’s Triage sandbox.

I’ve saved the capture file from Triage locally as “260504-hkcr6adt5x-behavioral1.pcapng”. This file can now be submitted to the FlowCarp demo service like this:

The generated mirai-eve.json file should now contain information about the flows and alerts that FlowCarp has found in the pcapng file. Let’s check which unique services that were contacted in the sandbox execution of this malware sample. I’m using jq to filter on event_type “flow” to show connection information instead of alerts.

• jq -c 'select(.event_type=="flow")|[.dest_ip, .dest_port, .proto, .app_proto]' < mirai-eve.json | sort -u
• ["107.189.17.70",80,"TCP","Mirai"]
• ["107.189.17.70",80,"TCP",null]
• ["1.1.1.1",53,"UDP","DNS"]
• ["185.125.188.61",443,"TCP","DNS"]
• ["185.125.188.62",443,"TCP","DNS"]
• ["224.0.0.251",5353,"UDP","DNS"]
• ["44.219.148.160",443,"TCP","TLS"]
• ["84.17.50.24",443,"TCP","DNS"]
• ["84.17.50.8",443,"TCP","TLS"]
• ["8.8.8.8",53,"UDP","BACnet"]
• ["8.8.8.8",53,"UDP","DNS"]
• ["8.8.8.8",53,"UDP","GTPv2"]

Alright, let’s see if any of those connections generated an alert:

• jq -r -c 'select(.event_type=="alert")|[.dest_ip, .dest_port, .proto, .alert.signature]' < mirai-eve.json | sort -u
• ["107.189.17.70",80,"TCP","MALWARE protocol detected: Mirai"]

FlowCarp tells us that the malware implant is using the Mirai C2 protocol to connect to a C2 server on TCP 107.189.17.70:80.

Running FlowCarp Locally

You can, of course, run FlowCarp locally on your own computer or in a container/pod instead of using the demo service. There are pre-compiled binaries of FlowCarp available for download on flowcarp.com for most platforms.

Let’s re-analyze the Mirai pcapng file, which was sent to the online demo service, but this time FlowCarp will run locally.

• ./flowcarp --input 260504-hkcr6adt5x-behavioral1.pcapng --output - 2>/dev/null | cut -d, -f 2,3,4 | sort -u
• 107.189.17.70:80, TCP
• 107.189.17.70:80, TCP, Mirai
• 1.1.1.1:53, UDP, DNS
• 185.125.188.61:443, TCP, DNS
• 185.125.188.62:443, TCP, DNS
• 224.0.0.251:5353, UDP, DNS
• 44.219.148.160:443, TCP, TLS
• 84.17.50.24:443, TCP, DNS
• 84.17.50.8:443, TCP, TLS
• 8.8.8.8:53, UDP, DNS

I let FlowCarp use its CSV output format instead of Eve JSON here, which is why cut was used to filter the output instead of jq. Nevertheless, the results are pretty much the same as before; FlowCarp detects Mirai traffic to 107.189.17.70:80.

You can try sending this same capture file to an IDS of your choice to see what alerts you get. Chances are that you might not get any alert for the Mirai traffic, since it is rather tricky to create good signatures for the Mirai C2 protocol. FlowCarp, on the other hand, doesn’t need any signatures to detect a protocol. All that is needed to build detection in FlowCarp is some example traffic of the protocol you’d like to identify. This unique feature is what makes FlowCarp so fantastic!

Real-Time Protocol Identification

FlowCarp is designed to run fast and use little resources, so that it can be used for local real-time analysis of network traffic. My general recommendation would be to run FlowCarp as a systemd service or to put it in a container or pod, but if you just want to test its real-time abilities then I suggest that you run this command:

FlowCarp will then read real-time PCAP data from standard input and print flow information – with identified application protocols – to standard output.

FlowCarp can also read real-time packet data through PCAP-over-IP, which allows us to utilize services like Fox-IT’s pcap-broker. You can start a pcap-broker listener like this:

FlowCarp can then access a real-time packet stream from the pcap-broker:

I hope you'll find FlowCarp useful!

Posted by Erik Hjelmvik on Monday, 04 May 2026 14:53:00 (UTC/GMT)

Tags: #protocol identification​ #Triage​ #tcpdump​

CapLoader 1.9.4 Released

A new version of our advanced PCAP filtering tool CapLoader was released today. The new CapLoader 1.9.4 release includes features like JA3 hash extraction from TLS traffic and a fantastic thing called Select Similar Flows, which is a unique feature that you will only find in CapLoader! We have also included a VXLAN parser, so that flows tunneled inside of overlay networks can be presented directly in the CapLoader GUI.

Select Similar Flows or Services

If you right-click a flow or service in CapLoader you’ll now be presented with an option to “select similar flows” (or services). This feature causes CapLoader to read through the loaded PCAP files again in order to find other flows that are similar to the one that was right-clicked. CapLoader doesn’t care about IP addresses or port numbers when assessing this similarity. Instead it looks at behavioral patterns in the traffic itself, such as packet sizes and byte patterns. In practice, this feature will select flows that are communicating using the same protocol as the one you clicked, regardless of which port it runs on. CapLoader already comes with an advanced feature for doing port-independent protocol identification, which currently detects over 170 protocols. But the “select similar” feature can even be used to find odd or proprietary protocols that aren’t in CapLoaders protocol database.

There is also a feature called “select VERY similar flows” which, instead of searching for flows with the same protocol, looks for flows with the same implementation or dialect of that particular protocol. This feature can be used to single out the network traffic of a particular software or tool from a haystack of network traffic from multiple applications, which all run the same application layer protocol. Another use case is to find additional malicious C2 sessions that run on top of a standard protocol like HTTP, TLS or DNS – provided that you’ve located at least one such malicious flow or service.

JA3 and JA3S Hashes for TLS Flows

We added JA3 extraction to NetworkMiner back in 2019, with the release of NetworkMiner 2.5. It’s now time to bring this useful little TLS fingerprinting feature into CapLoader as well. As of version 1.9.4 CapLoader attempts to extract JA3 and JA3S hashes from all TCP flows. The JA3 and JA3S hashes are presented in the Flows and Services tabs as separate columns. This allows users to filter flows based on a JA3 hash directly in CapLoader instead of having to export a filtered PCAP to an external tool to calculate JA3 hashes.

Image: Column criteria filter “JA3 = a72f351cf3c3cd1edb345f7dc071d813” on PCAP from CERT-SE’s 2021 CTF.

Extraction of Flows Inside of VXLAN Tunnels

VXLAN is a network virtualization technology that can be used to create overlay networks, where Ethernet frames are encapsulated inside of UDP packets (see RFC 7348). The UDP port used for VXLAN is 4789 or 8472. We added support for VXLAN to NetworkMiner in 2017, but CapLoader has until now only presented the VXLAN tunnels in the GUI when VXLAN traffic is loaded. We’re happy to announce that CapLoader now extracts flows for the VXLAN tunnels and the traffic inside of those tunnels.

Image: ICMP flow extracted from VXLAN tunnel. PCAP file is Virtual_Extensible_LAN-VXLAN.pcap from Xena Networks

Additional GUI Improvements

We’ve also made several minor improvements to CapLoader’s user interface, such as a “Save Visible Flows” option on the File menu, which can be used to save the filtered traffic in the current view to a PCAP file. Another nice addition is the “Copy from Selected Rows” menu option, which can be used to copy text from a particular column.

CapLoader’s OSINT lookup context menus have also been updated to include some very useful services like Feodo Tracker, Hatching Triage and IPVoid.

Free Trial versus Full Version

Many of the new additions to CapLoader are only available in the full version, but the VXLAN extraction and some of the GUI additions are also available in the free trial version of CapLoader. No registration is required to download the trial — just download, extract and run for 30 days. If you like it, then please consider purchasing the full version!

Updating to the Latest Release

Users who have already purchased a license for CapLoader can download a free update to version 1.9.4 from our customer portal.

Posted by Erik Hjelmvik on Thursday, 16 June 2022 11:44:00 (UTC/GMT)

Tags: #CapLoader​ #JA3​ #JA3S​ #Protocol Identification​ #Protocol Detection​ #PCAP​ #TLS​ #VXLAN​

Detecting Cobalt Strike and Hancitor traffic in PCAP

This video shows how Cobalt Strike and Hancitor C2 traffic can be detected using CapLoader.

I bet you’re going:

😱 OMG he’s analyzing Windows malware on a Windows PC!!!

Relax, I know what I’m doing. I have also taken the precaution of analyzing the PCAP file in a Windows Sandbox, which just takes a couple of seconds to deploy and run.

The capture file I’m looking at is called “2021-05-13-Hancitor-traffic-with-Ficker-Stealer-and-Cobalt-Strike.pcap” and can be downloaded from here: https://malware-traffic-analysis.net/2021/05/13/index.html

CapLoader’s Services tab shows us that the connections to TCP 80 and 443 on 103.207.42.11 are very periodic, with a detected period of exactly 1 minute. CapLoader successfully identifies the protocols for these two services as Cobalt Strike over HTTP and Cobalt Strike over SSL, respectively. The third service in this list is also very periodic, that’s the Hancitor trojan beaconing to its C2 server every two minutes.

CapLoader uses machine learning to identify the application layer protocol based on the behavior of the traffic, not the port number. This means that there can be false positives, i.e. the protocol classification that CapLoader gives a flow or service might be wrong. It is more common, however, for CapLoader to yield false negatives, which means that it can't identify the protocol. The detection of Cobalt Strike inside of HTTP and SSL traffic was recently introduced in the latest 1.9 release of CapLoader. I expected this feature to detect Cobalt Strike traffic in HTTP, but I was delighted to see that CapLoader often detects even TLS encrypted Cobalt Strike beaconing with really good precision!

As shown in the video, the Cobalt Strike beacon config can easily be extracted from the network traffic using NetworkMiner and Didier Stevens’ 1768 K python script.

The output from Didier’s 7868.py tool looks something like this:

As you can see, it uses HTTP for transport with a “sleeptime” of 1 minute (60000 ms) and 0% jitter. This means that a new connection will be made to the Cobalt Strike C2 server every minute. The fact that there was no jitter is what gives this service such a high value in CapLoader’s “Periodicity” column.

Network Forensics Training

Are you interested in learning more about how to analyze network traffic from Cobalt Strike and other backdoors, malware and hacker tools? Then take a look at the live online network forensics classes I will be teaching in September and October!

Posted by Erik Hjelmvik on Monday, 31 May 2021 08:30:00 (UTC/GMT)

Tags: #Netresec​ #Cobalt Strike​ #CobaltStrike​ #periodicity​ #Protocol Identification​ #PIPI​ #CapLoader​ #1768.py​ #Windows Sandbox​ #PCAP​ #NSM​ #video​ #videotutorial​