Stop Feeding the SOC Garbage

Security operations teams are handling increasing volumes of network events and security alerts. Whether those alerts are reviewed by human analysts, processed by AI, or handled through a combination of both, the result depends on the quality of the underlying detections.

No SOC can investigate an intrusion that never generated an alert. And if the incoming alerts are incomplete, noisy, or biased toward known attack patterns, the result is inefficient investigations and missed malicious activity.

Simply spending more on AI tokens will not solve this problem. AI can prioritize, correlate, and summarize the alerts it receives, but it cannot recover activity that was never detected or reliably compensate for systematically noisy inputs. Detection quality still depends on input quality. Or in other words, Garbage-In-Garbage-Out (GIGO) still applies.

False positives and false negatives

False positives are a constant pain for many SOCs. They waste analyst time, cause alert fatigue, and may lead teams to disable or ignore useful detections. So-called benign alerts are almost just as bad. This image shared by @cR0w humorously captures the analyst experience.

While false positives waste time, false negatives may waste nothing at all. That's an even bigger problem!

A different way to identify protocols

Traditional intrusion detection systems (IDS) are valuable, but they depend on static signatures and protocol-specific rules. Creating a reliable signature can require expertise and large PCAP datasets to test for false positives. Some protocols are especially difficult to detect with such techniques. They may be proprietary, undocumented, encrypted, obfuscated, or designed to resemble benign traffic.

FlowCarp takes a different approach. It identifies application-layer protocols by analyzing statistical characteristics of network traffic and comparing them with models of known protocols. This does not require a formal protocol specification. A protocol model can be created from example traffic, including traffic from a protocol that is difficult to express as a conventional IDS signature.

FlowCarp can identify both legitimate and malicious protocols, including protocols used for malware command-and-control (C2) traffic. It can also generate alerts and integrate with existing monitoring workflows.

A complementary detection method

FlowCarp is not intended to replace a traditional IDS. One of its key features is that it provides another view of network activity.

A traditional IDS signature may stop matching when an attacker changes an indicator. A parser may not support an undocumented protocol. A port-based rule may fail when traffic moves to an unexpected port. Because it identifies protocols based on statistical traffic characteristics, FlowCarp can provide an alternative when static signatures and protocol parsers are unavailable, insufficient, or unreliable.

The reverse can also be true: a conventional signature may be the better detector in a particular situation. Using different detection methods together can make monitoring more resilient.

This additional perspective is useful in any SOC. These alerts can provide additional investigative leads for analysts and additional evidence for automated triage systems. In both cases, the benefit depends on receiving alerts that are relevant and accurate.

Better detection benefits every SOC

The goal should not simply be to maximize the number of alerts a SOC can process. It should be to produce alerts that cover meaningful activity without overwhelming the people and systems responsible for investigating them.

Whether a SOC relies on human analysts, AI, or a combination of both, the foundation is the same: high-quality inputs lead to better detections. Before asking a SOC to handle higher alert volumes, it is worth asking whether those alerts provide an accurate view of the network and what might still be missing.

Posted by Erik Hjelmvik on Tuesday, 06 October 2026 06:30:00 (UTC/GMT)

Tags: #FlowCarp​

Unmasking Malware Families

Identifying malware families is hard. Malware samples are often packed, strings encrypted and configurations may only appear after several stages of execution. Even experienced reverse engineers can get the malware family wrong and commercial sandboxes do not always produce correct classifications.

Malware C2 network traffic can provide another way to approach the problem. C2 traffic often contains enough information to identify the application-layer protocol and the malware family using it.

FlowCarp

FlowCarp identifies application-layer protocols in network traffic by analyzing observable characteristics of the traffic. It computes statistical measurements from a capture and compares them with models for known protocols.

Unlike traditional IDS signatures, FlowCarp protocol models do not describe protocols using specific strings or byte sequences. To add detection for a new protocol to FlowCarp, you provide example traffic that is used to build a statistical model.

This makes it possible to identify proprietary protocols, including C2 protocols used by malware.

FlowCarp can detect hundreds of malware protocols, so I often run it against PCAP files captured during sandbox executions. It often correctly identifies which C2 protocol a sample is using and points out the IP and port number of the C2 server.

