Gh0stKCP Protocol

Gh0stKCP is a transport protocol based on KCP, which runs on top of UDP. Gh0stKCP has been used to carry command-and-control (C2) traffic by malware families such as PseudoManuscrypt and ValleyRAT/Winos4.0.

@Jane_0sint recently tweeted about ValleyRAT using a new UDP based C2 protocol. I wanted to take a closer look at the protocol, so I downloaded the PCAP from any.run and opened it with CapLoader. To my surprise CapLoader claimed that the C2 traffic was using a known protocol called “KCP”.

The protocol detection feature in CapLoader compares traffic in TCP and UDP sessions to statistical models of known protocols. This means that no protocol specification or RFC is required to identify a protocol. All that is needed is some example traffic to build a protocol model from (see this XenoRAT detection video for a demonstration of this feature). In this case CapLoader’s KCP protocol model was built from UDP based C2 traffic from PseudoManuscrypt, which was reported to have been using KCP.

What is KCP?

KCP is a UDP based protocol designed as a low-latency alternative to TCP. The protocol was created by Lin Wei in the early 2010s, primarily to transport p2p voice chat audio in games. The protocol is, however, very generic and can be used to transport basically any type of data. The KCP protocol specification includes the following packet structure:

The first field “conv” is a 32 bit (4 byte) unique ID for a KCP session. This conversation ID is used to uniquely identify a connection and will remain constant throughout the connection. KCP doesn’t include any handshake mechanism for establishing new sessions, which means that KCP endpoints typically start transmitting payload data already in the first KCP packet.

The Gh0stKcp Protocol

The UDP based KCP C2 protocol used by PseudoManuscrypt as well as the ValleyRAT C2 traffic that CapLoader reported being “KCP” both deviated from the original KCP specification in several ways. For instance, KCP packets have a 24 byte header, which means that packets shorter than 24 bytes can’t be KCP. In fact, the KCP source code actually ignores UDP packets that carry less than 24 bytes of payload. Yet, both the PseudoManuscrypt and ValleyRAT UDP C2 traffic initially transmit several 12-byte packets.

Image:Flow transcript of Gh0stKCP traffic in CapLoader

These 12-byte Gh0stKCP handshake packets are generated by an open source library called HP-Socket, which includes a custom Automatic Repeat reQuest (ARQ) handshake mechanism.

The following behavior can be deduced by examining UDP traffic from Valley RAT or by analyzing the UDP handshake mechanism in HP-Socket's ArqHelper.h.

The client (bot) starts by sending an empty UDP packet to the C2 server, followed by a UDP packet carrying a 12 byte payload structured like this:

The first four bytes can be decoded as follows:

• 4f bb = Magic bytes
• 01 = Handshake command
• 00 = Handshake is not completed

The “xx” bytes represent a KCP conversation ID (conv) proposed by the bot. This initial handshake packet can easily be detected and alerted on with the following Suricata IDS signature:

The C2 server also transmits a UDP packet containing a 12 byte handshake using the exact same structure as the client. However, the C2 server proposes a 32 bit conversation ID of its own. In “normal” KCP implementations the client and server agree on a single shared conversation ID, but Gh0stKCP actually uses one separate ID for each direction. This allows the server to transmit its handshake packet without having seen the client’s handshake.

The “yy” bytes represent the C2 server’s 32-bit conversation ID (conv).

The communicating parties frequently re-transmit this initial handshake packet until they have received a handshake from the other end.

Upon receiving the other end’s handshake both the bot and C2 server acknowledge the other end’s conversation ID with a UDP packet carrying the following 12 byte payload:

Where “xx” is the sender’s conversation ID and “yy” is the other end’s conversation ID. After having received the other end’s acknowledgment packet both parties additionally transmit a final ack packet, indicating that the handshake is completed and they will start communicating using KCP. This final ack packet is identical to the previous one, except the fourth byte (handshake complete flag) has changed from 0x00 to 0x01.

