NetworkMiner in FLARE VM

NetworkMiner is now available as a package in the reverse engineering platform FLARE VM. You can either select the networkminer.vm package in the installer or install NetworkMiner later on from the command line.

NetworkMiner can be installed in FLARE VM from an admin shell by running

After installation you’ll find NetworkMiner in the “Networking” category together with FakeNet-NG and Wireshark.

FLARE VM allows NetworkMiner to be launched by running the command “networkminer”, optionally with a PCAP file as an argument.

Posted by Erik Hjelmvik on Monday, 12 December 2022 10:50:00 (UTC/GMT)

Tags: #NetworkMiner​

What is a PCAP file?

A PCAP file is a container for packets captured on a computer network, such as a WiFi or Ethernet network. Each packet in a PCAP file is tagged with a timestamp indicating when it was captured.

The term PCAP is short for Packet CAPture. Other common names are capture file, trace file, packet trace, packet dump, dumpfile and pcap savefile. The PCAP file format was created by Van Jacobson, Craig Leres and Steven McCanne around 1987 as part of the work they did on tcpdump and libpcap at the Lawrence Berkeley Laboratory.

PCAP File Header Format

A PCAP file always starts with a 24 byte header, referred to as pcap_file_header in the libpcap source code, which contains the following fields:

• Magic Number (4 bytes) = d4 c3 b2 a1
• Version Major (2 bytes) = 02 00
• Version Minor (2 bytes) = 04 00
• Timezone (4 bytes) = 00 00 00 00
• Timestamp Accuracy (4 bytes) = 00 00 00 00
• Snap Length (4 bytes)
• Link-Layer Type (4 bytes)

As shown above, the first 16 bytes in the PCAP header have fixed values. There is one common exception though, which is when the field values are encoded as big endian rather than little endian. A big endian capture file typically starts with these 8 bytes:

• Magic Number (4 bytes) = a1 b2 c3 d4
• Version Major (2 bytes) = 00 02
• Version Minor (2 bytes) = 00 04

There are a few additional magic number variants, such as “4d 3c b2 a1” used to indicate nanosecond timestamps and FRITZ!Box’s “34 cd b2 a1”, as well as big endian versions of those magic numbers.

The timezone and accuracy fields aren’t used in practice, they should therefore be all zeroes.

The snap length value is a 32 bit number indicating the maximum packet size that can be stored in the PCAP without truncating the packet data. This value is often “00 00 04 00” (256 kB) or “ff ff 00 00” (65535 bytes), but can in theory be any value except zero.

The link layer type defines which type of packets the capture file contains. As an example, if the link-layer field is “01 00 00 00” in a little endian PCAP file, then all packets in that file should be parsed as Ethernet packets.

Some of the most common link-layer type values are:

• 01 00 00 00 = IEEE 802.3 Ethernet
• 65 00 00 00 = Raw IP packets (no layer 2 header)
• 69 00 00 00 = IEEE 802.11 (WiFi)
• 71 00 00 00 = SLL (Linux "cooked" capture encapsulation)
• 77 00 00 00 = Prism header + IEEE 802.11 (WiFi)
• 7f 00 00 00 = Radiotap header + IEEE 802.11 (WiFi)
• c3 00 00 00 = IEEE 802.15.4 (Zigbee)
• c5 00 00 00 = Endace ERF
• e4 00 00 00 = Raw IPv4 (no layer 2 header)

A list of all link layer type values is available on the tcpdump website.

Packet Header Format

Each captured packet in a PCAP file is prefixed by a 16 byte header, referred to as pcap_sf_pkthdr in the libpcap source code, which contains the following fields:

• Timestamp Seconds (4 bytes)
• Timestamp Microseconds (4 bytes)
• Captured Length (4 bytes)
• Original Length (4 bytes)

The “timestamp seconds” field is a standard epoch or Unix time field, indicating the number of seconds that have elapsed since 1 January 1970. As you’ve probably guessed, the microsecond field indicates the microsecond fractions of the packet timestamp. However, PCAP files with the magic number “4d 3c b2 a1” in the file header use this field to represent nanosecond fractions instead. The nanosecond variant makes a lot of sense, since only 20 bits of this 32 bit field are used when representing microsecond fractions, but 30 bits are needed to represent nanosecond fractions.

The captured length field indicates the number of bytes of packet data that follows after the 16 byte packet header. This value should never be larger than the snap length value in the PCAP file header.

The original length field indicates the size of the actual packet on the network. This value is typically the same as the captured length, provided that a large enough snap length was used when capturing packets.

