PureLogs, PureRAT and misleading 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 IDS signatures labeled as “zgRAT” 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

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

• 404f0d36fcbe5c4643e821403a4827eb 204.44.93.88:8449
• 7e49bac468548a0e83133f0d5b02544b 5.101.84.75:4242
• 3c9852c53cb45221886b34ed6bc7d674 46.151.182.159:776

PureRAT

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

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

• 323fed78fc8aaa86c3d35aa85313645d 85.239.149.178:56001
• b4400998cf293b0767455fb37526b18e 196.251.107.6:56001
• 010301d23beacee631006245ed09a2f7 45.192.211.59:56001

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:

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

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

Ping32 RMM and ValleyRAT

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:

• https://tria.ge/260325-z4xp4sew7y
• https://tria.ge/260325-z763ysex41

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.

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.

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:

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.

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

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.

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​

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​