Reporting Misclassifications

I occasionally contact cybersecurity companies or malware researchers when FlowCarp indicates that there's a mismatch between a sample’s reported family and its C2 protocol.

Some decide not to update their publications, while others revisit their findings after being informed of the misclassification. Companies often don’t provide public credit for such feedback. Instead, they typically revise their publication with updated findings and thank the broader research community, with wording like: "We extend our sincere gratitude to the researchers who provided critical feedback" or "Thank you to the community members who prompted us to take another look".

Brad Duncan is a notable exception. His malware-traffic-analysis.net writeups regularly give credit after receiving useful corrections or additional analysis.

Statistical Classification and Signatures

FlowCarp takes a different approach from traditional signature-based network detection.

A typical IDS signature might look for a known byte sequence, string, header, protocol field or other recognizable pattern. This works well when the pattern is stable and distinctive. It is also easy to understand: the rule matched, so the alert was generated.

FlowCarp's statistical classification looks at several traffic characteristics, such as:

• Packet sizes
• Timing between packets
• Message length distributions
• Request and response behavior
• Protocol structure

This approach can be useful when recognizable strings or byte sequences are unavailable. Encryption may hide the contents of a message, but it does not necessarily hide every recognizable property of the network protocol. FlowCarp may still be able to distinguish traffic based on its structure and behavior.

Statistical protocol detection doesn't require hand-built rules or deep protocol knowledge. Collect some example traffic, build a model, and FlowCarp automatically identifies the distinguishing characteristics.

Reducing Alert Overlap

A single network connection might generate IDS alerts associated with multiple malware families. This can happen when a generic signature matches traffic from several different families or when multiple signatures happen to match the same traffic. An analyst may therefore receive several possible family labels for one connection.

FlowCarp takes a simpler approach: it assigns a single protocol or malware label to each flow.

Traditional IDS tools are still great for spotting malicious traffic and identifying infected hosts and C2 servers. FlowCarp is not intended to replace those tools. It works best as an additional classification layer. It can help identify protocols that do not have useful signatures, provide a more specific label for some traffic and simplify the process of adding detection for new protocols.

Adding a New Protocol

Suppose you have identified a new C2 protocol used by a malware you call MalwareXYZ.

You collect several C2 sessions from sandbox executions and save them in a capture file called xyz.pcap. If possible, use sessions from more than one execution or sample rather than relying on a single session.

You can then use those examples to build a custom protocol model:

The model is given the label MalwareXYZ, marked as MALICIOUS, and saved as malwarexyz.fcp. Once the model has been created, you can use it to classify traffic in another PCAP:

This lets you test the model against captures from other samples or sandbox executions.

The quality of the result depends heavily on the examples used to build the model. If the training data contains only one narrow variation of the protocol, the model may not generalize well.

Trying the Demo Server

There is a free FlowCarp demo server at demo.flowcarp.com. It runs a FlowCarp web service with a commercial license and can identify more than 600 protocols.

The demo server provides a quick way to evaluate FlowCarp's protocol identification feature before building a local workflow. To submit a PCAP, use:

The server returns a JSON response containing detected flows, protocols, and alerts. For example, the output can be passed to tools such as jq or processed by an existing incident response pipeline.

C2 Traffic as Additional Evidence

FlowCarp does not replace reverse engineering, IDS signatures or analyst judgment. Its value is that it gives analysts another way to examine a sample. Statistical protocol classification can be a practical addition to malware analysis and incident response workflows. When a sample’s code and configuration are difficult to analyze, its C2 traffic may still reveal the underlying malware family.

Posted by Erik Hjelmvik on Monday, 21 September 2026 10:00:00 (UTC/GMT)

Tags: #FlowCarp​ #IDS​

PolarProxy 2.0.2 Released

A few more handy features have been added to PolarProxy, our TLS inspection proxy. PolarProxy can now tunnel outgoing connections through SOCKS proxies and supports environment variables as an alternative to command-line arguments. PolarProxy also ships with a software bill of materials (SBOM), providing greater transparency into its dependencies.

SOCKS Proxy Client