Packet Data

Following right after each packet header is the actual packet data that was being transferred over the network. This data is written to the PCAP file exactly as it was received, without caring about endianness or correctness of the data.

Now that I’ve covered all the different parts of a PCAP file, let’s have a look at the contents of an actual PCAP file.

The data in the illustration above was cut off after the second packet header, but you get the idea. A PCAP file can contain an unlimited number of packet headers and packets, but there can only be one PCAP file header per file.

I’d also like to stress the fact that the endianness defined in the PCAP file header doesn’t affect how the packet data gets stored in the packet data. Most network protocols use big endian encoding, but most PCAP files — including the one in the illustration above — use little endian. That’s why the TCP destination port 80 is encoded as “00 50” in the packet data, even though the little endian “d4 c3 b2 a1” magic number is specified in the PCAP file header.

Other Packet Capture Formats

The PCAP file format is by far the most widely used one for storing packet data, but it's not the only one. Common alternative packet capture formats are PcapNG, ETL and Endace ERF.

Posted by Erik Hjelmvik on Thursday, 27 October 2022 06:50:00 (UTC/GMT)

Tags: #pcap​ #tcpdump​ #libpcap​

IcedID BackConnect Protocol

This is a follow-up to my Hunting for C2 Traffic video. But I didn't have time to record a short video this time, so I wrote a long blog post instead.

UPDATE 2022-11-02

Brad Duncan has released a new pcap file on malware-traffic-analysis.net, which contains an additional C2 command (0x12). Our analysis indicates that this command launches a file manager. This blog post has now been updated with details about this finding.

UPDATE 2022-11-09

Lenny Hansson has released IDS signatures that detect BackConnect traffic. More details further down in this blog post.

UPDATE 2022-12-05

Lenny has updated his IDS signatures to alert on BackConnect C2 traffic from port 443 in addition to 8080. The signatures in this blog post have now been updated to Lenny's new rev:2 signatures.

UPDATE 2023-04-14

Brad Duncan made the following suggestion in a toot yesterday:

If the protocol for this VNC traffic from Qakbot looks the same as the BackConnect traffic from IcedID infections, perhaps we can just call it BackConnect Protocol without specifying "IcedID"

This is an excellent idea, since IcedID, QakBot as well as Bazar have all been seen using the same BackConnect protocol. We will therefore refer to the protocol described in this blog post as just the “BackConnect Protocol” from now on. This blog post has also been updated accordingly.

UPDATE 2023-10-02

The release of NetworkMiner 2.8.1 adds a BackConnect protocol parser to NetworkMiner.

IcedID BackConnect C2 Packet Structure

The BackConnect (BC) module uses a proprietary command-and-control (C2) protocol that is pretty straight forward. Both client (bot) and the C2 server typically send commands and responses as 13 byte packets using the following structure:

• Auth: 4 bytes
• Command: 1 byte
• Params: 4 bytes
• ID: 4 bytes

Auth Field

The "Auth" field is presumably used by the bot and C2 server to verify that the other party is communicating using the same protocol and version.

As mentioned by Group-IB and xors the Auth field is typically 0x974F014A (little endian), but we prefer to use the network byte order representation "4a 01 4f 97".

In their IcedID blog post from 2020 Group-IB say:

the auth field that has not changed since at least version 5 of the IcedID core is the constant 0x974F014A

Nevertheless, we recently noticed another BackConnect Auth field being used in the wild. But more on that later.

Commands

The following list of BackConnect C2 commands has been compiled by combining those mentioned by Group-IB with our own analysis of the BackConnect protocol:

• 0x00 = Bot queries for a task
• 0x01 = Set sleep timer
• 0x02 = Bot error
• 0x03 = Reconnect
• 0x04 = Start SOCKS
• 0x05 = Start VNC

We've also discovered these additional commands in BackConnect C2 traffic that uses the Auth value "1f 8b 08 08":

• 0x11 = Start VNC
• 0x12 = Start file manager
• 0x13 = Start reverse shell

Commands 0x04, 0x05, 0x11, 0x12 and 0x13 all cause the bot to connect back to the C2 server using a new BackConnect session, which will be used to wrap either SOCKS, VNC, file manager or reverse shell traffic.

Command 0x01: Set Sleep Timer

