NETRESEC Network Security Blog - Tag : Suricata

rss Google News

PureLogs, PureRAT and misleading zgRAT

No to zgRAT

Please stop classifying malware as zgRAT. That malware label is confusing. As far as I know, there isn’t a proper definition of what zgRAT actually is. Some claim that zgRAT is the same malware family as PureLogs, while others argue that zgRAT should be mapped to PureRAT. There is also a blog post by malware analysts khr0x and Jane where they clearly state that PureLogs is not the same thing as zgRAT.

Despite the similar names PureLogs and PureRAT are not the same type of malware. PureLogs is an infostealer, while PureRAT is a Remote Access Trojan (RAT). Both are, however, built using .NET and are developed by PureCoder.

We previously helped clear up confusion around labels like ResolverRAT and PureHVNC, which were used in the past to refer to PureRAT malware samples. I hope this post helps reduce misunderstandings caused by the use of zgRAT.

Naming malware and threat actors

Malware labels and threat-actor labels serve different purposes. Publicly attributing an attack to a real-world organization might cause political turmoil, which can be avoided by using a threat-actor alias instead. Threat-actor aliases also often reflect each organization’s access to evidence and internal clustering process. As a result, multiple aliases for the same actor can coexist.

Malware-family labels, on the other hand, are usually more deterministic. Given a hash of a malware sample, researchers generally know they’re looking at the exact same artifact. For that reason, the most useful practice is to use the same name as the malware developers or the earliest widely adopted naming and use “unknown” or “unidentified” when classification is unclear. This reduces label fragmentation and downstream confusion when the same label is reused for different malware families.

Why zgRAT causes confusion

Many zgRAT signatures consistently match PureLogs, while others match PureRAT. There’s also a fairly popular YARA rule called “MALWARE_Win_zgRAT” that matches pretty much any binary protected with .NET Reactor. Taken together, this creates a solid foundation for false positives and misunderstandings stemming from the zgRAT label. And without a proper definition of what zgRAT actually is, such as a consistent mapping to a single malware family, false positives and misclassifications involving the zgRAT label are much harder to spot and weed out.

PureLogs

info stealer

PureLogs is an infostealer that automatically collects and exfiltrates credentials and sensitive data from infected hosts, including browser-stored logins, credit card numbers, cookies, crypto-wallet data, VPN credentials and credentials for various chat/messaging platforms.

PureLogs uses a custom binary protocol to exfiltrate stolen data. As of PureLogs v5.0 the network traffic is often wrapped in TLS, thereby making it harder to detect on the network.

Default server ports:

  • TCP 7701➔7710 (non-TLS)
  • TCP 8443 (TLS)

Server ports are configurable, but the default ports are often used.

Suricata signatures for non-TLS PureLogs traffic:

  • 2048901 ET MALWARE [ANY.RUN] zgRAT / PureLogs Stealer C2 Connection M2
  • 2061601 ET MALWARE zgRAT / PureLogs Stealer GZIP Exfiltration Outbound
  • 2061633 ET MALWARE PureLogs Backdoor Server GZIP C2 Traffic
  • 2061634 ET MALWARE PureLogs Backdoor Client GZIP C2 Traffic
  • 2063215 ET MALWARE zgRAT / PureLogs Stealer C2 Server Connection M3

Selected suricata signatures (not exhaustive) for TLS encrypted PureLogs traffic:

  • 903209570 SSLBL: Malicious SSL certificate detected (PureHVNC C&C)
  • 903209620 SSLBL: Malicious SSL certificate detected (PureHVNC C&C)
  • 903209854 SSLBL: Malicious SSL certificate detected (PureLogsStealer C&C)
  • 903210180 SSLBL: Malicious SSL certificate detected (PureLogsStealer C&C)

FlowCarp protocol names:

  • PureLogs
  • TLS, PureLogs

Recent PureLogs samples (hash and C2):

PureRAT

Trojan Horse

PureRAT is a Remote Access Trojan (RAT) with many built-in features for live interaction with infected hosts, such as:

  • Hidden VNC (HVNC) and remote desktop with mouse and keyboard control
  • Viewing the webcam
  • Listening to the microphone
  • Real-time keylogging
  • Remote command prompt
  • Reverse proxy (HTTP and SOCKS5)
  • Code injection

PureRAT previously used a flawed TLS implementation that could be easily detected on the network. The current TLS implementation is more difficult to spot. HVNC Hidden Desktop and PureHVNC are older names for PureRAT, which were used up until 2025.

Default C2 ports:

  • TCP 56001
  • TCP 56002
  • TCP 56003

Server ports are configurable, but the default ports are often used.