PolarProxy has been able to accept incoming connections over SOCKS since version 0.9. With this release, PolarProxy can also send outgoing connections through another SOCKS proxy server. Both SOCKS4 and SOCKS5 are supported. This feature enables many use cases, including inspecting your own HTTPS requests before sending them through the Tor network.

The following command starts a SOCKS proxy on TCP port 1080 and forwards all traffic to a Tor SOCKS5 proxy listening on TCP port 9050. A copy of the traffic transmitted through the tunnel, including decrypted TLS traffic, is made available through a PCAP-over-IP service on TCP port 57012.

PolarProxy’s SOCKS client can also be used as a protocol converter. For example, incoming HTTP proxy and HAProxy connections can be converted into SOCKS proxy requests with the following command:

Simplified and Flexible Deployments

PolarProxy 2.0.2 enables users to supply configuration settings through environment variables as an alternative to command-line arguments. PolarProxy environment variables use uppercase names with the PP_ prefix. For example, the PP_SOCKS environment variable corresponds to the --socks command-line option.

Environment variables provide a clean separation between an application and its configuration. This is particularly useful when running PolarProxy with systemd, Docker, Podman, Kubernetes, Helm or other orchestration tools. They can simplify deployments and make ongoing configuration changes more flexible.

PolarProxy 2.0.2 also ships with a docker-compose.yml (musl builds only) or a systemd unit file (non-musl Linux builds), depending on which target the downloaded release is built for. These files simplify deployment. A docker container can, for example, be deployed by running:

A systemd service can be deployed with:

More Timeouts

PolarProxy 2.0.2 adds a new type of timeout that allows connections to be closed when the client or server has been idle for a specified period. Closing unused “dead” connections helps maintain a clean state and prevents zombie connections from lingering in PolarProxy or in clients connected through PolarProxy.

PolarProxy can now close connections based on timeouts at the following communication stages:

• TCP handshake: --timeout <seconds>
• TLS handshake: --tlstimeout <seconds>
• Idle client connection: --idletimeoutclient <seconds>
• Idle server connection: --idletimeoutserver <seconds>

The default timeout for TCP and TLS handshakes is 30 seconds, while the idle timeout is disabled by default.

SBOM: Software Bill of Materials

PolarProxy 2.0.2 includes a software bill of materials (SBOM), providing an overview of the components, libraries, and dependencies included in PolarProxy.

The SBOM supports software transparency and helps users assess their software supply chain. The file shipped with PolarProxy uses the SPDX format and is named polarproxy.spdx.json.

PolarProxy's SBOM can be integrated into your security and compliance workflows using standard vulnerability scanning tools. For more info about SBOMs, refer to NIST's Software Supply Chain Security Guidance.

Downloading and Installing PolarProxy

For more information on how to download and deploy PolarProxy in your environment, see the official PolarProxy product page.

Posted by Erik Hjelmvik on Tuesday, 08 September 2026 12:35:00 (UTC/GMT)

Tags: #PolarProxy​ #SOCKS​ #Tor​

OT Networks Still Need Monitoring

CERT Polska recently published a follow-up report detailing the hack of a Polish combined heat and power (CHP) plant in December 2025.

CERT Polska’s report concludes with several important recommendations, including protecting OT systems through network segmentation and monitoring traffic entering and leaving OT networks. It has now been more than 15 years since I first publicly advocated almost exactly these same two recommendations in my blog post Monitor Those Control System Networks.

One might get the impression that nothing has changed during those 15 years, but I can attest that many OT systems now have effective perimeter protection. Operators of critical infrastructure are also beginning to embrace the concept of network security monitoring for OT systems.

Unfortunately, it appears that the hacked CHP plant in Poland did not have sufficient perimeter protection or network security monitoring in place. The apparent lack of monitoring and logging also left CERT Polska with very limited forensic data. As the report states, “Due to the lack of logs, our investigation relied on the development and testing of hypotheses.” Despite these limitations, I am very impressed by the level of technical detail that CERT Polska were able to reconstruct during their investigation of the CHP hack.

Attack Path

As CERT Polska outline in their report, the attackers’ initial access vector was an Internet-facing FortiGate VPN at a wind farm. From the VPN device, they pivoted via a Teltonika cellular 5G router into a WAGO PLC, which ultimately gave them access to the control system network of a CHP plant.

