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​

PolarProxy 2.0.1 Released

Our TLS inspection proxy PolarProxy has been updated with bug fixes, improved performance and more reliable PCAP output.

The recent PolarProxy 2.0 release added musl/Alpine compatibility and support for unencrypted HTTP proxy requests. But there were a few small, yet very important, updates that unfortunately didn’t make it into that release. The new PolarProxy 2.0.1 release takes care of this.

Bug Fixes

The PolarProxy 2.0.1 release fixes three bugs affecting non-TLS traffic: two that could block non-TLS connections under certain conditions, and one that could corrupt packets in output PCAP data.

Improved Performance

Memory overhead has been reduced as part of a major overhaul of PolarProxy’s data-flow logic. PolarProxy now caches less data, reducing CPU and memory use while supporting more simultaneous sessions.

PCAP vs Throughput

PolarProxy now prioritizes accurate PCAP output over raw proxy throughput. If the consumer of a real-time PCAP-over-IP stream (for example Arkime or Zeek) cannot process encrypted traffic fast enough, PolarProxy may rate-limit proxied traffic to avoid dropping packets in the PCAP output. This preserves every decrypted packet for forensic analysis, unlike many TLS-inspection products that sacrifice decrypted packets to maximize throughput.

A single dropped packet can cause major problems, particularly in forensic investigations. To ensure analysts see every decrypted packet, PolarProxy avoids dropping packets when possible.

Posted by Erik Hjelmvik on Friday, 05 June 2026 06:45:00 (UTC/GMT)

Tags: #PolarProxy​ #PCAP​ #TLS​ #proxy​

CapLoader 2.1.0 Released

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

TLS Client Hello Reassembly

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

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

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

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

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

Threat Intel and OSINT

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

• domain
• domain:port
• IP
• IP:port

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

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

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

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

Encapsulated Protocols

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

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

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

Improved Protocol Detection

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

Posted by Erik Hjelmvik on Wednesday, 27 May 2026 09:15:00 (UTC/GMT)

Tags: #CapLoader​ #JA3​ #JA4​ #TLS​ #QUIC​ #OSINT​ #encapsulation​ #decapsulation​ #GRE​

PolarProxy 2.0 Released

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

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

What's new

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

Why this release matters

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

Quick start for Linux (regular user)

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

Quick start for Linux with systemd

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

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

Quick start for Alpine Docker

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

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

Listening services in quick start examples

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

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

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

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

Test your deployment

Download PolarProxy’s root CA certificate:

Convert to PEM format:

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

Test transparent proxy in another terminal/shell:

Test SOCKS proxy:

Test HTTP proxy:

Downloads and docs

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

Feel free to share feedback or report bugs about PolarProxy.

Posted by Erik Hjelmvik on Monday, 18 May 2026 07:01:00 (UTC/GMT)

Tags: #PolarProxy​ #systemd​ #cutoff​