NETRESEC Network Security Blog

CapLoader 2.1.0 Released

Erik Hjelmvik — Wed, 27 May 2026 09:15:00 GMT

CapLoader has been updated to version 2.1.0. The new release comes with better JA3/JA4 extraction and integration of additional threat-intel and OSINT services. We have also added support for more encapsulation protocols.

TLS Client Hello Reassembly

TLS handshakes no longer reliably fit in a single packet. Modern TLS features, like post-quantum key exchanges and Encrypted Client Hello (ECH), often expand handshake sizes across multiple TCP segments. The same trend appears in QUIC traffic, where TLS handshakes now often are too large to fit in a single UDP packet.

As a result, packet‑analysis tools that parse live traffic or PCAP files (like CapLoader) must cache partial TLS handshakes and reassemble them to recover the complete TLS ClientHello messages. NetworkMiner and FlowCarp already perform TLS handshake reassembly; CapLoader now supports it as well. This enables CapLoader to extract metadata from large TLS handshakes, including SNI hostnames, JA3 hashes and JA4 fingerprints.

The screenshot above shows CapLoader displaying information extracted from PCAP files that contain TLS and QUIC traffic with multi‑segment TLS 1.3 handshakes. The visible JA4 fingerprints for the client handshakes are:

q13d0311h3_55b375c5d22e_5a1f323ef56d − HTTP/3 w/ ECH
t13d1516h2_8daaf6152771_02713d6af862 − HTTP/2 w/ ECH
t13d1517h2_8daaf6152771_b0da82dd1658 − HTTP/2 w/ ECH
t13d1515h2_8daaf6152771_f37e75b10bcc − HTTP/2
t13d1516h2_8daaf6152771_9b887d9acb53 − HTTP/2

All these handshakes support post-quantum key agreements with a 1216 byte X25519MLKEM768 key. The first three listed JA4 fingerprints also use ECH.

Threat Intel and OSINT

CapLoader now matches network traffic against indicators of compromise (IOCs) from Johannes Bader's open source threat intelligence platform Rösti. An alert is raised whenever the analysed traffic matches any of the following IOC types on Rösti:

domain
domain:port
IP
IP:port

When a match occurs, CapLoader raises an alert on the flow/service and includes the matching IOC type and value. Rösti aggregates IOCs from public feeds, researchers, and threat‑intel providers (including IOCs published on this blog).

We have also extended the OSINT lookup shortcuts in CapLoader to include the following websites:

BGP.Tools (IP lookup)
IPinfo (IP lookup)
Netify (IP lookup)
ScanMalware (domain, IP and ASN lookups)

Right-click a flow/service/host/alert in CapLoader and select "Lookup [domain/IP/ASN] at...", which opens the chosen OSINT site in a browser tab with info about the domain/IP/ASN.

Encapsulated Protocols

CapLoader already decapsulates GRE, VXLAN, CapWap, Teredo, GTP-U, TZSP as well as IP-in-IP.

With this release we add support for extracting traffic from the following encapsulation protocols:

Aruba GRE encapsulated WiFi
Geneve (RFC 8926)
GRE in UDP (RFC 8086) to ports 4754 and 4755

Improved Protocol Detection

The precision of CapLoader's built-in port independent protocol identification has been improved and several additional protocols can now be detected, including GSocket, Hioles, Mirai, Pulsar RAT, PureRAT, SVCStealer and XenoRAT.

PolarProxy 2.0 Released

Erik Hjelmvik — Mon, 18 May 2026 07:01:00 GMT

A new major release of PolarProxy is out with a self-contained single-file binary, expanded platform support (musl/ARM), and improved container and service plumbing.

PolarProxy is a transparent TLS/SSL inspection proxy built for incident responders, malware analysts and security researchers. It decrypts and re‑encrypts TLS traffic and writes decrypted sessions to PCAP for analysis in Wireshark or an IDS.

What's new