From this point on Gh0stKCP communicates using the KCP protocol, with the exception that each end transmits packets using their own conversation ID rather than a common ID. The KCP traffic that follows can therefore be parsed and inspected in Wireshark with help of a KCP Lua parser, such as CandyMi’s kcp_dissector.lua.

Image: KCP traffic from ValleyRAT sample any.run in Wireshark

Finally, the Gh0stKCP session is terminated by sending a UDP packet containing the following hard coded 16 bytes:

This unique byte sequence is defined in HP-Socket as s_szUdpCloseNotify, which can be detected with the following Suricata IDS signature:

Hole Punching in NAT Firewalls

The elaborate handshake procedure used by Gh0stKCP introduces a significant delay before the C2 session is established. The handshake takes up to 500ms to complete, which is much slower than a normal TCP 3-way handshake. KCP is typically used because of its low-latency properties, but the handshake routine ruins any chance for quick establishment of Gh0stKCP sessions.

The intricate ARQ handshake routine does, however, allow for hole punching in firewalls, aka “NAT traversal”, which enables the protocol to be used for peer-to-peer communication. This p2p-enabling property could potentially be used to relay C2 communication through one or several bots, even if those bots are behind separate NAT firewalls.

Detecting Gh0stKCP with Snort and YARA

CapLoader can detect when the KCP protocol is used. However, only a few security analysts have a CapLoader license. We have therefore decided to release Surucata signatures and a YARA rule that can be used to detect Gh0stKCP.

The Suricata signatures included in this blog post can also be downloaded from here:
https://github.com/Netresec/Suricata/blob/main/netresec.rules

Our Gh0stKCP YARA rule is based on Steve Miller’s “RareEquities_KCP” rule, from Mandiant’s 2020 blog post APT41 Initiates Global Intrusion Campaign Using Multiple Exploits. Steve’s original YARA rule provides generic detection of software that uses the original KCP library. We’ve extended that rule to also look for HP-Socket’s characteristic 16-byte close command.

https://github.com/Netresec/YARA/blob/main/Gh0stKCP.yar

IOC List

Many of the IOCs in the list below are old, which is why you might not want to use them for alerting. They are included here primarily for researchers and analysts who wish to perform retrohunting to discover malware samples that use GhostKCP.

2021 (PseudoManuscrypt)

• UDP 34.64.183.91:53
• UDP 34.97.69.225:53
• UDP 160.16.200.77:53
• UDP 167.179.89.78:53
• UDP 167.179.89.78:53
• UDP 185.116.193.219:53
• UDP 198.13.62.186:53
• UDP email.yg9[.]me:53
• UDP facebook.websmails[.]com:53
• UDP google.vrthcobj[.]com:53

2022 (PseudoManuscrypt)

• UDP 34.142.181.181:53

2025 (ValleyRAT / Winos4.0)

• UDP 27.124.3.234:8443
• UDP 43.133.39.217:80
• UDP al17[.]tk:80
• UDP xiaoxiao.fenghua678.eu[.]cc:8443

Attribution

Use of ValleyRAT is often attributed to the APT group Silver Fox (银狐), but ValleyRAT and Gh0stKCP could be used by other threat actors as well.

Posted by Erik Hjelmvik on Wednesday, 24 September 2025 09:40:00 (UTC/GMT)

Tags: #CapLoader​ #Suricata​

Define Protocol from Traffic (XenoRAT)

This video shows how to define a protocol in CapLoader just by providing examples of what the protocol looks like. CapLoader can then identify that protocol in other traffic, regardless of IP address and port number, simply by looking for traffic that behaves similar to what it was trained on. We call this Port Independent Protocol Identification (PIPI). You don’t need to define all protocols this way though since CapLoader can detect hundreds of different protocols out of the box using PIPI.

The protocol identified in the video is the XenoRAT command-and-control (C2) protocol. The identification was based on a sandbox execution of XenoRATClientScript.js on ANY.RUN. The protocol model was then tested on a PCAP file from a XenoRAT execution on Triage.

IOC List