The set sleep timer command is issued by the C2 server to instruct the bot to sleep for a certain amount of time before requesting a new task from the C2 server again. The sleep time is defined in the four bytes following directly after the 0x01 command. This value is a 32-bit little endian value indicating the number of seconds the bot should sleep, i.e. "3c 00 00 00" = 0x0000003c = 60 seconds. The most common sleep value seems to be 60 seconds, which is why you'll often see byte sequences like this in IcedID C2 sessions:

zz zz zz zz 01 3c 00 00 00 xx xx xx xx

The following Wireshark display filter will show BackConnect C2 packets, where the bot is configured to sleep for 60 seconds before querying the C2 server for a new command:

tcp.len == 13 and tcp.payload[4:5] == 01:3c:00:00:00

Command 0x04: Start SOCKS

The SOCKS command (0x04) instructs the bot to start the SOCKS module. As an example, the following byte sequence was sent by the IcedID C2 server 91.238.50.80:8080 in Brad Duncan's 2022-06-28 TA578 IcedID pcap on malware-traffic-analysis.net (see frame #10231):

4a 01 4f 97 04 09 00 00 00 8c a2 b1 09

The first four bytes are the auth value, followed by the Start SOCKS command (04).

After receiving this command the bot established a new TCP connection back to the C2 server, where it echoed back the server's "Start SOCKS" command and then started acting like a SOCKS server.

Except for initially echoing the BackConnect Start SOCKS command the SOCKS module actually seems to be compliant with RFC1928, which defines the SOCKS5 protocol. This means that the C2 server can supply an IP address and port number to the bot's SOCKS proxy in order to relay a connection to that host through the bot.

Image: C2 server instructs bot to relay a connection to 188.40.30.100:80

After receiving a Start SOCKS command an IcedID bot immediately establishes a new TCP connection to the specified IP and port, and relays the application layer data back to the C2 server through the SOCKS connection.

Image: Update check of Advanced Port Scanner relayed through the infected machine

In the 2022-06-28 TA578 IcedID pcap the attacker used multiple SOCKS connections to scan the 10.6.21.0/24 network for services running on TCP ports 21, 80, 445 and 4899. That last port (TCP 4899) is typically used by Radmin VPN, which just so happens to be created by the outfit "Famatech" who also develop the "Advanced Port Scanner". The attacker also used the SOCKS module to make several HTTPS connections to servers like 18.204.62.252 (tlx.3lift[.]com), 23.94.138.115 (cmd5[.]org) and 74.119.118.137 (cat.da.us.criteo[.]com). The attacker also proxied connections to 40.97.120.242 and 52.96.182.162 (outlook.live.com) through the infected bot.

NetworkMiner showing hosts that the bot proxied TLS traffic to

JA3 Fingerprints from Proxied Traffic

Since the SOCKS proxy doesn't touch the application layer data we know that the client TLS handshake packets are coming from the C2 server rather than from the bot that's running the SOCKS proxy. This means that we can fingerprint the actual TLS client using JA3.

As you can see in the CapLoader screenshot above, most proxied TLS sessions use the cd08e31494f9531f560d64c695473da9 JA3 hash, but two of them use the rare JA3 hash 598872011444709307b861ae817a4b60. That rare JA3 hash was used only when connecting to outlook.live.com.

Command 0x05 or 0x11: VNC

Brad Duncan's 2022-06-28 TA578 IcedID pcap also contains the "Start VNC" command 0x05.

Image: Flow transcript of Start VNC command

As can be seen in the CapLoader screenshot above, Start VNC commands were sent at 16:33:33 and 16:34:06 UTC. And just like the SOCKS command, this caused the bot to establish a new connection back to the C2 server, echo the "Start VNC" command and then proceed with the VNC traffic.

Image: Flow transcript of IcedID VNC traffic in ASCII encoding

Command 0x13: Reverse Shell

Brad posted a new capture file with network traffic from another IcedID infection last week (2022-10-04). He also noted that the traffic to 51.89.201.236:8080 was different from normal IcedID post-infection traffic.

After looking at this C2 traffic I discovered that it was in fact using the IcedID BackConnect protocol outlined in this blog post, but the Auth field "4a 01 4f 97" had been replaced with "1f 8b 08 08".

That exact byte sequence is a common file header for gzip compressed files (RFC1952), where

• 1f 8b = GZIP magic
• 08 = DEFLATE compression
• 08 = Original file name header present

IcedID has previously been seen using fake gzip file headers in payloads, but this time even the C2 packets include the gzip header!

Image: Transcript of TCP session to 51.89.201.236:8080