Packaged as a self-contained, single-file binary for easier installation and management.
Improved HTTP proxy server: support for unencrypted HTTP traffic with --nontls allow
Upgraded runtime: migrated from .NET 8 to .NET 10.
More supported platforms: Linux musl (Alpine) builds for ARM and ARM64 architectures added.
Simplified container deployment: Dockerfile and docker-compose.yml included with all musl/Alpine releases.
Service installer for Linux: systemd unit (polarproxy.service) and install script included in non-musl Linux releases.
New runtime flags:
- --tlstimeout <seconds> — sets a TLS handshake/authentication timeout.
- --cutoff <bytes> — limits PCAP output to the specified number of bytes per flow.

Why this release matters

Self-contained single binary simplifies deployment and maintenance. This is a breaking change, at least for container/pod deployments, so make sure to validate your deployment before rolling out the new 2.0 release to production.
The .NET 10 upgrade brings improved runtime performance and security updates.
Better container support with musl/Alpine build for ARM and ARM64 in addition to existing x64 builds, and simplified container deployments with included config files.
The new timeout for TLS handshakes improves error handling of connections to broken TLS middleboxes and extremely slow web servers.
The flow cutoff CLI option enables users to prevent large downloads from filling up disk volumes. This setting also limits the per-flow size of decrypted traffic that is made available through PCAP-over-IP.

Quick start for Linux (regular user)

Download the appropriate tar archive for your platform (see download links).
Create directory:
mkdir ~/PolarProxy
Change directory:
cd ~/PolarProxy/
Extract the archive:
tar -xzf ~/Downloads/PolarProxy_2.0.0_linux-x64.tar.gz
Create log directory:
sudo mkdir -p /var/log/polarproxy
Change log dir owner:
sudo chown "$USER" /var/log/polarproxy
Start PolarProxy:
./PolarProxy -p 10443,80,443 --socks 1080 --httpconnect 8080 --nontls allow --certhttp 10080 -x /var/log/polarproxy/polarproxy.cer -f /var/log/polarproxy/proxyflows.log --pcapoverip 0.0.0.0:57012 -o /var/log/polarproxy/ -v

Quick start for Linux with systemd

Download the appropriate tar archive for your platform (see download links).
Create and change into a new temp directory:
cd $(mktemp -d)
Extract the archive:
tar -xzf ~/Downloads/PolarProxy_2.0.0_linux-x64.tar.gz
Run install script:
sudo ./install-polarproxy-service.sh
Show service status:
systemctl status polarproxy.service
Show logs:
sudo journalctl -t polarproxy

The install script creates a system user “polarproxy”, a systemd service called “polarproxy.service”, and then starts that service. You are, of course, free to modify the installation script and polarproxy.service file if you want a different configuration.

Quick start for Alpine Docker

Download the appropriate Linux musl archive for your platform (see download links).
Create and change into a new temp directory:
cd $(mktemp -d)
Extract:
tar -xzf ~/Downloads/PolarProxy_2.0.0_linux-musl-x64.tar.gz
Deploy to docker:
sudo docker compose up -d --build
Show container status:
sudo docker ps --filter "name=polarproxy"
Show logs:
sudo docker logs polarproxy

The docker-compose.yml will create a container named “polarproxy” with a non-root user called “polarproxy” without a password.

Listening services in quick start examples

All three quick start deployments above expose the following TCP ports:

10443 — Transparent TLS proxy
1080 — SOCKS server
8080 — HTTP Proxy server
10080 — Web server hosting the root CA certificate
57012 — PCAP-over-IP server providing decrypted traffic

A port forwarding (DNAT) firewall rule must be configured, which redirects TCP 443 traffic to the transparent TLS proxy, in order to run PolarProxy as a transparent TLS proxy that intercepts outgoing TLS traffic. See the Routing Option alternatives on the official PolarProxy page for more details.

Decrypted traffic from all proxy services is accessible through the PCAP-over-IP service on TCP port 57012. They are also written to PCAP files in /var/log/polarproxy/.

Test your deployment

Download PolarProxy’s root CA certificate:

		curl -L -o /tmp/polarproxy.cer http://localhost:10080
	  

Convert to PEM format:

		openssl x509 -inform DER -in /tmp/polarproxy.cer -out /tmp/pp.crt
	  

Monitor decrypted traffic via PCAP-over-IP in one terminal/shell:

		nc 127.0.0.1 57012 | tcpdump -Anr -
	  

Test transparent proxy in another terminal/shell:

  	  curl --cacert /tmp/pp.crt --connect-to www.netresec.com:443:127.0.0.1:10443 https://www.netresec.com/
	  

