NETRESEC Network Security Blog

CapLoader 2.2 Released

Erik Hjelmvik — Mon, 19 Oct 2026 08:48:00 GMT

CapLoader 2.2 adds new alerts for services and infrastructure that may be abused, makes flow transcripts easier to navigate and improves alert-based coloring. It also includes more helpful BPF filter feedback and several bug fixes.

More alerts

CapLoader’s alerting has been expanded with built-in detections for online services and infrastructure that are commonly abused, along with support for external blocklists from IFIN, GAYINT and Spamhaus.

New alert types include:

IPFS services and gateways
Port forwarding services
Abused web hosting and cloud storage services
VPN, proxy and tunnel protocols
Blockchain RPC nodes
Paste bin domains
Bulletproof, scanner and VPN ASNs

Many of these alerts are informational, while others are low severity.

Transcript navigation and row coloring

You can now move between flow transcripts using the arrow keys. To make moving to the next transcript quicker, CapLoader anticipates the next Flow Index and pre-fetches its frames.

Thanks to André for suggesting the transcript navigation feature during one of my trainings!

Video: Transcript of flows in Johannes Weber’s Ultimate PCAP

CapLoader 2.2 also adds the AlertSeverity row color scheme. It colors each flow, service and host according to the highest-severity alert associated with it.

Here’s CapLoader with the traditional Wireshark style color scheme:

This is what the same traffic looks like with the new AlertSeverity color scheme:

Both screenshots show the same capture file, which contains traffic from an XMRig sample on Triage.

BPF filter boxes now provide better error checking, with colors and tooltips to warn about possible syntax mistakes. You can also press Enter to open the transcript for a selected flow from any tab, not just the Flows tab. If you select multiple flows, Enter opens multiple transcripts.

Bug fixes

This release fixes an issue that could prevent the “About CapLoader” window from opening, as well as a crash that could occur when reading very large frames. It also fixes JA4 fingerprints when TLS Signature Algorithms contain GREASE values.

Detecting AtlasRAT C2

Erik Hjelmvik — Mon, 12 Oct 2026 14:30:00 GMT

Around May 2026 Atlas RAT began using a new variant of its command-and-control (C2) protocol. Earlier versions started with a distinctive byte sequence:

53 46 75 63 6b 00 00 00

In ASCII, that is “SFuck” followed by three null bytes. The newer traffic starts with “BFuck”, also followed by three null bytes:

42 46 75 63 6b 00 00 00

Image: CapLoader transcript of AtlasRAT traffic in PCAP from Triage

Attribution

Atlas RAT has been linked to Silver Fox (银狐), a Chinese-nexus threat group also tracked as Void Arachne, TA4922, SwimSnake and UTG-Q-1000. The group has been associated with trojanized software and malware including ValleyRAT (Winos4.0) and Gh0st RAT.

The Atlas RAT link remains circumstantial. However, we have observed ValleyRAT and AtlasRAT using the same C2 servers on different ports, suggesting a shared operator.

The New C2 Variant

We found that FlowCarp could detect the new BFuck variant even though its Atlas RAT detection model had originally been built using examples of the older “SFuck” traffic.

Image: FlowCarp win.atlas_rat alert for Atlas RAT PCAP from ANY.RUN

The updated model now includes examples of both variants. Because FlowCarp analyzes more than just the initial check-in sequence, we expect it to reliably detect Atlas RAT traffic even if that sequence changes again.

The initial check-in also reveals a change in the C2 server’s port. The older variant was primarily seen on TCP ports 886 and 9899. The new variant was observed on TCP port 443.

Stage 1 Loader

The initial “BFuck” or “SFuck” check-in comes from a loader. The loader retrieves 300 to 500 kB of shellcode containing a DLL with the full Atlas RAT backdoor. Atlas RAT then opens another connection to the same C2 server, this time using a different protocol.

For more details on the loader, backdoor and C2 traffic structure, see HexaStrike’s Trust the Tunnel, Get the Trojan write-up by Maurice Fielenbach.

Changes to the Legacy C2 Traffic

Maurice determines that Atlas RAT’s C2 protocol uses ChaCha20 encryption. Each encrypted packet also carries a 56-byte header in cleartext:

4 bytes: sequence number
4 bytes: compressed size
4 bytes: original size
4 bytes: padding or flags
32 bytes: ChaCha20 key
8 bytes: ChaCha20 nonce

Image: Atlas RAT C2 traffic in PCAP from Triage

By the end of March 2026, just a few days after HexaStrike’s publication, we observed the actors change their approach. They began XOR-encrypting the transmitted data with a fixed key that starts with a7 3b f1 8c.

Image: Atlas RAT XOR-encrypted C2 header in PCAP from Triage

I won’t go into more detail about this XOR-encrypted variant here. The actors abandoned it in July 2026 in favor of a new approach.

TLS becomes the new Atlas RAT C2

