NETRESEC Network Security Blog

Maximizing IOC Impact

Erik Hjelmvik — Mon, 08 Jun 2026 07:00:00 GMT

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:

Identify a potential malicious indicator (IP/domain/JA4 etc).
Pivot on the indicator to verify maliciousness and check for false positives.
If uncertain, ask in a trust-group, forum or request input on social media.
Check existing public feeds and databases for the IOC.
Assess urgency, impact, and victimology.
If new and high-impact: submit to one or several open sharing platforms.
If you have additional context: share it in a blog post or social notice.
If targeted or sensitive: notify the appropriate CERT or affected organizations privately.
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!

PolarProxy 2.0.1 Released

Erik Hjelmvik — Fri, 05 Jun 2026 06:45:00 GMT

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.

CapLoader 2.1.0 Released

Erik Hjelmvik — Wed, 27 May 2026 09:15:00 GMT

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.

PolarProxy 2.0 Released

Erik Hjelmvik — Mon, 18 May 2026 07:01:00 GMT

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)

Download the appropriate tar archive for your platform (see download links).
Create directory:
mkdir ~/PolarProxy
Change directory:
cd ~/PolarProxy/
Extract the archive:
tar -xzf ~/Downloads/PolarProxy_2.0.0_linux-x64.tar.gz
Create log directory:
sudo mkdir -p /var/log/polarproxy
Change log dir owner:
sudo chown "$USER" /var/log/polarproxy
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

Download the appropriate tar archive for your platform (see download links).
Create and change into a new temp directory:
cd $(mktemp -d)
Extract the archive:
tar -xzf ~/Downloads/PolarProxy_2.0.0_linux-x64.tar.gz
Run install script:
sudo ./install-polarproxy-service.sh
Show service status:
systemctl status polarproxy.service
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

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

		curl -L -o /tmp/polarproxy.cer http://localhost:10080
	  

Convert to PEM format:

		openssl x509 -inform DER -in /tmp/polarproxy.cer -out /tmp/pp.crt
	  

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

		nc 127.0.0.1 57012 | tcpdump -Anr -
	  

Test transparent proxy in another terminal/shell:

  	  curl --cacert /tmp/pp.crt --connect-to www.netresec.com:443:127.0.0.1:10443 https://www.netresec.com/
	  

Test SOCKS proxy:

		curl --cacert /tmp/pp.crt --socks5 127.0.0.1 https://www.netresec.com/
	  

Test HTTP proxy:

		curl --cacert /tmp/pp.crt --proxy 127.0.0.1:8080 https://www.netresec.com/
	  

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.

Remcos Alerts from FlowCarp in EveBox

Erik Hjelmvik — Fri, 08 May 2026 11:49:00 GMT

There is a wonderful little web-based alert and event front-end called EveBox, which renders Eve JSON formatted data to a web UI. This blog post demonstrates how EveBox can be used to show alert and flow information that FlowCarp has extracted from a Remcos malware infection.

Remcos RAT

The starting point of my analysis will be a PCAP file with network traffic from a Remcos RAT infection, which Brad Duncan has published on Malware-Traffic-Analysis.net. The password scheme for the zip file containing the PCAP can be found here, in case you'd like to follow along and perform the same analysis steps yourself. All commands and examples in this blog post can be run in both Linux and Windows.

JSON formatted alerts and flow data can be extracted from the PCAP file with FlowCarp like this:

		flowcarp --input 2026-03-12-SmartApeSG-ClickFix-activity-for-Remcos-RAT.pcap --format EveJson --output -
	  

But the free community license of FlowCarp doesn't include a protocol model for Remcos, which is why this command will generate flow events but no alerts about detected Remcos malware traffic. I will therefore submit the pcap file to the free FlowCarp demo server instead, which has a commercial license that can identify over 600 protocols. No registration or API key is required to use this demo server (as long as users behave − please behave).

		curl --data-binary @2026-03-12-SmartApeSG-ClickFix-activity-for-Remcos-RAT.pcap -o remcos-eve.json https://demo.flowcarp.com
	  

The downloaded remcos-eve.json file uses the Suricata Eve JSON format, so jq queries typically used to process Suricata eve.json log files can be used to parse and filter the JSON output from FlowCarp as well.

jq -c 'select(.event_type=="alert")|[.dest_ip, .dest_port, .proto, .alert.signature]' < remcos-eve.json
["193.178.170.155",443,"TCP","MALWARE protocol detected: TLS, Remcos"]

This FlowCarp alert indicates that the PCAP file contains TLS-encrypted Remcos traffic, which means that FlowCarp has performed a so-called sub-protocol match to detect the protocol inside of TLS without decrypting the TLS layer. A quick way to verify if this traffic is Remcos in TLS is to check the JA3 hash or JA4 fingerprint of the client's TLS handshake.