Test SOCKS proxy:

		curl --cacert /tmp/pp.crt --socks5 127.0.0.1 https://www.netresec.com/
	  

Test HTTP proxy:

		curl --cacert /tmp/pp.crt --proxy 127.0.0.1:8080 https://www.netresec.com/
	  

Downloads and docs

See the PolarProxy product page for downloads, full command-line options, sample configurations etc.

Feel free to share feedback or report bugs about PolarProxy.

Remcos Alerts from FlowCarp in EveBox

Erik Hjelmvik — Fri, 08 May 2026 11:49:00 GMT

There is a wonderful little web-based alert and event front-end called EveBox, which renders Eve JSON formatted data to a web UI. This blog post demonstrates how EveBox can be used to show alert and flow information that FlowCarp has extracted from a Remcos malware infection.

Remcos RAT

The starting point of my analysis will be a PCAP file with network traffic from a Remcos RAT infection, which Brad Duncan has published on Malware-Traffic-Analysis.net. The password scheme for the zip file containing the PCAP can be found here, in case you'd like to follow along and perform the same analysis steps yourself. All commands and examples in this blog post can be run in both Linux and Windows.

JSON formatted alerts and flow data can be extracted from the PCAP file with FlowCarp like this:

		flowcarp --input 2026-03-12-SmartApeSG-ClickFix-activity-for-Remcos-RAT.pcap --format EveJson --output -
	  

But the free community license of FlowCarp doesn't include a protocol model for Remcos, which is why this command will generate flow events but no alerts about detected Remcos malware traffic. I will therefore submit the pcap file to the free FlowCarp demo server instead, which has a commercial license that can identify over 600 protocols. No registration or API key is required to use this demo server (as long as users behave − please behave).

		curl --data-binary @2026-03-12-SmartApeSG-ClickFix-activity-for-Remcos-RAT.pcap -o remcos-eve.json https://demo.flowcarp.com
	  

The downloaded remcos-eve.json file uses the Suricata Eve JSON format, so jq queries typically used to process Suricata eve.json log files can be used to parse and filter the JSON output from FlowCarp as well.

jq -c 'select(.event_type=="alert")|[.dest_ip, .dest_port, .proto, .alert.signature]' < remcos-eve.json
["193.178.170.155",443,"TCP","MALWARE protocol detected: TLS, Remcos"]

This FlowCarp alert indicates that the PCAP file contains TLS-encrypted Remcos traffic, which means that FlowCarp has performed a so-called sub-protocol match to detect the protocol inside of TLS without decrypting the TLS layer. A quick way to verify if this traffic is Remcos in TLS is to check the JA3 hash or JA4 fingerprint of the client's TLS handshake.

tshark -r 2026-03-12-SmartApeSG-ClickFix-activity-for-Remcos-RAT.pcap -Y "ip.dst == 193.178.170.155 and tls.handshake" -T fields -e tls.handshake.ja3 -e tls.handshake.ja4
a85be79f7b569f1df5e6087b69deb493 t13i010400_0f2cb44170f4_5c4c70b73fa0

This nicely matches what we expect to see from TLS encrypted Remcos traffic. For reference these are the JA3 and JA4 fingerprints typically associated with Remcos:

JA3: a85be79f7b569f1df5e6087b69deb493
JA4: t13i010400_0f2cb44170f4_5c4c70b73fa0
JA4: t13i010400_0f2cb44170f4_1b583af8cc09

There is always a risk of false positives associated with JA3 or JA4 fingerprints, so a rule of thumb is to not blindly trust JA3/JA4 based alerts without having additional indicators of compromise. FlowCarp performs a much deeper identification of sub-TLS protocols than JA3/JA4, but there's still a false positive risk associated with detection of encrypted malware traffic — so make sure to verify alerts like this with other types of data sources, such as event logs from the infected device or OSINT information about the suspected C2 server. For this alert we can see that @DonPasci has reported 193.178.170.155:443 to ThreatFox as being a Remcos C2 server.

EveBox

EveBox is a web-based front-end for Suricata "EVE" alerts and events, created by Jason Ish. The EveBox source code lives on GitHub and pre-built EveBox binaries for Linux and Windows are available on evebox.org.