• Url: hxxps://raw.githubusercontent[.]com/NTCHuy/hack/refs/heads/main/Client.exe
• MD5: e0b465d3bd1ec5e95aee016951d55640
• MD5: 5ab23ac79ede02166d6f5013d89738f9
• C2: Huy1612-24727.portmap[.]io:24727
• C2: 193.161.193.99:24727
• C2: 147.185.221.30:54661

Posted by Erik Hjelmvik on Thursday, 21 August 2025 12:50:00 (UTC/GMT)

Tags: #CapLoader​ #PIPI​ #ANY.RUN​

PureRAT = ResolverRAT = PureHVNC

PureRAT is a Remote Access Trojan, which can be used by an attacker to remotely control someone else’s PC. PureRAT provides the following features to an attacker:

• See the victims user interface
• Interact with the victim PC using mouse and keyboard
• View the webcam
• Listen to the microphone
• Record keystrokes
• Upload and download files
• Proxy network traffic through victim

What the PureRAT user interface looks like to the attacker

PureRAT is the exact same malware as what Morphisec and others call ResolverRAT. PureHVNC, on the other hand, is the predecessor to PureRAT. These three malware names are all used by threat intel companies and researchers when referring to the same malware family. We will call this malware family “PureRAT” in this blog post.

Indicators of PureRAT

Malware analysts might recognize PureRAT through properties like these ones:

• Loader is a .NET executable obfuscated with Eazfuscator.NET
• Payload is AES-256 encrypted in CBC mode
• Payload is gzip compressed
• Extracted PureRAT payload is a DLL
• PureRAT DLL is packed with .NET Reactor
• A handler is registered for the ResourceResolve event to inject a malicious .NET assembly

See analysis by eSentire, Morphisec, Kaspersky, Fortinet and 0xlibris for more reverse engineering details on PureRAT and related software from the PureCoder developer(s).

Another way to identify the malware is to run it in a sandbox and inspect the network traffic. The following characteristics are typical indicators of PureRAT:

• C2 TCP port is often 56001, 56002 or 56003
• Client (bot) first sends 04 00 00 00 (in hex), followed by a TLS handshake
• Client and server run TLS 1.0
• X.509 cert is self signed
• X.509 cert expires 9999-12-31 23:59:59 UTC

As you can see in the flow transcript above, CapLoader currently identifies this traffic as “ResolverRAT”. This detection will most likely be changed to “PureRAT” in future versions of CapLoader.

IOC List

Here are some IP:port tuples for C2 servers used by recent samples of PureRAT:

• 193.26.115.125:8883
• purebase.ddns[.]net:8883
• 45.74.10.38:56001
• 139.99.83.25:56001

Posted by Erik Hjelmvik on Tuesday, 12 August 2025 15:43:00 (UTC/GMT)

Tags: #PureCoder​

PureLogs Forensics

I analyzed some PureLogs Stealer malware infections this morning and found some interesting behavior and artifacts that I want to share.

PureLogs infections sometimes start with a dropper/downloader (PureCrypter) that retrieves a .pdf file from a legitimate website. The dropper I will demo here downloaded this file:

hxxps://www.vastkupan[.]com/wp-admin/js/Daupinslenj.pdf

This file isn’t really a PDF though, but more on that later. Here’s a CapLoader screenshot with some interesting flows from the infection:

The PCAP in the screenshot above comes from a sandbox execution on any.run of a file called BSN100357-HHGBM100002525.exe.

Here’s a breakdown of what happens behind the scenes in this execution:

1. Dropper connects to www.vastkupan[.]com (DNS and TLS flows).
2. A fake PDF (Daupinslenj.pdf) is downloaded over HTTPS.
3. The fake PDF is decrypted to a DLL (PureLogs), which is stored in memory.
4. InstallUtil.exe is started.
5. The PureLogs DLL is injected into the running InstallUtil process.
6. PureLogs connects to C2 server at 91.92.120.101:65535

The same dropper has also been run on JoeSandbox, with almost identical behavior. The vastkupan.com website belongs to a legitimate company (Västkupan Fastigheter).