Selected suricata signatures (not exhaustive) for PureRAT traffic:

  • 2035595 ET MALWARE Generic AsyncRAT/zgRAT Style SSL Cert
  • 2070181 ET MALWARE PureRAT TLS Certificate Observed (PureRAT Agent)
  • 903208736 SSLBL: Malicious SSL certificate detected (PureHVNC C&C)
  • 903209136 SSLBL: Malicious SSL certificate detected (PureLogsStealer C&C)
  • 903209139 SSLBL: Malicious SSL certificate detected (PureLogsStealer C&C)
  • 903209682 SSLBL: Malicious SSL certificate detected (ResolverRAT C&C)
  • 906200096 SSLBL: Malicious JA3 SSL-Client Fingerprint detected (AsyncRAT)

FlowCarp protocol names:

  • PureRAT
  • TLS, PureRAT

Recent PureRAT samples (hash and C2):

Detection notes

As you can see, both PureLogs and PureRAT traffic can trigger Suricata alerts with signatures labeled as “zgRAT”. There are also still signatures using outdated names like “PureHVNC” and “ResolverRAT”. Luckily, analysts know that the alert label often doesn’t map to the correct malware family. The alert labels merely reflect how the rule author named the suspected malware at creation time. Nevertheless, the fact that the “zgRAT“ label is used for PureLogs as well as PureRAT signatures contributes to the confusion regarding what zgRAT actually is.

I use FlowCarp to identify PureLogs and PureRAT traffic and to tell them apart. FlowCarp uses statistical methods for identifying the C2 protocol, which allows it to identify PureLogs as well as PureRAT traffic without having to track every new X.509 certificate that the C2 servers use.

Recommendations

Given the fuzziness and ongoing confusion around the zgRAT label, I strongly recommend not using that term. If you know that a sample is a piece of malware created by PureCoder (including PureLogs, PureRAT, PureMiner or BlueLoader), but you don’t know which one, then label it “unknown PureCoder malware” instead of slapping the poorly defined zgRAT label to it.

Feel free to use the FlowCarp demo service if you have a PCAP file with C2 traffic and want a second opinion on the C2 protocol or malware family. You can use curl to submit a PCAP file to the FlowCarp demo service like this:

curl --data-binary @sandbox.pcap https://demo.flowcarp.com

Posted by Erik Hjelmvik on Monday, 27 July 2026 16:00:00 (UTC/GMT)

Tags: #zgRAT #PureRAT #PureLogs #PureHVNC #ResolverRAT #Suricata #FlowCarp

Short URL: https://netresec.com/?b=267e877


Ping32 RMM and ValleyRAT

malware infected laptop

Fareed Radzi recently blogged about a malware campaign observed earlier in June by Kaspersky’s GReAT team. The malware campaign embedded malicious code in VBScripts, which were distributed through WhatsApp DMs. The VBScript then dropped the legitimate Remote Monitoring and Management (RMM) tool ManageEngine Endpoint Central.

Fareed included the IOCs for the following Endpoint Central server IP addresses:

  • 202.61.160.208
  • 202.61.160.202
  • 202.61.160.201
  • 202.61.160.160
  • 202.61.160.137
  • 38.55.151.63

He also noted a link to ValleyRAT:

Notably, 202.61.160[.]201 had previously been observed as command-and-control infrastructure associated with ValleyRAT and Gh0st RAT activity. Although the overlap raises the possibility of the VBS campaign being linked to the operator of these known malware families, the available evidence is insufficient to confidently attribute the campaign to a known threat actor.

Attribution is difficult, so it makes sense not to call out any specific threat actor just because of a single overlapping IP address. Nevertheless, the threat actor that typically comes to mind when talking about ValleyRAT is Silver Fox (银狐).

Retrohunting in Sandboxes

I searched various online sandboxes for the IP addresses and MD5 hashes that were published in Fareed's blog post. To my delight I found plenty of samples on ANY.RUN as well as Triage. But what was even more interesting was the sandbox executions on Triage for the sample with MD5 hash d43fdaa1f0ee09d7e5f0f94ee9df7b6c. One of the known filenames for this sample was "Bitte füllen Sie das Formular für Umsatzsteuer-Nullsatz-Verkäufe aus..vbs".

Sample executions on Recorded Future Triage Sandbox:

I can’t determine how this sample was originally connected to the ManageEngine Endpoint Central campaign, but it shared several traits with what was described in Fareed’s Securelist write-up. However, this particular VBScript didn’t install the ManageEngine RMM. Instead it reached out to f004.backblazeb2[.]com and downloaded a dropper.

Traffic to f004.backblazeb2[.]com on Triage Sandbox