The C2 traffic also contained the command 0x13, which I hadn't seen before. Just like the SOCKS and VNC commands, this one triggered the bot to establish a new connection back to the C2 server. But the bot sent a task query command (00) this time, instead of echoing the C2 server's command (0x13). The new TCP session then transitioned into what looks like a reverse shell session.

Image: Transcript of reverse shell traffic from IcedID BackConnect session

The reverse shell traffic reveals that the attackers retrieved a list of domain admin users and then executed a PowerShell script from aicsoftware[.]com. This PowerShell script was used to install CobaltStrike beacon on the victim's PC.

Command 0x12: File Manager

We discovered the file manager command after this blog post was published. This section has therefore been added after the original publication of this blog post.

The following Wireshark display filter can be used to find file manager commands (0x12) in BackConnect C2 traffic that uses the "1f 8b 08 08" auth value:

tcp.len == 13 and tcp.payload[0:5] == 1f:8b:08:08:12

Image: File manager commands in BackConnect C2

The screenshot above shows that the file manager command was issued three times in 2022-10-31-IcedID-with-DarkVNC-and-Cobalt-Strike-full-pcap-raw.pcap.

Image: BackConnect TCP sessions in CapLoader's Flows view

As you can see in the two screenshots above, each time a file manager command was issued in the C2 session (Wireshark screenshot) the bot established a new TCP connection back to the C2 server (CapLoader screenshot).

The file manager sessions use a proprietary protocol to perform tasks such as listing disks, changing directory and uploading files.

We've identified the following file manager commands:

• DISK = List drives
• CDDIR <path> = Change directory
• PWD = Show current directory
• DIR = List current directory
• PUT <path> = Upload file

IDS Signatures

Lenny Hansson has released IDS signatures that can detect IcedID (and QakBot) BackConnect traffic. I'd like to highlight four of Lenny's signatures here.

Alert on "sleep 60 seconds" C2 command, regardless of Auth value:

alert tcp $EXTERNAL_NET [443,8080] -> $HOME_NET 1024: (msg:"NF - Malware IcedID BackConnect - Wait Command"; flow:established; flags:AP; dsize:13; content:"|01 3c 00 00 00|"; offset:4; depth:5; reference:url,networkforensic.dk; metadata:02112022; classtype:trojan-activity; sid:5006006; rev:3;)

Alert on "start VNC" C2 command with "4a 01 4f 97" Auth:

alert tcp $EXTERNAL_NET [443,8080] -> $HOME_NET 1024: (msg:"NF - Malware IcedID BackConnect - Start VNC command"; flow:established; flags:AP; dsize:13; content:"|4a 01 4f 97 05|"; offset:0; depth:5; reference:url,networkforensic.dk; metadata:03112022; classtype:trojan-activity; sid:5006007; rev:2;)

Alert on "start VNC" C2 command with "1f 8b 08 08" Auth:

alert tcp $EXTERNAL_NET [443,8080] -> $HOME_NET 1024: (msg:"NF - Malware IcedID BackConnect - Start VNC command - 11"; flow:established; flags:AP; dsize:13; content:"|1f 8b 08 08 11|"; offset:0; depth:5; reference:url,networkforensic.dk; metadata:03112022; classtype:trojan-activity; sid:5006011; rev:2;)

Alert on "start file manager" C2 command with "1f 8b 08 08" Auth:

alert tcp $EXTERNAL_NET [443,8080] -> $HOME_NET 1024: (msg:"NF - Malware IcedID BackConnect - Start file manager command"; flow:established; flags:AP; dsize:13; content:"|1f 8b 08 08 12|"; offset:0; depth:5; reference:url,networkforensic.dk; metadata:03112022; classtype:trojan-activity; sid:5006008; rev:2;)

A zip file containing Lenny's Snort rules can be downloaded from networkforensic.dk.

Questions and Answers

Allright, that's all I had to say about the IcedID BackConnect C2 protocol. I'm now ready to take your questions.

Q: Is IcedID's BackConnect VNC traffic the same thing as DarkVNC?

No, DarkVNC traffic doesn't use the BackConnect C2 Packet Structure described in this blog post. Also, one characteristic behavior DarkVNC is that the first C2 packet contains a string that looks like one of these:

• (COMPUTERNAME)_ADDITIONAL_ID-DARKVNC
• BOT-COMPUTERNAME(USERNAME)_ID-REFnnn
• USR-COMPUTERNAME(USERNAME)_ID-REFnnn

Q: Is IcedID's BackConnect VNC traffic the same thing as hVNC?