The PDF that Wasn’t

This is what the downloaded “PDF” looks like:

So, what’s up with all that “171171” data? Let’s XOR with “711” and see what we get.

The downloaded PDF turns out to be a .NET DLL file with MD5 38d29f5ac47583f39a2ff5dc1c366f7d. This is the file that was injected into the otherwise legitimate InstallUtil process. Some PureLogs droppers use RegAsm.exe instead of InstallUtil though (see JoeSandbox and any.run).

IOC List

Droppers (MD5):

• 711d9cbf1b1c77de45c4f1b1a82347e6
• 6ff95e302e8374e4e1023fbec625f44b
• e6d7bbc53b718217b2de1b43a9193786
• a9bc0fad0b1a1d6931321bb5286bf6b7
• 09bb5446ad9055b9a1cb449db99a7302

Dropper TLS handshake signatures:

• JA3: 3b5074b1b5d032e5620f69f9f700ff0e
• JA4: t12d210700_76e208dd3e22_2dae41c691ec

Payload URLs:

• hxxps://www.vastkupan[.]com/wp-admin/js/Cicdwkknms.pdf
• hxxps://www.vastkupan[.]com/wp-admin/js/Daupinslenj.pdf
• hxxps://www.new.eventawardsrussia[.]com/wp-includes/Ypeyqku.pdf

Payloads (MD5):

• ab250bb831a9715a47610f89d0998f86 (Cicdwkknms.pdf)
• cec53e8df6c115eb7494c9ad7d2963d4 (Daupinslenj.pdf)
• eedc8bb54465bd6720f28b41f7a2acf6 (Ypeyqku.pdf)

Decrypted payloads:

• MD5: 38d29f5ac47583f39a2ff5dc1c366f7d
• SHA1: fc8b0ee149027c4c02f7d44cc06cade3222bb6b6
• SHA256: 8d7729ca0b25a677287076b4461304a21813e6f15053e190975512e58754988f

PureLogs C2:

• 91.92.120.101:62520 (old)
• 91.92.120.101:65535 (new)

Update 2025-07-16

Additional PureLogs payloads have been found on vastkupan.com.

Payload URLs:

• hxxps://www.vastkupan[.]com/wp-admin/js/Cxqyoub.dat
• hxxps://www.vastkupan[.]com/wp-admin/js/Qlwxqgsag.dat

Cxqyoub.dat is decrypted by XOR-ing with "414".

Qlwxqgsag.dat is a DLL with reversed content.

Payloads (MD5):

• 22a304ea9c006e2ccb2f6110c4d3f53f (Cxqyoub.dat)
• d5b6607ee4718506eb4970c02cf286cd (XOR decrypted DLL from Cxqyoub.dat)
• 062d2a5906fac4c2ef07c6b43141e19c (Qlwxqgsag.dat)
• 40624de03bc3c53331b6e903d9e3860f (DLL from reversed Qlwxqgsag.dat)

C2 server:

• 91.92.120.102:62050

See JoeSandbox and any.run for sandbox executions of the dropper aa06d06ddb6d3801c70cc1991f393112 (retrieves Cxqyoub.dat), and JoeSandbox and any.run for c45a95dc7ebc8c78217cd996a8f6dda7 (gets Qlwxqgsag.dat).

Update 2025-07-21

Yet another PureLogs payload found on vastkupan.com.

• Dropped by: 031a9c2f44881f4db1c6f6d88a540206
• URL of encrypted DLL: hxxp://www.vastkupan[.]com/wp-admin/js/Kplbc.pdf
• Encrypted DLL MD5: 6ed3c9b70ca02d1c558d1ef9a8aaab77
• C2: 65.108.24.103:62050

Sandbox executions are available on JoeSandbox and any.run.

Update 2025-07-30

Additional encrypted PureLogs DLLs found on vastkupan.com