The dropper then deployed NSecRTS.exe, which turned out to be another RMM tool called “Ping32” from the Chinese company Shandong Anzai Information Technology, aka NSecsoft. This RMM tool has a history of being abused as a Remote Access Trojan (RAT) by hackers.

The Ping32 RMM used HTTP over multiple TCP ports on 143.92.37.168, and it also communicated via UDP port 18987 on the same server.

CapLoader transcript of Ping32 RMM UDP traffic
Image: UDP traffic to 143.92.37.168:18987

Pivot to ValleyRAT

I pivoted on the C2 IP 143.92.37.168, which was used by the malicious Ping32 RMM, and got a hit on Triage Sandbox. Triage classified this sample as DonutLoader and ValleyRAT, and its malware config extractor identified the following attributes:

Family valleyrat_s2
Version 1.0
C2 143.92.37.168:10086
Campaign date 2026-02-02

This is interesting, because this is another link between the campaign mentioned in Fareed’s blog post and ValleyRAT. When I examined the ValleyRAT C2 traffic from the Triage sandbox execution I noticed that CapLoader as well as FlowCarp identified it as Gh0stKCP, which is a UDP-based protocol that ValleyRAT sometimes uses to transport its C2 traffic.

Gh0stKCP flows in CapLoader

Use this oneliner to upload the PcapNG file from Triage to the free FlowCarp demo server and extract IP:port IOCs from FlowCarp alerts.

curl -fSs --data-binary @260514-agrsxacw6n-behavioral1.pcapng https://demo.flowcarp.com | jq -s -c 'map(select(.event_type=="alert")|[(.dest_ip + ":" + (.dest_port|tostring)), .alert.signature])|unique[]'

["143.92.37.168:10086","MALWARE protocol detected: Gh0stKCP"]

If you prefer Suricata, use these custom signatures to detect Gh0stKCP:
https://github.com/Netresec/Suricata/blob/main/netresec.rules

You can then use the same jq query as in the FlowCarp example to extract the alert IOCs from Suricata’s eve.json output.

cat eve.json | jq -s -c 'map(select(.event_type=="alert")|[(.dest_ip + ":" + (.dest_port|tostring)), .alert.signature])|unique[]'

["143.92.37.168:10086","Gh0stKCP / HP-Socket ARQ handshake"]
["143.92.37.168:10086","Gh0stKCP close"]

Silver Fox

It is difficult to attribute the analyzed malware samples to a specific threat actor, but it is possible that they were used by the notorious Silver Fox group, which is one of China’s largest and most active cybercrime groups.

On a positive note, China Daily recently reported that Chinese police have taken “criminal compulsory measures” against 27 suspects linked to Silver Fox. The same article also stated that “The gang allegedly sent phishing emails in bulk, stole corporate data and built fraud scenarios to carry out criminal activities totaling more than 7 million yuan ($1 million)”.

Let’s hope this puts a stop to, or at least significantly reduces, the massive flood of malware that has been coming from this threat actor.

IOC List

Unknown Downloader

  • d43fdaa1f0ee09d7e5f0f94ee9df7b6c (Bitte füllen..vbs)
  • hxxps://f004.backblazeb2[.]com/file/fadaoxiao/uamcd.pdf
  • hxxps://f004.backblazeb2[.]com/file/gaosu2/CoreShield.msi
  • hxxps://fadaoxiao.s3.us-west-004.backblazeb2[.]com/pacc.vbs
  • ac63eb8814f20ffd89ce81f51cba6916 (uamcd.pdf)
  • 9ca134a5ed592a0fb57e2ad910a71c80 (pacc.vbs)

NSecsoft Ping32 RMM C2

  • 143.92.37.168:18987 (UDP)
  • 143.92.37.168:38987 (TCP)
  • 143.92.37.168:48988 (TCP)
  • 143.92.37.168:48991 (TCP)
  • 143.92.37.168:48992 (TCP)

DonutLoader/ValleyRAT

  • 8266b00c4e45d728cef78b3f5a865f68 (ManagementTool.exe)
  • 143.92.37.168:10086 (UDP)

Posted by Erik Hjelmvik on Thursday, 25 June 2026 09:27:00 (UTC/GMT)

Tags: #Gh0stKCP #ValleyRAT #Suricata #FlowCarp #CapLoader

Short URL: https://netresec.com/?b=2666e31


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.

Gh0stKCP ghost

@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”.

ValleyRAT UDP traffic identified as KCP by CapLoader

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:

KCP 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.

CapLoader transcript of Gh0stKCP session

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:

4f bb 01 00 xx xx xx xx 00 00 00 00

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:

alert udp $HOME_NET any -> $EXTERNAL_NET any (msg:"Gh0stKCP handshake"; dsize:12; content:"|4f bb 01 00|"; offset:0; depth:4; content:"|00 00 00 00|"; within:8; distance:4; classtype:trojan-activity; reference:url,https://netresec.com/?b=259a5af; sid:1471101; rev:1;)

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.

4f bb 01 00 yy yy yy yy 00 00 00 00

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:

4f bb 01 00 xx xx xx xx yy yy yy yy

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.

4f bb 01 01 xx xx xx xx yy yy yy yy

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.

Gh0stKCP traffic in Wireshark with Lua script to decode KCP

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:

be b6 1f eb da 52 46 ba 92 33 59 db bf e6 c8 e4

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

alert udp any any -> any any (msg:"Gh0stKCP close"; dsize:16; content:"|be b6 1f eb da 52 46 ba 92 33 59 db bf e6 c8 e4|"; offset:0; depth:16; classtype:trojan-activity; reference:url,https://netresec.com/?b=259a5af; sid:1471102; rev:1;)

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 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: #Gh0stKCP #ValleyRAT #CapLoader #Suricata

Short URL: https://netresec.com/?b=259a5af


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.

comparing apple to orange

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

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:

Chaos​reader Network​Miner Suri​cata tcp​flow Wire​shark Zeek
FTP
HTTP
HTTP/2
IEC-104
IMAP
LPR
NFS
njRAT
POP3
SMB
SMB2/3
SMTP
TFTP
TLS certs

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

Short URL: https://netresec.com/?b=255329f


What is PCAP over IP?

PCAP over IP

PCAP-over-IP is a method for reading a PCAP stream, which contains captured network traffic, through a TCP socket instead of reading the packets from a PCAP file.

A simple way to create a PCAP-over-IP server is to simply read a PCAP file into a netcat listener, like this:

nc -l 57012 < sniffed.pcap

The packets in “sniffed.pcap” can then be read remotely using PCAP-over-IP, for example with tshark like this (replace 192.168.1.2 with the IP of the netcat listener):

nc 192.168.1.2 57012 | tshark -r -

But there’s an even simpler way to read PCAP-over-IP with Wireshark and tshark, which doesn’t require netcat.

wireshark -k -i TCP@192.168.1.2:57012
tshark -i TCP@192.168.1.2:57012

The Wireshark name for this input method is “TCP socket” pipe interface, which is available in Linux, Windows and macOS builds of Wireshark as well as tshark.

PCAP-over-IP in Wireshark's Pipe Interfaces

It is also possible to add a PCAP-over-IP interface from Wireshark's GUI. Open Capture/Options, Manage Interfaces, Pipes Tab and then enter a Local Pipe Path such as TCP@127.0.0.1:57012 and click OK. This setting will disappear when you close Wireshark though, since pipe settings don't get saved.

Live Remote Sniffing

Sniffed traffic can be read remotely over PCAP-over-IP in real-time simply by forwarding a PCAP stream with captured packets to netcat like this:

tcpdump -U -w - not tcp port 57012 | nc -l 57012
dumpcap -P -f "not tcp port 57012" -w - | nc -l 57012
PCAP-over-IP with tcpdump, netcat and tshark

Tcpdump is not available for Windows, but dumpcap is since it is included with Wireshark.

Note how TCP port 57012 is purposely filtered out using BPF when capturing in order to avoid a snowball effect, where the PCAP-over-IP traffic otherwise gets sniffed and re-transmitted through the PCAP-over-IP stream, which again gets sniffed etc.

A more sophisticated setup would be to let the service listening on TCP port 57012 spawn the sniffer process, like this:

nc.traditional -l -p 57012 -c "tcpdump -U -w - not port 57012"

Or even better, let the listening service reuse port 57012 to allow multiple incoming PCAP-over-IP connections.

socat TCP-LISTEN:57012,reuseaddr,fork EXEC:"tcpdump -U -w - not port 57012"

Reading PCAP-over-IP with NetworkMiner

We added PCAP-over-IP support to NetworkMiner in 2011 as part of NetworkMiner 1.1, which was actually one year before the TCP socket sniffing feature was included in Wireshark.

Live remote sniffing with NetworkMiner 2.7.3 using PCAP-over-IP

Image: Live remote sniffing with NetworkMiner 2.7.3 using PCAP-over-IP

NetworkMiner can also be configured to listen for incoming PCAP-over-IP connections, in which case the sniffer must connect to the machine running NetworkMiner like this:
tcpdump -U -w - not tcp port 57013 | nc 192.168.1.3 57013
Note: TCP port 57013 is used by services that receive packets from a PCAP-over-IP stream to a listening socket. The more commong PCAP-over-IP port 57012 is used by services that send packets using PCAP-over-IP from a listening socket.

PCAP-over-IP is the recommended method for doing real-time analysis of live network traffic when running NetworkMiner in Linux or macOS, because NetworkMiner’s regular sniffing methods are not available on those platforms.

Reading Decrypted TLS Traffic from PolarProxy

PolarProxy

One of the most powerful use-cases for PCAP-over-IP is to read decrypted TLS traffic from PolarProxy. When PolarProxy is launched with the argument “--pcapoverip 57012” it starts a listener on TCP port 57012, which listens for incoming connections and pushes a real-time PCAP stream of decrypted TLS traffic to each client that connects. PolarProxy can also make active outgoing PCAP-over-IP connections to a specific IP address and port if the “--pcapoveripconnect <host>:<port>” argument is provided.

In the video PolarProxy in Windows Sandbox I demonstrate how decrypted TLS traffic can be viewed in NetworkMiner in real-time with help of PCAP-over-IP. PolarProxy’s PCAP-over-IP feature can also be used to read decrypted TLS traffic from PolarProxy with Wireshark as well as to send decrypted TLS traffic from PolarProxy to Arkime (aka Moloch).

Replaying PCAP-over-IP to an Interface

There are lots of great network monitoring products and intrusion detection systems that don’t come with a built-in PCAP-over-IP implementation, such as Suricata, Zeek, Security Onion and Packetbeat, just to mention a few. These products would greatly benefit from having access to the decrypted TLS traffic that PolarProxy can provide. Luckily we can use netcat and tcpreplay to replay packets from a PCAP-over-IP stream to a network interface like this:

nc localhost 57012 | tcpreplay -i eth0 -t -

But for permanent installations we recommend creating a dedicated dummy interface, to which the traffic gets replayed and sniffed, and then deploy a systemd service that performs the replay operation. See our blog post Sniffing Decrypted TLS Traffic with Security Onion for an example on how to deploy such a systemd service. In that blog post we show how decrypted TLS traffic from PolarProxy can be replayed to a local interface on a Security Onion machine, which is being monitored by Suricata and Zeek.

Nils Hanke has also compiled a detailed documentation on how decrypted TLS packets from PolarProxy can be replayed to Packetbeat and Suricata with help of tcpreplay.

In these setups netcat and tcpreplay act as a generic glue between a PCAP-over-IP service and tools that can sniff packets on a network interface, but there are a few drawbacks with this approach. One drawback is that tcpreplay requires root privileges in order to replay packets to an interface. Another drawback is that extra complexity is added to the solution and two additional single point of failures are introduced (i.e. netcat and tcpreplay). Finally, replaying packets to a network interface increases the risk of packet drops. We therefore hope to see built-in PCAP-over-IP implementations in more network monitoring solutions in the future!

FAQ for PCAP-over-IP

Q: Why is it called “PCAP-over-IP” and not “PCAP-over-TCP”?

Good question, we actually don’t know since we didn’t come up with the name. But in theory it would probably be feasible to read a PCAP stream over UDP or SCTP as well.

Q: What is the standard port for PCAP-over-IP?

There is no official port registered with IANA for PCAP-over-IP, but we’ve been using TCP 57012 as the default port for PCAP-over-IP since 2011. The Wireshark implementation, on the other hand, uses TCP port 19000 as the default value.

Q: Which software comes with built-in PCAP-over-IP servers or clients?

The ones we know of are: Arkime, NetworkMiner, PolarProxy, tshark and Wireshark. There is also a PCAP-over-IP plugin for Zeek (see update below).

Q: Is there some way to encrypt the PCAP-over-IP transmissions?

Yes, we recommend encrypting PCAP-over-IP sessions with TLS when they are transmitted across a non-trusted network. NetworkMiner’s PCAP-over-IP implementation comes with a “Use SSL” checkbox, which can be used to receive “PCAP-over-TLS”. You can replace netcat with socat or ncat in order to establish a TLS encrypted connection to NetworkMiner.

Q: Is there a tool that can aggregate multiple PCAP-over-IP streams into one?

No, none that we’re aware of. However, multiple PCAP-over-IP streams can be merged into one by specifying multiple PCAP-over-IP interfaces in dumpcap and then forwarding that output to a netcat listener, like this:

dumpcap -i TCP@10.1.2.3:57012 -i TCP@10.4.5.6:57012 -w - | editcap -F pcap - - | nc -l 57012

Update 2023-04-13

Erich Nahum has published zeek-pcapovertcp-plugin, which brings native PCAP-over-IP support to Zeek.

Erich's plugin can be installed as a zeek package through zkg.

zkg install zeek-pcapovertcp-plugin

After installing the plugin, a command like this reads a PCAP stream from a remote source:

zeek -i pcapovertcp::192.168.1.2:57012

Update 2025-11-27

Fox-IT have released pcap-broker, which can be used to distribute PCAP-over-IP to multiple clients. You can build and run pcap-broker as a Docker container like this:

git clone https://github.com/fox-it/pcap-broker.git
docker build -t pcap-broker pcap-broker/
docker run -it --net=host pcap-broker -cmd "tcpdump -U -w - not port 57012" -listen localhost:57012

Posted by Erik Hjelmvik on Monday, 15 August 2022 08:05:00 (UTC/GMT)

Tags: #PCAP-over-IP #PCAP #tcpdump #Wireshark #tshark #NetworkMiner #PolarProxy #Suricata #Zeek #Arkime #tcpreplay #netcat #ASCII-art

Short URL: https://netresec.com/?b=228fddf


Sniffing Decrypted TLS Traffic with Security Onion

Wouldn't it be awesome to have a NIDS like Snort, Suricata or Zeek inspect HTTP requests leaving your network inside TLS encrypted HTTPS traffic? Yeah, we think so too! We have therefore created this guide on how to configure Security Onion to sniff decrypted TLS traffic with help of PolarProxy.

Network drawing with Clients, SecurityOnion and the Internet

PolarProxy is a forward TLS proxy that decrypts incoming TLS traffic from clients, re-encrypts it and forwards it to the server. One of the key features in PolarProxy is the ability to export the proxied traffic in decrypted form using the PCAP format (a.k.a. libpcap/tcpdump format). This makes it possible to read the decrypted traffic with external tools, without having to perform the decryption again. It also enables packet analysis using tools that don't have built-in TLS decryption support.

This guide outlines how to configure PolarProxy to intercept HTTPS traffic and send the decrypted HTTP traffic to an internal network interface, where it can be sniffed by an IDS.

STEP 1 ☆ Install Ubuntu

Download and install the latest SecurityOnion ISO image, but don't run the "Setup" just yet.

STEP 2 ☆ Add a Dummy Network Interface

Add a dummy network interface called "decrypted", to which decrypted packets will be sent.

ip link add decrypted type dummy
ip link set decrypted arp off up
Add the commands above to /etc/rc.local before "exit 0" to have the network interface automatically configured after reboots.

dummy interface in rc.local

STEP 3 ☆ Install Updates

Install updates in Security Onion by running "sudo soup".

STEP 4 ☆ Run the Security Onion Setup

Run the Security Onion setup utility by double-clicking the "Setup" desktop shortcut or executing "sudo sosetup" from a terminal. Follow the setup steps in the Production Deployment documentation and select "decrypted" as your sniffing interface.

Sniffing Interface Selection Window

Reboot and run Setup again to continue with the second phase of Security Onion's setup. Again, select "decrypted" as the interface to be monitored.

STEP 5 ☆ Install PolarProxy Service

Download and install PolarProxy:

sudo adduser --system --shell /bin/bash proxyuser
sudo mkdir /var/log/PolarProxy
sudo chown proxyuser:root /var/log/PolarProxy/
sudo chmod 0775 /var/log/PolarProxy/

sudo su - proxyuser
mkdir ~/PolarProxy
cd ~/PolarProxy/
curl https://www.netresec.com/?download=PolarProxy | tar -xzf -
exit

sudo cp /home/proxyuser/PolarProxy/PolarProxy.service /etc/systemd/system/PolarProxy.service

Edit /etc/systemd/system/PolarProxy.service and add "--pcapoverip 57012" at the end of the ExecStart command.

--pcapoverip 57012 in PolarProxy.service

Start the PolarProxy systemd service:

sudo systemctl enable PolarProxy.service
sudo systemctl start PolarProxy.service

STEP 6 ☆ Install Tcpreplay Service

The decrypted traffic can now be accessed via PolarProxy's PCAP-over-IP service on TCP 57012. We can leverage tcpreplay and netcat to replay these packets to our dummy network interface in order to have them picked up by Security Onion.

nc localhost 57012 | tcpreplay -i decrypted -t -
However, it's better to create a systemd service that does this automatically on bootup. We therefore create a file called /etc/systemd/system/tcpreplay.service with the following contents:
[Unit]
Description=Tcpreplay of decrypted traffic from PolarProxy
After=PolarProxy.service

[Service]
Type=simple
ExecStart=/bin/sh -c 'nc localhost 57012 | tcpreplay -i decrypted -t -'
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

Start the tcpreplay systemd service:

sudo systemctl enable tcpreplay.service
sudo systemctl start tcpreplay.service

STEP 7 ☆ Add firewall rules

Security Onion only accepts incoming connections on TCP 22 by default, we also need to allow connections to TCP port 10443 (proxy port), and 10080 (root CA certificate download web server). Add allow rules for these services to the Security Onion machine's firewall:

sudo ufw allow in 10443/tcp
sudo ufw allow in 10080/tcp

Verify that the proxy is working by running this curl command on a PC connected to the same network as the Security Onion machine:

curl --insecure --connect-to www.netresec.com:443:[SecurityOnionIP]:10443 https://www.netresec.com/
Note: You can even perform this test from a Win10 PC, since curl is included with Windows 10 version 1803 and later.

Add the following lines at the top of /etc/ufw/before.rules (before the *filter section) to redirect incoming packets on TCP 443 to PolarProxy on port 10443.

*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -i enp0s3 -p tcp --dport 443 -j REDIRECT --to 10443
COMMIT

Note: Replace "enp0s3" with the Security Onion interface to which clients will connect.

After saving before.rules, reload ufw to activate the port redirection:

sudo ufw reload

Verify that you can reach the proxy on TCP 443 with this command:

curl --insecure --resolve www.netresec.com:443:[SecurityOnionIP] https://www.netresec.com/

STEP 8 ☆ Redirect HTTPS traffic to PolarProxy

It's now time to configure a client to run its HTTPS traffic through PolarProxy. Download and install the PolarProxy X.509 root CA certificate from PolarProxy's web service on TCP port 10080:

http://[SecurityOnionIP]:10080/polarproxy.cer

Install the certificate in the operating system and browser, as instructed in the PolarProxy documentation.

You also need to forward packets from the client machine to the Security Onion machine running PolarProxy. This can be done either by configuring a local NAT rule on each monitored client (STEP 8.a) or by configuring the default gateway's firewall to forward HTTPS traffic from all clients to the proxy (STEP 8.b).

STEP 8.a ☆ Local NAT

Use this firewall rule on a Linux client to configure it to forward outgoing HTTPS traffic to the Security Onion machine:

sudo iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to [SecurityOnionIP]

STEP 8.b ☆ Global NAT Network drawing Firewall, PolarProxy, Clients

If the client isn't running Linux, or if you wanna forward HTTPS traffic from a whole network to the proxy, then apply the following iptables rules to the firewall in front of the client network. See "Routing Option #2" in the PolarProxy documentation for more details.

  1. Add a forward rule on the gateway to allow forwarding traffic to our PolarProxy server:
    sudo iptables -A FORWARD -i eth1 -d [SecurityOnionIP] -p tcp --dport 10443 -m state --state NEW -j ACCEPT
  2. Add a DNAT rule to forward 443 traffic to PolarProxy on port 10443:
    sudo iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j DNAT --to [SecurityOnionIP]:10443
  3. If the reverse traffic from PolarProxy to the client doesn't pass the firewall (i.e. they are on the same LAN), then we must add this hide-nat rule to fool PolarProxy that we are coming from the firewall:
    sudo iptables -t nat -A POSTROUTING -o eth1 -d [SecurityOnionIP] -p tcp --dport 10443 -j MASQUERADE
For other network configurations, please see the various routing setups in the PolarProxy documentation.

STEP 9 ☆ Inspect traffic in SecurityOnion

Wait for the Elastic stack to initialize, so that the intercepted network traffic becomes available through the Kibana GUI. You can check the status of the elastic initialization with "sudo so-elastic-status".

You should now be able to inspect decrypted traffic in Security Onion using Kibana, Squert, Sguil etc., just as if it was unencrypted HTTP.

Bro HTTP traffic in Kibana Image: Kibana showing HTTP traffic info from decrypted HTTPS sessions

MIME types in Kibana Image: MIME types in Kibana

NIDS alerts in Kibana Image: NIDS alerts from payload in decrypted traffic shown in Kibana

Snort alerts in Squert Image: Snort alerts from decrypted traffic shown in Squert

Security Considerations and Hardening

Security Onion nodes are normally configured to only allow access by SOC/CERT/CSIRT analysts, but the setup described in this blog post requires that "normal" users on the client network can access the PolarProxy service running on the Security Onion node. We therefore recommend installing PolarProxy on a dedicated Security Onion Forward Node, which is configured to only monitor traffic from the proxy.

We also recommend segmenting the client network from the analyst network, for example by using separate network interfaces on the Security Onion machine or putting it in a DMZ. Only the PolarProxy service (TCP 10080 and 10443) should be accessable from the client network.

PolarProxy could be used to pivot from the client network into the analyst network or to access the Apache webserver running on the Security Onion node. For example, the following curl command can be used to access the local Apache server running on the Security Onion machine via PolarProxy:

curl --insecure --connect-to localhost:443:[SecurityOnionIP]:10443 https://localhost/
We therefore recommend adding firewall rules that prevent PolarProxy from accessing the analyst network as well as the local Apache server.

Hardening Steps:

  • Configure the Security Onion node as a Forward Node
  • Segment client network from analyst network
  • Add firewall rules to prevent PolarProxy from accessing services on the local machine and analyst network

For additional info on hardening, please see the recommendations provided by Wes Lambert on the Security-Onion mailing list.

Posted by Erik Hjelmvik on Monday, 20 January 2020 09:40:00 (UTC/GMT)

Tags: #SecurityOnion #Security Onion #PCAP #Bro #Zeek #PolarProxy #Snort #Suricata #TLS #SSL #HTTPS #tcpreplay #PCAP-over-IP #IDS #NIDS #netcat #curl #UFW #ASCII-art

Short URL: https://netresec.com/?b=2013af4


Detecting the Pony Trojan with RegEx using CapLoader

This short video demonstrates how you can search through PCAP files with regular expressions (regex) using CapLoader and how this can be leveraged in order to improve IDS signatures.

The EmergingThreats snort/suricata rule mentioned in the video is SID 2014411 “ET TROJAN Fareit/Pony Downloader Checkin 2”.

The header accept-encoding header with quality factor 0 used by the Pony malware is:
Accept-Encoding: identity, *;q=0

And here is the regular expression used to search for that exact header: \r\nAccept-Encoding: identity, \*;q=0\r\n

After recording the video I noticed that the leaked source code for Pony 2.0 actually contains this accept-encoding header as a hard-coded string. Have a look in the redirect.php file, where they set curl’s CURLOPT_HTTPHEADER to this specific string.

Pony using curl to set: Accept-Encoding: identity, *;q=0

Wanna learn more about the intended use of quality factors in HTTP accept headers? Then have a look at section 14.1 of RFC 2616section 5.3.4 of RFC 7231, which defines how to use qvalues (i.e. quality factors) in the Accept-Encoding header.

Finally, I'd like to thank Brad Duncan for running the malware-traffic-analysis.net website, your PCAP files often come in handy!

Update 2018-07-05

I submitted a snort/suricata signature to the Emerging-Sigs mailinglist after publishing this blog post, which resulted in the Emerging Threats signature 2014411 being updated on that same day to include:

content:"|0d 0a|Accept-Encoding|3a 20|identity,|20 2a 3b|q=0|0d 0a|"; http_header;

Thank you @EmergingThreats for the fast turnaround!

Posted by Erik Hjelmvik on Wednesday, 04 July 2018 07:39:00 (UTC/GMT)

Tags: #video #regex #malware #IDS #curl #malware-traffic-analysis.net #videotutorial

Short URL: https://netresec.com/?b=187e291


Zyklon Malware Network Forensics Video Tutorial

We are releasing a series of network forensics video tutorials throughout the next few weeks. First up is this analysis of a PCAP file containing network traffic from the "Zyklon H.T.T.P." malware.

Analyzing a Zyklon Trojan with Suricata and NetworkMiner

Resources
https://www.malware-traffic-analysis.net/2017/07/22/index.html
https://github.com/Security-Onion-Solutions/security-onion
https://www.arbornetworks.com/blog/asert/wp-content/uploads/2017/05/zyklon_season.pdf
http://doc.emergingthreats.net/2017930

IOCs
service.tellepizza.com
104.18.40.172
104.18.41.172
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3pre) Gecko/20070302 BonEcho/2.0.0.3pre
gate.php
.onion
98:1F:D2:FF:DC:16:B2:30:1F:11:70:82:3D:2E:A5:DC
65:8A:5C:76:98:A9:1D:66:B4:CB:9D:43:5C:DE:AD:22:38:37:F3:9C
E2:50:35:81:9F:D5:30:E1:CE:09:5D:9F:64:75:15:0F:91:16:12:02:2F:AF:DE:08:4A:A3:5F:E6:5B:88:37:D6

Posted by Erik Hjelmvik on Monday, 05 February 2018 07:30:00 (UTC/GMT)

Tags: #Netresec #PCAP #Trojan #video #tutorial #videotutorial #NetworkMiner #SecurityOnion #Suricata #malware #network #forensics #NSM #malware_traffic

Short URL: https://netresec.com/?b=182b4ac