Almost. hVNC means "hidden VNC" and includes any type of malicious VNC server running on a victim's PC, including IcedID's VNC module as well as DarkVNC.

Q: How did you get Wireshark to decode the SOCKS traffic from IcedID BackConnect?

1. Open the pcap file from 2022-06-28 TA578 IcedID
2. Apply display filter: tcp.port eq 8080
3. Right-click, Decode As, TCP port 8080 = SOCKS
4. Display filter: tcp.dstport eq 8080 and tcp.len eq 13 and tcp.payload[0:5] eq 4a:01:4f:97:04
5. Select all packets (Ctrl+A)
6. Edit, Ignore Packets (Ctrl+D)
7. Display filter: socks.dst

Q: Can CapLoader's Protocol Identification feature detect the BackConnect protocol?

The version used in this blog post (1.9.4) doesn't have a protocol model for the BackConnect protocol, but later versions can identify IcedID's BackConnect protocol regardless of port. CapLoader version 1.9.5 (and later) also alerts on BackConnect traffic.

Posted by Erik Hjelmvik on Wednesday, 12 October 2022 18:24:00 (UTC/GMT)

Tags: #IcedID​ #QakBot​ #QBot​ #TA578​ #BackConnect​ #SOCKS​ #SOCKS5​ #VNC​ #JA3​ #gzip​ #PowerShell​

Hunting for C2 Traffic

In this video I look for C2 traffic by doing something I call Rinse-Repeat Threat Hunting, which is a method for removing "normal" traffic in order to look closer at what isn't normal.

The video was recorded in a Windows Sandbox in order to avoid accidentally infecting my Windows PC with malware.

The PCAP files analyzed in the video are:

• 2022-06-27-part-1-of-2-Qakbot-with-Cobalt-Strike-and-DarkVNC.pcap
• 2022-06-27-part-2-of-2-Qakbot-with-DarkVNC-and-email-banner-traffic.pcap
• 2022-06-28-TA578-IcedID-with-Cobalt-Strike-raw.pcap

Thank you for sharing these capture files Brad!

IOC List

• QBot source: 23.29.125.210
• QBot md5: 2b55988c0d236edd5ea1a631ccd37b76
• QBot sha1: 033a22c3bb2b0dd1677973e1ae6280e5466e771c
• QBot sha256: 2d68755335776e3de28fcd1757b7dcc07688b31c37205ce2324d92c2f419c6f0
• Qbot proxy protocol server: 23.111.114.52:65400
• QBot C2: 45.46.53.140:2222
• QBot C2 JA3: 51c64c77e60f3980eea90869b68c58a8
• QBot C2 JA3S : 7c02dbae662670040c7af9bd15fb7e2f
• QBot X.509 domain: thdoot.info
• QBot X.509 thumbprint: 5a8ee4be30bd5da709385940a1a6e386e66c20b6
• IcedID BackConnect server: 78.31.67.7:443
• IcedID BackConnect server: 91.238.50.80:8080

References and Links

• herALook.dat (MalwareBazaar)
• herALook.dat (VirusTotal)
• Qbot proxy protocol details (Securelist)
• QBot JA3 hash (DFIR Report)
• IcedID BackConnect protocol (Group-IB)

Update 2022-10-13

Part two of this analysis has been published: IcedID BackConnect Protocol

Posted by Erik Hjelmvik on Friday, 30 September 2022 12:37:00 (UTC/GMT)

Tags: #Threat Hunting​ #PCAP​ #CapLoader​ #NetworkMiner​ #NetworkMiner Professional​ #Video​ #QBot​ #QakBot​ #51c64c77e60f3980eea90869b68c58a8​ #IcedID​ #TA578​

What is 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:

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):

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

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.

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 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:

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

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.

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

This PCAP-over-IP feature is actually 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

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:

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:

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.

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

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​

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​

Real-time PCAP-over-IP in Wireshark

Did you know that it is possible to stream captured packets from a remote device or application to Wireshark in real-time using PCAP-over-IP? This blog post explains how you can configure Wireshark to read decrypted TLS packets directly from PolarProxy over a TCP socket.

PolarProxy

PolarProxy is a TLS proxy that decrypts and re-encrypts TLS traffic, while also saving the decrypted traffic in a PCAP file. Users who wish to inspect the decrypted TLS traffic in Wireshark typically open this file from disk, but that doesn’t allow for a real-time view of the traffic.