• Dropped by: 67861615d765d0c59d65e8d4454e5ffc
• URL of encrypted DLL: hxxps://www.vastkupan[.]com/wp-admin/js/Qytqk.pdf
• Encrypted DLL MD5: 668a42bdfd253e0d54716cd115479b9f
• C2: 91.92.120.102:62050 (same as Cxqyoub.dat and (Qlwxqgsag.dat)

• Dropped by: 031a9c2f44881f4db1c6f6d88a540206
• URL of encrypted DLL: hxxps://www.vastkupan[.]com:443/wp-admin/js/Kplbc.pdf
• Encrypted DLL MD5: 6ed3c9b70ca02d1c558d1ef9a8aaab77
• C2: 65.108.24.103:62050

• Dropped by: 07ff4006101f117aa4f198c984a45137
• URL of encrypted DLL: hxxps://www.vastkupan[.]com/wp-admin/js/Pnnvrpjewlq.vdf
• Encrypted DLL MD5: 98cf831688941cc8bccfe1e8a33c9c16

• Dropped by: a1fd8053b49442028d66e3adea550d19
• URL of encrypted DLL: hxxps://www.vastkupan[.]com/wp-admin/js/Niose.wav
• Encrypted DLL MD5: 067086aff11080357b92931e96ecebae

• Dropped by: 3cf704e64cbba6560663ec45ce2dabc2
• URL of encrypted DLL: hxxps://www.vastkupan[.]com:443/wp-admin/js/Frfkft.vdf
• Encrypted DLL MD5: c9bac721c9b6f2900fd3d8ed922bc759
• C2: 91.92.120.101:7705

• Dropped by: 486d6c9cbdb638f9d574c58459676ed9
• URL of encrypted DLL: hxxps://www.vastkupan[.]com/wp-admin/js/Skrcygatz.dat
• Encrypted DLL MD5: a3cf5108315a06d564c97c8367994fd1
• C2: 216.250.252.231:2080

Update 2025-07-31

Turns out the whole /wp-admin/js/ directory on Västkupan's website allows directory listing. Among the files in that directory is "New PO 102456688.exe", which drops PureLogs.

• Filename: New PO 102456688.exe
• MD5: b2647b263c14226c62fe743dbff5c70a
• C2: 147.124.219.201:65535

See executions on Tria.ge and any.run for details.

Posted by Erik Hjelmvik on Wednesday, 02 July 2025 11:52:00 (UTC/GMT)

Tags: #PureLogs​ #PureCoder​ #3b5074b1b5d032e5620f69f9f700ff0e​ #JoeSandbox​

CapLoader 2.0.1 Released

This update resolves several minor bugs, but also brings better protocol identification and a new IP lookup alert to CapLoader.

IP lookup services, like ip-api, checkip.amazonaws.com and ident.me, aren’t malicious, but malware often use such services to find out what the public IP address is of an infected machine. As Tony Robinson points out, in his recent External IP Lookup Rules post, malware does so to check for internet connectivity and determine the country of the infected PC. But I’ve also observed a third reason, which is when the threat actor resolves the victim’s public IP to then query a DNSBL service and check the IP’s reputation. I believe the DNSBL lookup is performed to evaluate the success rate of sending spam, such as emails with malicious attachments or links, from the victim PC.

If you want to learn more about how TrickBot used DNSBL then read GoSecure’s TrickBot […] and Spamhaus blog post or sign up for one of my network forensics training sessions.

Improved Protocol Detection

The precision of CapLoaders built-in port independent protocol identification has been improved and a few additional protocols can now be detected, including Interlock RAT.

Bug Fixes

The following bugs fixes and feature updates are included in this release:

• Better handling of corrupt PCAP files
• Fixed periodicity measurement inconsistency for services with more than 100 flows
• Fixed parsing bug for duplicate QUIC packets
• Improved speed and reliability of auto-extract PCAP from selection
• ThreatFox API updated to use abuse.ch Auth-Key

Posted by Erik Hjelmvik on Tuesday, 01 July 2025 13:48:00 (UTC/GMT)

Tags: #CapLoader​ #TrickBot​ #DNSBL​

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​ #PureLogs​ #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​