Image: Attack path from the Internet to the CHP network

The lack of perimeter protection, which would otherwise have prevented direct connections between different remote sites, gave the attackers access to the PLCs and other industrial equipment that directly controlled the physical process at the CHP plant.

With that type of access, attackers do not need to exploit a vulnerability. They can simply issue “normal” commands over the OT network to shut down the process at the plant. In this specific case, the attackers performed the following operations, apparently in an attempt to cause maximum disruption:

• Switched multiple Siemens S7 PLCs to STOP mode
• Enabled password protection on Siemens S7 PLCs to prevent operators from switching them back to RUN mode
• Changed the configurations of several industrial serial device servers and network switches, making them inaccessible from the network

Image: Siemens S7-1500 PLC in STOP mode, from CERT Polska’s report

As a result of the attack, a steam turbine and the system used to produce process water in the CHP plant were both shut down on December 29.

Network Security Monitoring

Better perimeter protection might have prevented the initial access path used against the Polish CHP plant. However, it is not always easy for asset owners and operators to identify every boundary around an OT environment or segment it without affecting operations. This is where network security monitoring plays an important role.

OT networks are often well suited to passive monitoring. Most industrial protocols are unencrypted, communication patterns are more deterministic than those in enterprise networks, and traffic volumes are often modest. By monitoring OT network traffic and alerting on suspicious or anomalous behavior and known attack techniques, defenders may be able to detect an intrusion early enough to investigate, contain, and stop it before destructive actions are carried out.

Examples of useful detections include:

• Reconnaissance activity, such as TCP SYN scans
• Attempts to access canary or honeypot systems that normal operations should not touch
• Connections from unexpected systems to ICS-specific ports, such as TCP ports 102, 502, 2404, 5094, 20000, 44818 and 47808
• Potentially dangerous protocol commands, such as putting a PLC into STOP mode, changing its operating mode, downloading a new program, or modifying its configuration outside a scheduled maintenance window
• New communication paths, such as traffic between IP address pairs that have not previously communicated

The Polish incident illustrates the value of detecting reconnaissance activity, not just the final destructive commands. The disruptive actions occurred on December 29, but CERT Polska uncovered malicious activity as early as December 18.

Image: Log from the Teltonika RUTX50 cellular router

This suggests that the attackers had access to the environment more than 10 days before the destructive actions. This period is known as the dwell time: the time between an attacker gaining access to an environment and being detected or taking disruptive action.

Had the intrusion been detected early, this dwell time would have provided multiple opportunities for defenders to contain it before the attackers carried out their disruptive actions.

Long dwell times are common in attacks against OT systems. Attackers may spend weeks or months learning about the environment, identifying important assets, and determining how to disrupt the physical process. In some cases, access to critical infrastructure is established as part of pre-positioning, where a state-sponsored threat actor gains and maintains access to an OT environment without immediately causing disruption, preserving the ability to deliver a destructive payload at a later point. This makes early detection especially important, even when an intrusion does not initially appear to be affecting plant operations.

Captured network traffic, preferably stored as PCAP files, is one of the most valuable sources of evidence when analyzing a suspected attack against an OT system. It can help investigators reconstruct the attacker’s activity, validate alerts, and identify affected systems. If the captured traffic is stored on a system that is not accessible from the OT network, the risk of an attacker tampering with the evidence is reduced.

This is one reason we have been teaching Network Forensics for Industrial Control Systems for more than 10 years. Feel free to reach out if you want to learn more about our network forensics training.

Siemens S7 Advisory

On a related note, the NSA, CISA, FBI, DOE, and EPA published a joint cybersecurity advisory titled Defending Against an Active Threat to Siemens S7 Series PLCs on August 19 (PDF). In the advisory, the authoring agencies called for mitigation measures such as verifying network segmentation and monitoring network traffic to detect and alert on anomalous or malicious activity. These recommendations are very much in line with what CERT Polska stated in their report, as well as with what I have been recommending since 2011.

The question isn't whether we should implement these recommendations, 15+ years of evidence answers that. The question is what it will take to make them happen.