This evebox command will fire up a browser and render information about the flows and alerts in the Eve JSON file from FlowCarp:

		evebox oneshot remcos-eve.json
	  

The flows and alerts are displayed in reverse order, so that the most recent events are on top. The Remcos alert stands out in red and immediately catches your eye. Let's change Event Type from "All" to "Alert" just to make sure there are no other alerts.

Looks like this was the only alert in this JSON file.

EveBox is built for Suricata, but it's really nice that it can be used out-of-the-box to read FlowCarp's JSON logs as well. For reference, let's also see what it looks like when we run the same PCAP file through Suricata and import eve.json into EveBox.

I'm happy to see that Suricata also alerts on the same TCP session as FlowCarp. This alert was raised by the Emerging Threats signature ID 2036594, which triggers whenever the JA3 hash of a TLS handshake is a85be79f7b569f1df5e6087b69deb493.

FlowCarp Identifies Protocols

Erik Hjelmvik — Mon, 04 May 2026 14:53:00 GMT

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

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

FlowCarp Demo Service

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

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

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

		curl --data-binary @260504-hkcr6adt5x-behavioral1.pcapng -o mirai-eve.json https://demo.flowcarp.com
	  

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

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

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

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

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

Running FlowCarp Locally

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

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

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

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

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

Real-Time Protocol Identification

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

		tcpdump -U -w - | flowcarp --input - --realtime --preview --output -
	  

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

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

		./pcap-broker -listen 127.0.0.1:57012 -cmd "sudo tcpdump -i eth0 -U -w -"
	  

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

		./flowcarp --input tcpconnect:127.0.0.1:57012 --realtime --preview --output -
	  

I hope you'll find FlowCarp useful!

CISA mixup of IOC domains

Erik Hjelmvik — Thu, 26 Feb 2026 09:35:00 GMT

Google's Threat Intelligence Group (GTIG) and Mandiant's recent Disrupting the GRIDTIDE Global Cyber Espionage Campaign report is great and it has lots of good Indicators of Compromise (IOC). Many of these IOCs had already been shared by CISA last year as part of their Alert AA25-141A titled "Russian GRU Targeting Western Logistics Entities and Technology Companies". The IOC overlap between these two reports is surprisingly big, provided that the GTIG report covers a Chinese espionage group while the CISA report covers the Russian GRU unit 26165 (aka APT28 / Fancy Bear).

But some of the domain names in CISA's report from last year are strange. For example, the domain name "accesscan[.]org" doesn't seem to ever have been registered. The GTIG report, however, contains the very similar domain "accesscam[.]org". This accesscam domain is registered to the dynamic DNS provider Dynu Systems, whose services are often abused by malicious actors. Is it possible that there are typos in the IOCs published by CISA? I think so.

Another odd domain in CISA's AA25-141A is "glize[.]com", which I suspect is a typo from either "giize[.]com" or "gleeze[.]com". The two latter domains are listed in the GTIG report and both of them also belong to the dynamic DNS provider Dynu Systems. The domain listed in CISA's alert, on the other hand, appears to be a legit website (archived page from 2024) from the marketing company Glize in Malta.

Glize's website seems to have disappeared sometime in 2025.

Update 2026-02-27

The IOC list published by CISA originates from cybersecurity advisory 157019-25 / PP-25-2107, which was created as a joint effort by the following 21 organizations:

United States National Security Agency (NSA)
United States Federal Bureau of Investigation (FBI)
United Kingdom National Cyber Security Centre (NCSC-UK)
Germany Federal Intelligence Service (BND)
Germany Federal Office for Information Security (BSI)
Germany Federal Office for the Protection of the Constitution (BfV)
Czech Republic Military Intelligence (VZ)
Czech Republic National Cyber and Information Security Agency (NÚKIB)
Czech Republic Security Information Service (BIS)
Poland Internal Security Agency (ABW)
Poland Military Counterintelligence Service (SKW)
United States Cybersecurity and Infrastructure Security Agency (CISA)
United States Department of Defense Cyber Crime Center (DC3)
United States Cyber Command (USCYBERCOM)
Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
Canadian Centre for Cyber Security (CCCS)
Danish Defence Intelligence Service (DDIS)
Estonian Foreign Intelligence Service (EFIS)
Estonian National Cyber Security Centre (NCSC-EE)
French Cybersecurity Agency (ANSSI)
Netherlands Defence Intelligence and Security Service (MIVD)

