Remcos Alerts from FlowCarp in EveBox

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:

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

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:

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.

Posted by Erik Hjelmvik on Friday, 08 May 2026 11:49:00 (UTC/GMT)

Tags: #FlowCarp​ #Remcos​ #a85be79f7b569f1df5e6087b69deb493​ #t13i010400_0f2cb44170f4_5c4c70b73fa0​ #t13i010400_0f2cb44170f4_1b583af8cc09​

FlowCarp Identifies Protocols

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

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

FlowCarp Demo Service

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

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

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

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

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

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

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

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

Running FlowCarp Locally

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

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

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

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

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

Real-Time Protocol Identification

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

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

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

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

I hope you'll find FlowCarp useful!

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

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

CISA mixup of IOC domains

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)

Posted by Erik Hjelmvik on Thursday, 26 February 2026 09:35:00 (UTC/GMT)

Tags: #IOC​

njRAT runs MassLogger

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

Posted by Erik Hjelmvik on Monday, 02 February 2026 19:39:00 (UTC/GMT)

Tags: #njRAT​ #NetworkMiner Professional​ #malware-traffic-analysis.net​

Decoding malware C2 with CyberChef

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:

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

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

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.

Posted by Erik Hjelmvik on Tuesday, 20 January 2026 12:10:00 (UTC/GMT)

Tags: #Netresec​ #CyberChef​ #XOR​ #PCAP​ #CapLoader​ #PowerShell​ #Video​ #videotutorial​