Posted by Erik Hjelmvik on Monday, 31 August 2026 11:50:00 (UTC/GMT)

Tags: #Netresec​ #NSM​ #ICS​ #ASCII-art​

CNCMachineRMS C2 Protocol

This post describes the binary command-and-control (C2) protocol used by CNCMachineRMS, a recently identified remote access trojan (RAT). We cover how the protocol was discovered, how its infrastructure was identified, and how network defenders can detect it.

Background

We have been tracking a previously unknown malware C2 protocol for several months. It first came to our attention back in April through packet captures from two sandbox executions created by Brad Duncan.

The captures showed ClickFix attacks in which a fake CAPTCHA was used to deliver a previously unknown remote access trojan. The RAT communicated with 89.110.110.119 over TCP port 443. Although the traffic used port 443, it was not protected by TLS and did not resemble any previously known C2 protocol.

We later added a detection model for the protocol to FlowCarp. At that point, the protocol was labeled "Unknown_16". Using FlowCarp, we identified additional C2 servers using the same protocol. All of them exposed the C2 service on TCP port 443:

• 85.158.110.78
• 89.110.110.119
• 89.124.79.98
• 144.124.242.171

Brad Duncan’s malware captures were instrumental in identifying this infrastructure. We then used the IP addresses and hashes from Brad’s executions to find additional samples and executions of the same malware family on ANY.RUN, Joe Sandbox, and Triage.

CNCMachineRMS

I only recently read Rodel Mendrez’s excellent writeup CNCMachineRMS: The Undocumented RAT At the End of a BabaDeda Chain. The report confirmed that the malware Rodel had reverse engineered was the same malware we had observed communicating in Brad Duncan’s PCAP files. In particular, the report mentions the IP address 85.158.110.78 and the domain notepadreleased[.]com.

Rodel notes that CNCMachineRMS includes several features typical of RATs, including:

• Interactive shell
• File manager
• Screen capture

The name “CNCMachineRMS” is taken from a hardcoded directory name used by the malware’s loader:

One notable behavior is the malware’s use of DNS over HTTPS (DoH). Rather than sending the C2 domain lookup to the system’s usual DNS resolver, CNCMachineRMS sends the query over HTTPS to an external DoH provider. Rodel also mentioned this in his report:

The payload resolves its C2 domain over DNS over HTTPS, using dns.google, cloudflare-dns.com and dns.quad9.net. Local DNS logs will not show the lookup.

Image: Decrypted DoH query for notepadreleased[.]com from ANY.RUN

Even without extracting crypto keys from memory or using a TLS inspection tool like PolarProxy, you can still see a TLS encrypted connection to a DoH provider such as dns.google. This usually happens just seconds before CNCMachineRMS connects to its C2 server.

Network Detection

FlowCarp uses a statistical model of the CNCMachineRMS binary protocol to detect similar traffic. This made it possible to add support for the CNCMachineRMS C2 protocol by providing FlowCarp with some example C2 sessions.

To our knowledge, no IDS signatures currently exist for this protocol. However, the traffic appears relatively straightforward to identify. Several fields contain consecutive 0x00 or 0xff bytes at fixed offsets, creating a distinctive pattern across the protocol’s messages.

Image: CapLoader flow transcript of CNCMachineRMS traffic

Note: Yellow 0xff fields contain 0x00 in some connections.

You can test a PCAP file for CNCMachineRMS traffic by submitting it to the free FlowCarp demo server:

If the file contains CNCMachineRMS traffic, the response includes a JSON alert similar to the following:

IOC List

Posted by Erik Hjelmvik on Friday, 21 August 2026 14:45:00 (UTC/GMT)

Tags: #FlowCarp​ #malware-traffic-analysis.net​ #ANY.RUN​ #DoH​

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​

Maximizing IOC Impact

I’ve been thinking about threat intelligence lately. Specifically: indicators of compromise (IOC), how and where to share them to cause maximum pain to adversaries and help as many organizations as possible protect themselves.

I regularly analyze malware traffic from sandboxes such as ANY.RUN, Triage, JoeSandbox and Hybrid Analysis. Pulling fresh PCAPs is an easy way to find malware command-and-control (C2) traffic to previously unknown C2 servers. This method can even reveal new and unreported C2 protocols. I often use CapLoader and NetworkMiner to extract network IOCs, such as:

• Domain names
• IP:port
• URIs
• JA3 / JA3S hashes
• JA4 fingerprints
• X.509 certificate thumbprints
• packet pattern/signature

These indicators can be found in the lower sections of David J. Bianco’s pyramid of pain. But that doesn’t mean they’re not worth sharing — they’re easy to detect, have low false-positive rates, and are very actionable. Their main drawback is short lifetime, so rapid and wide IOC distribution matters.

Image: ASCII pyramid from Optimizing IOC Retention Time

False positives are a real concern, so manual verification of an IOC is required before sharing. Many IOCs are already reported to threat-intel sharing platforms, like ThreatFox, OTX or one of the many MISP instances out there, but I frequently find ones that aren’t. When I discover an IOC, I typically consider these options:

• Report directly to the hosting provider, registrar or network owner.
• Share with a national or sector CERT.
• Share with an ISAC.
• Publish to threat-sharing platforms (ThreatFox/URLhaus/OTX/MISP/AbuseIPDB/etc).
• Publish in a blog post or on social media.

I generally pick outlets case-by-case. Sometimes by convenience, sometimes by where I expect to achieve the greatest impact. Is there a single best destination? Often not, it depends.

Sending an IOC to every channel is comprehensive, but time-consuming. Ideally, a verified IOC drop point that automatically propagates to all the right places would be fantastic! But as far as I know, no such service exists.

I mostly look at malware that hit many victims, which is why it makes sense to prioritize fast, broad distribution (free threat-intel services and blog/social posts). But I have also investigated APT attacks and state-sponsored campaigns, such as Man-on-the-Side attacks, SSL MITM attacks in China as well as DNS traffic from Cozy Bear’s SolarWinds hack. The right place to share IOCs for APT attacks is often different than for mainstream malware. For targeted or sensitive operations, I recommend reaching out to victims, CERTs or a trusted intermediary.

Factors affecting the choice of IOC sharing method:

• Scope and scale of impact: Mass-distribution malware should be blocked widely. Notify specific victims or CERTs on targeted attacks.
• Lifetime and volatility: Short-lived IOCs (IPs, domains) benefit from fast, broad distribution. Longer-lived indicators are better shared in reports or blog posts that provide more depth and context.
• False-positive risk: Prefer channels that support easy updates/removals and allow others to validate or comment.
• Remediation: If a takedown or abuse report is appropriate, contact providers or registrars directly.
• Victimology: Choose platforms aligned with who needs to act. ISACs/CERTs for sectors, targeted notifications for known victims, open feeds for broad coverage.

Many companies and organizations engage in mutual sharing in closed trust groups, expecting that by sharing with others, they will return the favor. This creates a "win-win" situation for the trust group members, while the wider community misses out. As someone who doesn't require IOCs, I find that this approach can limit my reach. I prefer to get information out to as many people as possible, as quickly as possible, with minimum effort. I’ve also noticed a growing commercialization of threat intelligence, which is both good and bad. It can provide funding for threat-intel platforms, but may also limit reach when threat feeds and APIs get paywalled.

Workflow for IOC sharing:

1. Identify a potential malicious indicator (IP/domain/JA4 etc).
2. Pivot on the indicator to verify maliciousness and check for false positives.
3. If uncertain, ask in a trust-group, forum or request input on social media.
4. Check existing public feeds and databases for the IOC.
5. Assess urgency, impact, and victimology.
6. If new and high-impact: submit to one or several open sharing platforms.
7. If you have additional context: share it in a blog post or social notice.
8. If targeted or sensitive: notify the appropriate CERT or affected organizations privately.
9. If abuse/takedown is feasible: report to provider/registrar or request assistance from a national CERT.

I’m interested in hearing how others approach this. What works for you, and how do you maximize IOC sharing with minimal effort? Reach out via social media, email or share your thoughts in a writeup or blog post. Also, if you run an automated IOC propagation service, please reach out!

Posted by Erik Hjelmvik on Monday, 08 June 2026 07:00:00 (UTC/GMT)

Tags: #IOC​ #C2​ #ThreatFox​