It is therefore unclear which organization(s) reported the erroneous IOCs as well as who were responsible for verifying them before publication.

In summary, these are the incorrect and correct IOC domains:

Incorrect IOC: *.accesscan[.]org (not registered)
Correct IOC: *.accesscam[.]org (registered by Dynu Systems)
Incorrect IOC: *.glize[.]com (legitimate website, now closed)
Correct IOC: *.giize[.]com (registered by Dynu Systems)
Correct IOC: *.gleeze[.]com (registered by Dynu Systems)

njRAT runs MassLogger

Erik Hjelmvik — Mon, 02 Feb 2026 19:39:00 GMT

njRAT is a remote access trojan that has been around for more than 10 years and still remains one of the most popular RATs among criminal threat actors. This blog post demonstrates how NetworkMiner Professional can be used to decode the njRAT C2 traffic to extract artifacts like screenshots, commands and transferred files.

A PCAP file with njRAT traffic was published on malware-traffic-analysis.net last week. After loading this PCAP file, NetworkMiner Professional reveals that the attacker downloaded full resolution screenshots of the victim’s screen.

Image: Overview of screenshots sent to C2 server

Image: Screenshot extracted from njRAT traffic by NetworkMiner

The file “New Purchase Order and Specifications.exe” in this screenshot is the njRAT binary that was used to infect the PC.

A list of njRAT commands sent from the C2 server to the victim can be viewed on NetworkMiner’s Parameters tab by filtering for ”njRAT server command”.

The following njRAT commands are present here:

CAP = take screenshot
inv = invoke (run) a plugin (dll)
rn = run a tool (executable)

Additional njRAT commands can be found in our writeup for the Decoding njRAT traffic with NetworkMiner video, which we published last year.

njRAT File Transfers

The “inv” and “rn” commands both transfer and execute additional code on the victim machine. The “inv” command typically transfers a DLL file that is used as a plugin, while the “rn” commands sends an executable file. These DLL and EXE files are transferred in gzip compressed format, which is why NetworkMiner extracts them as .gz files.

Image: Gzip compressed files extracted from njRAT traffic

This oneliner command lists the internal/original file names and corresponding MD5 hashes of the gzip compressed executables sent to the victim PC:

for f in njRAT-rn*.gz; do echo $f; gunzip -c $f | exiftool - | grep Original; gunzip -c $f | md5sum; done
njRAT-rn-260129030403.gz
Original File Name : Stub.exe
ca819e936f6b913e2b80e9e4766b8e79 -
njRAT-rn-260129030433.gz
Original File Name : Stub.exe
e422a4ce321be1ed989008d74ddb6351 -
njRAT-rn-260129030451.gz
Original File Name : CloudServices.exe
fcbb7c0c68afa04139caa55efe580ff5 -
njRAT-rn-260129031041.gz
Original File Name : Stub.exe
0ae3798c16075a9042c5dbb18bd10a5c -

The MD5 hashes of the files inside the gzip compressed streams can also be seen on the Parameters tab in NetworkMiner.

MassLogger

The “CloudServices.exe” executable is a known credential stealer called MassLogger. This particular MassLogger sample is hard coded to exfiltrate data in an email to kingsnakeresult@mcnzxz[.]com. The email is sent through the SMTP server cphost14.qhoster[.]net. See the execution of this sample on Triage for additional details regarding the MassLogger payload in CloudServices.exe.

IOC List

njRAT (splitter = "|Ghost|")

58f1a46dba84d31257f1e0f8c92c59ec = njRAT sample
104.248.130.195:7492 = njRAT C2 server
burhanalassad.duckdns[.]org:7492 = njRAT C2 server
801a5d1e272399ca14ff7d6da60315ef = sc2.dll
ca819e936f6b913e2b80e9e4766b8e79 = Stub.exe
e422a4ce321be1ed989008d74ddb6351 = Stub.exe
fcbb7c0c68afa04139caa55efe580ff5 = CloudServices.exe
0ae3798c16075a9042c5dbb18bd10a5c = Stub.exe