PolarProxy comes with a feature called PCAP-over-IP, which provides a real-time PCAP stream with decrypted packets to connecting clients. If you start PolarProxy with “--pcapoverip 57012” then a PCAP-over-IP listener will be set up on TCP port 57012. I have previously demonstrated how this decrypted stream can be read by NetworkMiner, but it was not until recently that I learned that the same thing can be done with Wireshark as well.

PCAP-over-IP in Wireshark

There’s a little known feature in Wireshark that allows a PCAP stream to be read from a TCP socket, which is exactly what PCAP-over-IP is! To connect to a PolarProxy PCAP-over-IP service on the local PC, do as follows:

1. Capture > Options (or Ctrl+K)
2. “Manage Interfaces...”
3. Select the “Pipes” tab
4. Click the “+” button
5. Name the pipe “TCP@127.0.0.1:57012” and press ENTER to save it.
   
6. Click “OK” in the Manage Interface window.
7. Click “Start” to inspect decrypted traffic from PolarProxy in real-time.

This setup works on Windows, Linux and macOS. Just remember to replace 127.0.0.1 with the IP of PolarProxy in case it is running on a remote machine.

Image: Real-time view of HTTP2 packets from decrypted TLS traffic

It’s also possible to read PCAP-over-IP with the command line tool tshark like this:

The PCAP-over-IP params can also be supplied to Wireshark on the command line in a similar manner:

Happy sniffing!

Posted by Erik Hjelmvik on Tuesday, 24 May 2022 14:00:00 (UTC/GMT)

Tags: #pcapoverip​ #Wireshark​ #PolarProxy​ #PCAP​

Emotet C2 and Spam Traffic Video

This video covers a life cycle of an Emotet infection, including initial infection, command-and-control traffic, and spambot activity sending emails with malicious spreadsheet attachments to infect new victims.

The video was recorded in a Windows Sandbox in order to avoid accidentally infecting my Windows PC with malware.

Initial Infection

Palo Alto's Unit 42 sent out a tweet with screenshots and IOCs from an Emotet infection in early March. A follow-up tweet by Brad Duncan linked to a PCAP file containing network traffic from the infection on Malware-Traffic-Analysis.net.

Image: Screenshot of original infection email from Unit 42

• Attachment MD5: 825e8ea8a9936eb9459344b941df741a

Emotet Download

The PCAP from Malware-Traffic-Analysis.net shows that the Excel spreadsheet attachment caused the download of a DLL file classified as Emotet.

Image: CapLoader transcript of Emotet download

• DNS: diacrestgroup.com
• MD5: 99f59e6f3fa993ba594a3d7077cc884d

Emotet Command-and-Control

Just seconds after the Emotet DLL download completes the victim machine starts communicating with an IP address classified as a botnet command-and-control server.

Image: Emotet C2 sessions in CapLoader

• C2 IP: 209.15.236.39
• C2 IP: 147.139.134.226
• C2 IP: 134.209.156.68
• JA3: 51c64c77e60f3980eea90869b68c58a8
• JA3S: ec74a5c51106f0419184d0dd08fb05bc
• JA3S: fd4bc6cea4877646ccd62f0792ec0b62

Emotet Spambot

The victim PC eventually started sending out spam emails. The spam bot used TLS encryption when possible, either through SMTPS (implicit TLS) or with help of STARTTLS (explicit TLS).

Image: Emotet spambot JA3 hash in NetworkMiner Professional

• SMTPS JA3: 37cdab6ff1bd1c195bacb776c5213bf2
• STARTTLS JA3: 37cdab6ff1bd1c195bacb776c5213bf2

Transmitted Spam

Below is a spam email sent from the victim PC without TLS encryption. The attached zip file contains a malicious Excel spreadsheet, which is designed to infect new victims with Emotet.

Image: Spam email extracted from Emotet PCAP with NetworkMiner

• .zip Attachment MD5: 5df1c719f5458035f6be2a071ea831db
• .xlsm Attachment MD5: 79cb3df6c0b7ed6431db76f990c68b5b

Network Forensics Training

If you want to learn additional techniques for analyzing network traffic, then take a look at our upcoming network forensic trainings.

Posted by Erik Hjelmvik on Monday, 09 May 2022 06:50:00 (UTC/GMT)

Tags: #Emotet​ #C2​ #video​ #pcap​ #JA3​ #JA3S​ #51c64c77e60f3980eea90869b68c58a8​ #ec74a5c51106f0419184d0dd08fb05bc​ #fd4bc6cea4877646ccd62f0792ec0b62​ #SMTP​ #SMTPS​ #Windows Sandbox​