tshark -r 2026-03-12-SmartApeSG-ClickFix-activity-for-Remcos-RAT.pcap -Y "ip.dst == 193.178.170.155 and tls.handshake" -T fields -e tls.handshake.ja3 -e tls.handshake.ja4
a85be79f7b569f1df5e6087b69deb493 t13i010400_0f2cb44170f4_5c4c70b73fa0

This nicely matches what we expect to see from TLS encrypted Remcos traffic. For reference these are the JA3 and JA4 fingerprints typically associated with Remcos:

JA3: a85be79f7b569f1df5e6087b69deb493
JA4: t13i010400_0f2cb44170f4_5c4c70b73fa0
JA4: t13i010400_0f2cb44170f4_1b583af8cc09

There is always a risk of false positives associated with JA3 or JA4 fingerprints, so a rule of thumb is to not blindly trust JA3/JA4 based alerts without having additional indicators of compromise. FlowCarp performs a much deeper identification of sub-TLS protocols than JA3/JA4, but there's still a false positive risk associated with detection of encrypted malware traffic — so make sure to verify alerts like this with other types of data sources, such as event logs from the infected device or OSINT information about the suspected C2 server. For this alert we can see that @DonPasci has reported 193.178.170.155:443 to ThreatFox as being a Remcos C2 server.

EveBox

EveBox is a web-based front-end for Suricata "EVE" alerts and events, created by Jason Ish. The EveBox source code lives on GitHub and pre-built EveBox binaries for Linux and Windows are available on evebox.org.

This evebox command will fire up a browser and render information about the flows and alerts in the Eve JSON file from FlowCarp:

		evebox oneshot remcos-eve.json
	  

The flows and alerts are displayed in reverse order, so that the most recent events are on top. The Remcos alert stands out in red and immediately catches your eye. Let's change Event Type from "All" to "Alert" just to make sure there are no other alerts.

Looks like this was the only alert in this JSON file.

EveBox is built for Suricata, but it's really nice that it can be used out-of-the-box to read FlowCarp's JSON logs as well. For reference, let's also see what it looks like when we run the same PCAP file through Suricata and import eve.json into EveBox.

I'm happy to see that Suricata also alerts on the same TCP session as FlowCarp. This alert was raised by the Emerging Threats signature ID 2036594, which triggers whenever the JA3 hash of a TLS handshake is a85be79f7b569f1df5e6087b69deb493.

FlowCarp Identifies Protocols

Erik Hjelmvik — Mon, 04 May 2026 14:53:00 GMT

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

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

FlowCarp Demo Service

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

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

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

		curl --data-binary @260504-hkcr6adt5x-behavioral1.pcapng -o mirai-eve.json https://demo.flowcarp.com
	  

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

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

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

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

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

Running FlowCarp Locally

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

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

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

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

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

Real-Time Protocol Identification

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

		tcpdump -U -w - | flowcarp --input - --realtime --preview --output -
	  

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

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

		./pcap-broker -listen 127.0.0.1:57012 -cmd "sudo tcpdump -i eth0 -U -w -"
	  

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

		./flowcarp --input tcpconnect:127.0.0.1:57012 --realtime --preview --output -
	  

I hope you'll find FlowCarp useful!

CISA mixup of IOC domains

Erik Hjelmvik — Thu, 26 Feb 2026 09:35:00 GMT

Google's Threat Intelligence Group (GTIG) and Mandiant's recent Disrupting the GRIDTIDE Global Cyber Espionage Campaign report is great and it has lots of good Indicators of Compromise (IOC). Many of these IOCs had already been shared by CISA last year as part of their Alert AA25-141A titled "Russian GRU Targeting Western Logistics Entities and Technology Companies". The IOC overlap between these two reports is surprisingly big, provided that the GTIG report covers a Chinese espionage group while the CISA report covers the Russian GRU unit 26165 (aka APT28 / Fancy Bear).

But some of the domain names in CISA's report from last year are strange. For example, the domain name "accesscan[.]org" doesn't seem to ever have been registered. The GTIG report, however, contains the very similar domain "accesscam[.]org". This accesscam domain is registered to the dynamic DNS provider Dynu Systems, whose services are often abused by malicious actors. Is it possible that there are typos in the IOCs published by CISA? I think so.

Another odd domain in CISA's AA25-141A is "glize[.]com", which I suspect is a typo from either "giize[.]com" or "gleeze[.]com". The two latter domains are listed in the GTIG report and both of them also belong to the dynamic DNS provider Dynu Systems. The domain listed in CISA's alert, on the other hand, appears to be a legit website (archived page from 2024) from the marketing company Glize in Malta.

Glize's website seems to have disappeared sometime in 2025.

Update 2026-02-27

The IOC list published by CISA originates from cybersecurity advisory 157019-25 / PP-25-2107, which was created as a joint effort by the following 21 organizations:

United States National Security Agency (NSA)
United States Federal Bureau of Investigation (FBI)
United Kingdom National Cyber Security Centre (NCSC-UK)
Germany Federal Intelligence Service (BND)
Germany Federal Office for Information Security (BSI)
Germany Federal Office for the Protection of the Constitution (BfV)
Czech Republic Military Intelligence (VZ)
Czech Republic National Cyber and Information Security Agency (NÚKIB)
Czech Republic Security Information Service (BIS)
Poland Internal Security Agency (ABW)
Poland Military Counterintelligence Service (SKW)
United States Cybersecurity and Infrastructure Security Agency (CISA)
United States Department of Defense Cyber Crime Center (DC3)
United States Cyber Command (USCYBERCOM)
Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC)
Canadian Centre for Cyber Security (CCCS)
Danish Defence Intelligence Service (DDIS)
Estonian Foreign Intelligence Service (EFIS)
Estonian National Cyber Security Centre (NCSC-EE)
French Cybersecurity Agency (ANSSI)
Netherlands Defence Intelligence and Security Service (MIVD)

It is therefore unclear which organization(s) reported the erroneous IOCs as well as who were responsible for verifying them before publication.

In summary, these are the incorrect and correct IOC domains:

Incorrect IOC: *.accesscan[.]org (not registered)
Correct IOC: *.accesscam[.]org (registered by Dynu Systems)
Incorrect IOC: *.glize[.]com (legitimate website, now closed)
Correct IOC: *.giize[.]com (registered by Dynu Systems)
Correct IOC: *.gleeze[.]com (registered by Dynu Systems)

njRAT runs MassLogger

Erik Hjelmvik — Mon, 02 Feb 2026 19:39:00 GMT

njRAT is a remote access trojan that has been around for more than 10 years and still remains one of the most popular RATs among criminal threat actors. This blog post demonstrates how NetworkMiner Professional can be used to decode the njRAT C2 traffic to extract artifacts like screenshots, commands and transferred files.

A PCAP file with njRAT traffic was published on malware-traffic-analysis.net last week. After loading this PCAP file, NetworkMiner Professional reveals that the attacker downloaded full resolution screenshots of the victim’s screen.

Image: Overview of screenshots sent to C2 server

Image: Screenshot extracted from njRAT traffic by NetworkMiner

The file “New Purchase Order and Specifications.exe” in this screenshot is the njRAT binary that was used to infect the PC.

A list of njRAT commands sent from the C2 server to the victim can be viewed on NetworkMiner’s Parameters tab by filtering for ”njRAT server command”.

The following njRAT commands are present here:

CAP = take screenshot
inv = invoke (run) a plugin (dll)
rn = run a tool (executable)

Additional njRAT commands can be found in our writeup for the Decoding njRAT traffic with NetworkMiner video, which we published last year.

njRAT File Transfers

The “inv” and “rn” commands both transfer and execute additional code on the victim machine. The “inv” command typically transfers a DLL file that is used as a plugin, while the “rn” commands sends an executable file. These DLL and EXE files are transferred in gzip compressed format, which is why NetworkMiner extracts them as .gz files.

Image: Gzip compressed files extracted from njRAT traffic

This oneliner command lists the internal/original file names and corresponding MD5 hashes of the gzip compressed executables sent to the victim PC:

for f in njRAT-rn*.gz; do echo $f; gunzip -c $f | exiftool - | grep Original; gunzip -c $f | md5sum; done
njRAT-rn-260129030403.gz
Original File Name : Stub.exe
ca819e936f6b913e2b80e9e4766b8e79 -
njRAT-rn-260129030433.gz
Original File Name : Stub.exe
e422a4ce321be1ed989008d74ddb6351 -
njRAT-rn-260129030451.gz
Original File Name : CloudServices.exe
fcbb7c0c68afa04139caa55efe580ff5 -
njRAT-rn-260129031041.gz
Original File Name : Stub.exe
0ae3798c16075a9042c5dbb18bd10a5c -

The MD5 hashes of the files inside the gzip compressed streams can also be seen on the Parameters tab in NetworkMiner.

MassLogger

The “CloudServices.exe” executable is a known credential stealer called MassLogger. This particular MassLogger sample is hard coded to exfiltrate data in an email to kingsnakeresult@mcnzxz[.]com. The email is sent through the SMTP server cphost14.qhoster[.]net. See the execution of this sample on Triage for additional details regarding the MassLogger payload in CloudServices.exe.

IOC List

njRAT (splitter = "|Ghost|")

58f1a46dba84d31257f1e0f8c92c59ec = njRAT sample
104.248.130.195:7492 = njRAT C2 server
burhanalassad.duckdns[.]org:7492 = njRAT C2 server
801a5d1e272399ca14ff7d6da60315ef = sc2.dll
ca819e936f6b913e2b80e9e4766b8e79 = Stub.exe
e422a4ce321be1ed989008d74ddb6351 = Stub.exe
fcbb7c0c68afa04139caa55efe580ff5 = CloudServices.exe
0ae3798c16075a9042c5dbb18bd10a5c = Stub.exe

MassLogger

fcbb7c0c68afa04139caa55efe580ff5
kingsnakeresult@mcnzxz[.]com
cphost14.qhoster.net:587
78.110.166.82:587