MassLogger

fcbb7c0c68afa04139caa55efe580ff5
kingsnakeresult@mcnzxz[.]com
cphost14.qhoster.net:587
78.110.166.82:587

Decoding malware C2 with CyberChef

Erik Hjelmvik — Tue, 20 Jan 2026 12:10:00 GMT

This video tutorial demonstrates how malware XOR encrypted and obfuscated C2 traffic can be decoded with CyberChef.

The analyzed PCAP files can be downloaded from malware-traffic-analysis.net.

CyberChef recipe to decode the reverse shell traffic to 103.27.157.146:4444:

From_Hex('Auto')
XOR({'option':'Hex','string':'62'},'Standard',false)
Find_/_Replace({'option':'Regex','string':'\\r'},'',true,false,true,false)
From_HTML_Entity()

Decoded data from first "key007" reverse shell session to 103.27.157.146:4444:

				key007

				Authentication successful

				furtheringthemagic.com

				net group "domain computers" /domain

				The request will be processed at a domain controller for domain furtheringthemagic.com.

				Group name     Domain Computers

				Comment        All workstations and servers joined to the domain

				Members

				-------​--------​-------​--------​-------​---------​-------​----------​--------​--------

				DESKTOP-G71S4PF$

				The command completed successfully.

CyberChef recipe to decode obfuscated PowerShell payload from malicious finger service on 64.190.113.206:79:

Fork(',','',false)
Pad_lines('End',5,',6044')
Subtract('Comma')
From_Charcode('Space',10)

Update 2026-01-21

Our classification of the final payload has been updated from AsyncRAT to GhostWeaver thanks to feedback from Don Pasci. Don referenced a writeup by Recorded Future's Insikt Group, called Uncovering MintsLoader With Recorded Future Malware Intelligence Hunting, which states the following:

GhostWeaver has periodically been misclassified as AsyncRAT. [...] GhostWeaver and AsyncRAT share certain characteristics within their self-signed X.509 certificates, such as identical expiration dates and serial number lengths; however, these similarities may simply reflect common certificate-generation methods rather than meaningful operational overlap.

We also believe that some of the PowerShell related traffic was caused by MintsLoader.

IOC List

103.27.157.146:4444 (unknown "key007" reverse shell)
64.190.113.206:79 (finger)
checkifhuman[.]top (finger)
ey267te[.]top (MintsLoader)
64.52.80.153:80 (MintsLoader)
173.232.146.62:25658 (~~AsyncRAT~~ GhostWeaver)
08kcbghk807qtl9[.]fun:25658 (~~AsyncRAT~~ GhostWeaver)

Network Forensics Training

Check out our network forensic trainings if you want to learn more about decoding malware C2 traffic. I'm teaching a live online Network Forensics for Incident Response class on February 23-26.

Latrodectus BackConnect

Erik Hjelmvik — Wed, 10 Dec 2025 13:00:00 GMT

This blog post demonstrates how artifacts, such as reverse shell commands and VNC session screenshots, can be extracted from Latrodectus BackConnect C2 traffic with NetworkMiner.

I recently learned that the great folks from The DFIR Report have done a writeup covering the Latrodectus backdoor. Their report is titled From a Single Click: How Lunar Spider Enabled a Near Two-Month Intrusion.

I found it particularly interesting that the threat actors used Latrodectus to drop a BackConnect RAT to the victim PC. I have verified that this RAT’s Command and Control (C2) traffic is using the exact same BackConnect C2 protocol as what would previously be seen in IcedID and QakBot infections.

This BackConnect RAT supports features such as:

Reverse VNC (Keyhole)
Reverse SOCKS
Reverse shell (cmd.exe or powershell)
File manager

NetworkMiner

I immediately recognized the BackConnect protocol because I spent many hours reverse engineering that protocol back in 2022. I later spent even more time building a parser for it in 2023. This BackConnect parser was eventually published as part of the NetworkMiner 2.8.1 release.