In July 2026, Atlas RAT began using TLS for C2 communication. After the initial “BFuck” check-in, the backdoor established a new TLS-encrypted session with the C2 server.

The TLS client and server handshakes have distinctive JA3 fingerprints:

JA3: e26606c572e55d499b0676e9095e3df8
JA3S: f98a4985f829b6513fbeccf5b751b458

The C2 server typically presents a self-signed X.509 certificate that impersonates update.microsoft.com.

The certificate thumbprint is:

a66308a1fb09c8345228ca00335e633b2dabde53

Suricata Signatures

If you’re not ready to deploy FlowCarp for C2 detection, these Suricata rules can detect the SFuck and BFuck check-ins:

		alert tcp-pkt $HOME_NET any -> $EXTERNAL_NET any (msg:"Atlas RAT loader SFuck checkin"; flow:to_server; content:"|53 46 75 63 6b 00 00 00|"; startswith; metadata: malware_family win.atlas_rat; classtype:trojan-activity; reference:url,https://netresec.com/?b=26A6cc8; sid:1471105; rev:1;)

		alert tcp-pkt $HOME_NET any -> $EXTERNAL_NET any (msg:"Atlas RAT loader BFuck checkin"; flow:to_server; content:"|42 46 75 63 6b 00 00 00|"; startswith; metadata: malware_family win.atlas_rat; classtype:trojan-activity; reference:url,https://netresec.com/?b=26A6cc8; sid:1471106; rev:1;)

This rule alerts on Atlas RAT’s C2 TLS handshake:

		alert tcp-pkt $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Atlas RAT TLS handshake"; flow:established,to_server; content:"|00 00 0c 00 3d 00 35 00 9c 00 3c 00 2f 00 ff 01 00 00 10 00 0d 00 04 00 02 04 01 00 16 00 00 00 17 00 00|"; offset:43; metadata: malware_family win.atlas_rat; classtype:trojan-activity; reference:url,https://netresec.com/?b=26A6cc8; sid:1471107; rev:1;)
	  

And this one on the self-signed X.509 certificate:

		alert tls $EXTERNAL_NET 443 -> $HOME_NET any (msg:"Atlas RAT fake Microsoft certificate"; flow:established,to_client; content:"|03 7d 30 82 03 79 30 82 02 61 a0 03 02 01 02 02 14 64 72 4e 8c f1 71 88 bc ff e5 19 0b 69 e0 cb 52 6d 38 9a df 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 4c 31 1d 30 1b 06 03 55 04 03 0c 14 75 70 64 61 74 65 2e 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d|"; offset:12; depth:107; classtype:trojan-activity; reference:url,https://netresec.com/?b=26A6cc8; sid:1471108; rev:1;)
	  

These Suricata rules are also available for download from our Suricata GitHub repo:
https://github.com/Netresec/Suricata

Further Reading

More information about Atlas RAT is available in write-ups from Proofpoint and Hexastrike.

IOC Lists

IP-port:

23.226.57.50:443
38.76.177.46:443
43.99.101.175:443
45.142.152.180:443
116.204.169.70:443
150.158.50.175:443
156.234.7.48:443
192.252.180.45:443

Domains:

laicaishuli[.]com
yilufafafa[.]club
zixungongsi[.]top

Other:

JA3: e26606c572e55d499b0676e9095e3df8
JA3S: f98a4985f829b6513fbeccf5b751b458
Cert SHA-1: a66308a1fb09c8345228ca00335e633b2dabde53

NetworkMiner 3.2 Released

Erik Hjelmvik — Wed, 07 Oct 2026 11:30:00 GMT

NetworkMiner 3.2 parses RADIUS authentication data and extracts more details from the OT/ICS protocols UMAS and IEC-104. The release also improves several existing protocol parsers and fixes file-reassembly issues, helping analysts extract more information from captured network traffic.

OT Protocol Support

NetworkMiner parses many OT/SCADA/ICS communication protocols, such as CIP, COTP, EtherNet/IP, IEC 60870-5-104, Modbus/TCP and UMAS. The parsers for UMAS and IEC-104 have been updated in this release.

The parser for Schneider Electric’s proprietary UMAS protocol in NetworkMiner has been improved. NetworkMiner can now extract data from UMAS commands “Read Physical Address” and “Write Physical Address”. This addition enables analysts to determine not only if data stored in memory of a Schneider Modicon PLC has been modified, but also what changed. This visibility is particularly valuable when performing forensic analysis of OT network traffic after an incident.

Image: Data 0x43 written to address 0x0001FF4E on a Modicon M221 PLC

NetworkMiner can parse most commands defined by the IEC 60870-5-104 protocol, which is used for monitoring and controlling systems in European and Asian power grids.

In this release we’ve added support for IEC-104 command ID 60 (C_RC_TA_1) “Regulating step command with time tag CP56Time2a”, which is used to increase or decrease a data-point by one.

Image: Data-point at IOA 16 decremented using IEC-104 command ID 60

RADIUS

NetworkMiner now includes a parser for the authentication and authorization protocol RADIUS. The parser extracts usernames, passwords (encrypted or hashed), IP addresses, messages and various RADIUS-specific identifiers.

Image: Usernames and password related attributes extracted from RADIUS traffic

Image: Parameters extracted from RADIUS packets

RADIUS traffic for the screenshots above comes from Wireshark’s Sample Captures (radius_localhost.pcap) and Johannes Weber’s Ultimate PCAP.

JA4 Download in NetworkMiner Professional

Many users of NetworkMiner Professional have received an error message saying “JA4 database download failed”.

This error message is displayed when NetworkMiner Professional tries to download a JA4 database from FoxIO’s website ja4db.com. After consulting FoxIO in 2024, we implemented a solution that automatically retrieved the JA4 database and checked for updates every 30 days.

FoxIO no longer provides this database for download, which is why users saw “JA4 database download failed” messages. We apologize for any inconvenience this may have caused.

Version 3.2 no longer attempts to download this database.

Bug Fixes and Other Improvements

NetworkMiner 3.2 includes fixes for several bugs reported by Jeliazko Zlatev, which relate to how files are extracted from PCAP data (thank you Jeliazko!). We have also improved parsers for protocols like HTTP, SIP and DNS to extract even more data from the analyzed network traffic to the various tabs on the user interface.

Upgrading to Version 3.2

Users who have purchased NetworkMiner Professional can download version 3.2 from our customer portal, or use the “Check for Updates” feature from NetworkMiner’s Help menu. Users who prefer to use the free and open source version can grab the latest release of NetworkMiner from the official NetworkMiner page.

Stop Feeding the SOC Garbage

Erik Hjelmvik — Tue, 06 Oct 2026 06:30:00 GMT

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.

Unmasking Malware Families

Erik Hjelmvik — Mon, 21 Sep 2026 10:00:00 GMT

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:

	  flowcarp --input xyz.pcap --output model:MalwareXYZ:MALICIOUS:malwarexyz.fcp
	

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:

		flowcarp --model malwarexyz.fcp --input new.pcap --output -
	  

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:

	  curl --data-binary @dump.pcap https://demo.flowcarp.com
	  

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.

	  curl --data-binary @dump.pcap https://demo.flowcarp.com | jq
	  

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.

PolarProxy 2.0.2 Released

Erik Hjelmvik — Tue, 08 Sep 2026 12:35:00 GMT

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 --socks 1080 --connect socks5:127.0.0.1:9050 --nontls allow --pcapoverip 57012 --writeall
	  

Note PolarProxy normally serves only decrypted TLS traffic over PCAP-over-IP. The --writeall option extends the PCAP output to include all proxied traffic.

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:

		PolarProxy --httpconnect 8080 --haproxy 7654 --nontls allow --connect socks5:localhost:1080
	  

Pro-Tip Use PolarProxy’s --bypass switch if you want to use PolarProxy only as a protocol converter, without decrypting and re-encrypting TLS traffic.

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.

Pro-Tip Use PolarProxy’s --helpenv switch to print a list of supported environment variables.

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:

		curl https://www.netresec.com/?download=PolarProxy_linux-musl-x64 | tar -xzf -

		# Modify polarproxy.env

		docker compose up -d

A systemd service can be deployed with:

		curl https://www.netresec.com/?download=PolarProxy | tar -xzf -

		# Modify polarproxy.env

		./install-polarproxy-service.sh

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.

OT Networks Still Need Monitoring

Erik Hjelmvik — Mon, 31 Aug 2026 11:50:00 GMT

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.

CNCMachineRMS C2 Protocol

Erik Hjelmvik — Fri, 21 Aug 2026 14:45:00 GMT

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:

		  %TEMP%\CNCMachineRMS\tasks\[TASK_ID]\task_payload.bin
		

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:

		curl --data-binary @suspicious.pcap https://demo.flowcarp.com
	  

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

IOC List

Indicator	Details
89.110.110.119:443	first seen 2026-04-06 last seen 2026-05-27
85.158.110.78:443	first seen 2026-06-30 last seen 2026-08-02
89.124.79.98:443	first seen 2026-06-30 last seen 2026-07-31
144.124.242.171:443	first seen 2026-08-12 last seen 2026-08-12
notepadreleased[.]com	registered 2026-04-02
triotmelon[.]com	registered 2026-08-04
b0bc47a7308bd39a5b638781874a3d8e	JSONSchema.zip
ca88a6c055a96e1a6fa47e2586d41d2a	python.zip
e421ad53b169282b04e50e1b9d1faa9e	403404323857317050-pdf.zip
eba2bbd380b6949a249aba5c3ed13245	81241123044010750.pdf