I was happy to see that NetworkMiner could parse the BackConnect traffic in The DFIR Report’s Latrodectus case (#TB28761).

The only caveat was that I had to use NetworkMiner Professional, because it has a built-in protocol detection feature that detects the BackConnect traffic and applies the correct parser. That feature isn’t included in the free version of NetworkMiner, which is why it doesn’t know what to do with this strange looking TCP traffic to port 443.

Below are some screenshots extracted with NetworkMiner Professional from the BackConnect reverse VNC traffic.

Image: Keyhole reverse VNC session

Image: Attacker fails to inspect ad_users.txt

Image: Attacker launches additional malware with rundll

The reverse VNC activity spanned a period of over two weeks, which is very impressive for this type of intrusion data set. The threat actors used the BackConnect reverse VNC service to access the machine several times during this period, for example to steal credentials and install additional malware.

A histogram of interactive BackConnect events, including reverse shell, VNC and file manager sessions, show that the majority of the work was carried out around 12pm UTC.

Keylog of the Attacker

Not only does the BackConnect network traffic from the intrusion allow us to extract screenshots from the VNC traffic. NetworkMiner also extracts the attacker’s hands-on keyboard activity.

The keylog shows that the attacker accidentally typed “cd //” instead of “cd ..” at one point. Here’s the screenshot that NetworkMiner extracted from the reverse VNC traffic after the attacker had corrected the typo.

This typo might seem a bit odd, but if you compare the US keyboard layout with the Russian Cyrillic one, then you’ll see that the dot key on the Cyrillic keyboard is at the same place as slash on the US keyboard.

Image: Russian Windows keyboard layout from Wikipedia

This reminds me of another BackConnect infection, captured by Brad Duncan, which he named IcedID (BokBot) infection with Keyhole VNC and Cobalt Strike. Here’s a screenshot that NetworkMiner extracted from the PCAP file shared by Brad:

The attacker can be seen typing “фьфящт” into the browser’s address bar in that VNC session. Фьфящт doesn’t mean anything in Russian, but the individual positions on the Russian keyboard corresponds to “amazon” on a standard Latin keyboard layout.

Reverse Shell

NetworkMiner also extracts commands from BackConnect reverse shell sessions.

This screenshot shows that the attacker sent the following command to the reverse shell:

				rundll32 C:\ProgramData\sys.dll,StartUp471
			

This command launched a Cobalt Strike implant that connected to avtechupdate[.]com. Analysis of the Cobalt Strike C2 traffic is not in the scope for this blog post though, but the original writeup for this lab contains additional details on the Cobalt Strike infection.

The attacker later issued another rundll command to launch another red-team/penetration testing tool, namely Brute Ratel C4.

				rundll32 wscadminui.dll, wsca
			

This Brute Ratel backdoor connected to C2 servers on erbolsan[.]com and a few other domains (see IOC list). The DFIR Report’s writeup contains additional information about that payload as well.

About The DFIR Report

The DFIR Report provide analysis of cyber intrusions, detailing the tactics, techniques, and procedures used by attackers. They share insights into various attacks, from initial access to execution, and offer private threat briefs and reports for organizations.

A lab containing Elastic or Splunk data from this infection can be purchased from The DFIR Report’s store. Look for the lab titled “The Lunar Tangled Malware Web - Public Case #28761”. The DFIR Report also sell access to a threat intelligence service, which contains even more detailed lab data from this and other malware infections.

Netresec is not affiliated with The DFIR Report.

IOC List

The analyzed infection is from 2024, so these indicators are in no way fresh. They are included here for research purposes and to facilitate retro hunting.

BackConnect C2 ip:port

185.93.221.12:443
193.168.143.196:443

Latrodectus domains

grasmetral[.]com
illoskanawer[.]com
jarkaairbo[.]com
scupolasta[.]store
workspacin[.]cloud

Cobalt Strike C2 URI

hxxps://resources.avtechupdate[.]com/samlss/vm.ico

Brute Ratel C4 domains

dauled[.]com
erbolsan[.]com
kasym500[.]com
kasymdev[.]com
samderat200[.]com

Network Forensics Training

Check out our network forensics training if you want to learn more about analyzing malware traffic in PCAP files.

I will teach an online class for incident responders and blue teams on February 23-26. That class allows a maximum of 15 attendees in order to provide a good environment for taking questions. So don’t miss out on this chance to get your hands dirty with some packet analysis together with me!