NETRESEC Network Security Blog

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

Decoding malware C2 with CyberChef

Erik Hjelmvik — Tue, 20 Jan 2026 12:10:00 GMT

This video tutorial demonstrates how malware XOR encrypted and obfuscated C2 traffic can be decoded with CyberChef.

The analyzed PCAP files can be downloaded from malware-traffic-analysis.net.

CyberChef recipe to decode the reverse shell traffic to 103.27.157.146:4444:

From_Hex('Auto')
XOR({'option':'Hex','string':'62'},'Standard',false)
Find_/_Replace({'option':'Regex','string':'\\r'},'',true,false,true,false)
From_HTML_Entity()

Decoded data from first "key007" reverse shell session to 103.27.157.146:4444:

				key007

				Authentication successful

				furtheringthemagic.com

				net group "domain computers" /domain

				The request will be processed at a domain controller for domain furtheringthemagic.com.

				Group name     Domain Computers

				Comment        All workstations and servers joined to the domain

				Members

				-------​--------​-------​--------​-------​---------​-------​----------​--------​--------

				DESKTOP-G71S4PF$

				The command completed successfully.

CyberChef recipe to decode obfuscated PowerShell payload from malicious finger service on 64.190.113.206:79:

Fork(',','',false)
Pad_lines('End',5,',6044')
Subtract('Comma')
From_Charcode('Space',10)

Update 2026-01-21

Our classification of the final payload has been updated from AsyncRAT to GhostWeaver thanks to feedback from Don Pasci. Don referenced a writeup by Recorded Future's Insikt Group, called Uncovering MintsLoader With Recorded Future Malware Intelligence Hunting, which states the following:

GhostWeaver has periodically been misclassified as AsyncRAT. [...] GhostWeaver and AsyncRAT share certain characteristics within their self-signed X.509 certificates, such as identical expiration dates and serial number lengths; however, these similarities may simply reflect common certificate-generation methods rather than meaningful operational overlap.

We also believe that some of the PowerShell related traffic was caused by MintsLoader.

IOC List

103.27.157.146:4444 (unknown "key007" reverse shell)
64.190.113.206:79 (finger)
checkifhuman[.]top (finger)
ey267te[.]top (MintsLoader)
64.52.80.153:80 (MintsLoader)
173.232.146.62:25658 (~~AsyncRAT~~ GhostWeaver)
08kcbghk807qtl9[.]fun:25658 (~~AsyncRAT~~ GhostWeaver)

Network Forensics Training

Check out our network forensic trainings if you want to learn more about decoding malware C2 traffic. I'm teaching a live online Network Forensics for Incident Response class on February 23-26.

Latrodectus BackConnect

Erik Hjelmvik — Wed, 10 Dec 2025 13:00:00 GMT

This blog post demonstrates how artifacts, such as reverse shell commands and VNC session screenshots, can be extracted from Latrodectus BackConnect C2 traffic with NetworkMiner.

I recently learned that the great folks from The DFIR Report have done a writeup covering the Latrodectus backdoor. Their report is titled From a Single Click: How Lunar Spider Enabled a Near Two-Month Intrusion.

I found it particularly interesting that the threat actors used Latrodectus to drop a BackConnect RAT to the victim PC. I have verified that this RAT’s Command and Control (C2) traffic is using the exact same BackConnect C2 protocol as what would previously be seen in IcedID and QakBot infections.

This BackConnect RAT supports features such as:

Reverse VNC (Keyhole)
Reverse SOCKS
Reverse shell (cmd.exe or powershell)
File manager

NetworkMiner

I immediately recognized the BackConnect protocol because I spent many hours reverse engineering that protocol back in 2022. I later spent even more time building a parser for it in 2023. This BackConnect parser was eventually published as part of the NetworkMiner 2.8.1 release.

I was happy to see that NetworkMiner could parse the BackConnect traffic in The DFIR Report’s Latrodectus case (#TB28761).

The only caveat was that I had to use NetworkMiner Professional, because it has a built-in protocol detection feature that detects the BackConnect traffic and applies the correct parser. That feature isn’t included in the free version of NetworkMiner, which is why it doesn’t know what to do with this strange looking TCP traffic to port 443.

Below are some screenshots extracted with NetworkMiner Professional from the BackConnect reverse VNC traffic.

Image: Keyhole reverse VNC session

Image: Attacker fails to inspect ad_users.txt

Image: Attacker launches additional malware with rundll

The reverse VNC activity spanned a period of over two weeks, which is very impressive for this type of intrusion data set. The threat actors used the BackConnect reverse VNC service to access the machine several times during this period, for example to steal credentials and install additional malware.

A histogram of interactive BackConnect events, including reverse shell, VNC and file manager sessions, show that the majority of the work was carried out around 12pm UTC.

Keylog of the Attacker

Not only does the BackConnect network traffic from the intrusion allow us to extract screenshots from the VNC traffic. NetworkMiner also extracts the attacker’s hands-on keyboard activity.

The keylog shows that the attacker accidentally typed “cd //” instead of “cd ..” at one point. Here’s the screenshot that NetworkMiner extracted from the reverse VNC traffic after the attacker had corrected the typo.

This typo might seem a bit odd, but if you compare the US keyboard layout with the Russian Cyrillic one, then you’ll see that the dot key on the Cyrillic keyboard is at the same place as slash on the US keyboard.

Image: Russian Windows keyboard layout from Wikipedia

This reminds me of another BackConnect infection, captured by Brad Duncan, which he named IcedID (BokBot) infection with Keyhole VNC and Cobalt Strike. Here’s a screenshot that NetworkMiner extracted from the PCAP file shared by Brad:

The attacker can be seen typing “фьфящт” into the browser’s address bar in that VNC session. Фьфящт doesn’t mean anything in Russian, but the individual positions on the Russian keyboard corresponds to “amazon” on a standard Latin keyboard layout.

Reverse Shell

NetworkMiner also extracts commands from BackConnect reverse shell sessions.

This screenshot shows that the attacker sent the following command to the reverse shell:

				rundll32 C:\ProgramData\sys.dll,StartUp471
			

This command launched a Cobalt Strike implant that connected to avtechupdate[.]com. Analysis of the Cobalt Strike C2 traffic is not in the scope for this blog post though, but the original writeup for this lab contains additional details on the Cobalt Strike infection.

The attacker later issued another rundll command to launch another red-team/penetration testing tool, namely Brute Ratel C4.

				rundll32 wscadminui.dll, wsca
			

This Brute Ratel backdoor connected to C2 servers on erbolsan[.]com and a few other domains (see IOC list). The DFIR Report’s writeup contains additional information about that payload as well.

About The DFIR Report

The DFIR Report provide analysis of cyber intrusions, detailing the tactics, techniques, and procedures used by attackers. They share insights into various attacks, from initial access to execution, and offer private threat briefs and reports for organizations.

A lab containing Elastic or Splunk data from this infection can be purchased from The DFIR Report’s store. Look for the lab titled “The Lunar Tangled Malware Web - Public Case #28761”. The DFIR Report also sell access to a threat intelligence service, which contains even more detailed lab data from this and other malware infections.

Netresec is not affiliated with The DFIR Report.

IOC List

The analyzed infection is from 2024, so these indicators are in no way fresh. They are included here for research purposes and to facilitate retro hunting.

BackConnect C2 ip:port

185.93.221.12:443
193.168.143.196:443

Latrodectus domains

grasmetral[.]com
illoskanawer[.]com
jarkaairbo[.]com
scupolasta[.]store
workspacin[.]cloud

Cobalt Strike C2 URI

hxxps://resources.avtechupdate[.]com/samlss/vm.ico

Brute Ratel C4 domains

dauled[.]com
erbolsan[.]com
kasym500[.]com
kasymdev[.]com
samderat200[.]com

Network Forensics Training

Check out our network forensics training if you want to learn more about analyzing malware traffic in PCAP files.

I will teach an online class for incident responders and blue teams on February 23-26. That class allows a maximum of 15 attendees in order to provide a good environment for taking questions. So don’t miss out on this chance to get your hands dirty with some packet analysis together with me!

NetworkMiner 3.1 Released

Erik Hjelmvik — Mon, 01 Dec 2025 08:20:00 GMT

This NetworkMiner release brings improved extraction of artifacts like usernames, passwords and hostnames from network traffic. We have also made some updates to the user interface and continued our effort to extract even more details from malware C2 traffic.

More Artifacts Extracted

Usernames and passwords are now extracted from Proxy-Authenticate headers. NetworkMiner’s username extraction support for SMTP AUTH LOGIN requests has also been improved.

Image: Username and password extracted from HTTP Proxy-Authenticate header

NetworkMiner has several methods for passively identifying host names of clients and servers. We’ve added a few additional hostname sources to this release, such as client hostnames from SMTP EHLO requests and TLS SNI fields from RDP traffic.

User Interface Improvements

The most significant user interface update in the 3.1 release is probably the new “Not in” keyword filter mode. I received this feature request when teaching a network forensics class (thanks for the great idea Lukas!). This filter mode is the opposite to the default “Exact Phrase” setting.

Image: Parameters extracted from anything but HTTP traffic in Johannes Weber's Ultimate PCAP

The “Not in” filter mode comes in very handy when the information you’re interested in is drowning in a sea of non-relevant, but easily identifiable, data.

Malware C2 Traffic

NetworkMiner can extract information from various malware Command-and-Control (C2) protocols like Latrodectus/IcedID BackConnect, Meterpreter, njRAT, Redline Stealer, Remcos, RMS and StealC. The free version of NetworkMiner can extract information, such as commands or transferred files, from these malware protocols as long as the C2 server listens on a “standard” port number. But if the C2 server runs on some other port (which often is the case), then NetworkMiner Professional’s Port Independent Protocol Identification (PIPI) feature is required to identify the correct parser for the network traffic.

Implementing malware C2 protocol parsers is sometimes a thankless task because these protocols tend to get replaced at a much higher rate compared to legitimate network protocols. But it is an important task nevertheless.

njRAT

A popular malware for which the C2 protocol hasn’t changed much during the past decade is njRAT. In fact, new njRAT samples are discovered by security researchers pretty much every day despite it being a 13 years old trojan. NetworkMiner’s njRAT support has therefore been improved in this release. NetworkMiner can extract files that are uploaded or downloaded to/from a PC infected with njRAT. This file extraction feature also includes the ability to extract plugins for specific tasks, such as to run a reverse shell, see camera images or steal passwords. njRAT C2 servers transmit these plugins as gzip compressed DLL files to victim computers when needed.

Image: Files extracted from njRAT in PCAP from our network forensics class

NetworkMiner extracts these gz compressed plugin DLL files to disk. A new feature in the 3.1 release is that it then decompresses the gz data and calculates an MD5 hash of the file contents, but without saving the decompressed data to disk. The MD5 hash of the transferred files are instead displayed on the Parameters tab as seen in this screenshot:

Image: MD5 hashes of njRAT plugin DLLs

The following njRAT plugin MD5 hashes can be seen in this screenshot:

cef141d894400bc2e0096d1ed0c8f95b (aka inf.dll)
a73edb60b80a2dfa86735d821bea7b19 (aka cam.dll)
a93349ba5e621cfb7a46dc9f401fd998 (aka plg.dll)
11375fb0cee4c06b5cefa2031ee2ed6d (aka pw.dll)
19967e886edcd2f22f8d4a58c8ea3773 (aka sc2.dll)

See our video Decoding njRAT traffic with NetworkMiner for a more in-depth demonstration of NetworkMiner’s njRAT parsing features.

Redline Stealer

Another common malware is Redline Stealer. It uses a legitimate protocol called MC-NMF to send instructions and exfiltrate data from victim computers. Basic support for the MC-NMF protocol has therefore been added to NetworkMiner 3.1. MC-NMF is also used by legitimate services like Microsoft’s Service Bus, so as a bonus you can now analyze such traffic with NetworkMiner as well. The MC-NMF protocol has a compression routine called MC-NBFSE, which is utilized by Redline Stealer. NetworkMiner can’t decompress this format, so files are extracted to disk in compressed form.

Image: Files extracted from Redline execution on Joe Sandbox

You can probably spot some interesting details in the extracted data even when viewing the NBFSE compressed contents though.

Image: NBFSE compressed file contents extracted from Redline execution on Joe Sandbox

Bug Fixes

NetworkMiner 3.1 also resolves several minor bugs. One of these bugs could cause NetworkMiner to hang when showing file details in Linux. Another resolved bug prevented some IPv6 payload from being parsed correctly if the Ethernet frame contained trailing padding data. The VoIP call metadata extraction has also been improved in NetworkMiner Professional.

Upgrading to Version 3.1

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

Optimizing IOC Retention Time

Erik Hjelmvik — Thu, 06 Nov 2025 12:05:00 GMT

Are you importing indicators of compromise (IOC) in the form of domain names and IP addresses into your SIEM, NDR or IDS? If so, have you considered for how long you should keep looking for those IOCs?

An IoT botnet study from 2022 found that 90% of C2 servers had a lifetime of less than 5 days and 93% had a lifetime shorter than 14 days. Additionally, a recent writeup from Censys concludes that the median lifespan of Cobalt Strike C2 servers is 5 days. Both these studies indicate that IP and domain name indicators are short lived, yet many organizations cling on to old IOCs for much longer than so. Monitoring for too many old indicators not only costs money, it can even inhibit detection of real intrusions.

Pyramid of Pain

David J. Bianco's pyramid of pain illustrates how much pain is caused to an adversary if their malicious actions are hindered by defenders blocking various indicators.

Indicators at the bottom of the pyramid are trivial for an adversary to replace, which is why IOCs like hashes and IP addresses tend to be very short lived. The indicator types close to the pyramid’s base are also the ones that typically are shared in threat intel feeds.

It would be nice to detect adversaries with indicators higher up in David’s pyramid of pain, but it is often difficult to craft reliable detection mechanisms for such indicators. The simple indicators at the bottom, like domains, IPs and hashes, are on the other hand very exact and practical for us defenders to work with. So in this sense the pyramid of pain applies to defenders as well, where indicators at the bottom are trivial to use and the complexity increases as we go further up. In this sense the Pyramid of Pain can also be viewed as the “Pyramid of Detection Complexity”.

Chasing Ghosts

Many IOCs are “dead” even before you get them. This IOC delay is particularly noticeable when looking at writeups of malware and botnets published by security researchers, in which the IPs and domain names shared in their IOC lists often haven’t been used for several weeks by the time the report gets published. It’s understandable that it takes time to reverse engineer a new piece of malware, compose a blog post and to get the writeup approved for publishing. Nevertheless, those old IOCs often get picked up, redistributed, and used as if they were fresh indicators. Recorded Future observed a 33-day average lead time between when their scans found a C2 server and when it is reported in other sources. Thirty-three days! Only a very small fraction of those C2 servers can be expected to still be active by the time those IOCs are shared by various threat intel providers. All the other C2 servers are dead indicators, or “Ghost IOCs” as I like to call them. Attempting to detect such Ghost IOCs in live network traffic is a waste of resources.

IOC Costs

Most network intrusion detection systems (IDS) only support a certain number of active rules or signatures, which effectively limits the number of IOCs you can look for. Other products charge the user based on the number of monitored IOCs. As an example, Tostes et al.’s paper covering the shelf life of an IOC says that Azure Sentinel Threat Intelligence charges $2.46 per ingested GB. This type of direct cost can then be compared to the cost of not alerting on a known malicious IOC that has timed out. Simplified comparisons like this typically result in poor and misleading guidance to keep using IOCs for much longer than necessary, often hundreds of days or even perpetually.

One important factor that is missing in such simplified reasoning is the cost for false positive alerts, which increases significantly when monitoring for ghost IOCs. An IP address that is being used as a botnet C2 server one week might be running a totally legitimate service the next week. The risk for false positives is smaller for domain names compared to IP addresses, but hacked websites is one example where domain names often cause false positive alerts as well. One common cause for such domain IOC false positives is the frequent misuse of hacked websites for malware distribution. Such illicit use is often detected and rectified within a couple of days, in particular when this happens to a website belonging to a medium to large sized company or organization. Alerting on DNS based IOCs for a long time after last confirmed sighting therefore also increases the risk for false positives.

The cost of false positives is difficult to estimate, as it involves the time analysts spend in vain trying to verify if a particular alert was a false positive or not. Too many false positives can also cause alert fatigue or alarm burnout, much in the same way as in Aesop’s ancient fable about the boy who cried wolf.

This implies that monitoring for too many old IOCs actually increases the risk of real sightings of malicious indicators being missed or overlooked due to alert fatigue. This line of thinking might seem contradictory and is often overlooked in research related to the shelf life of indicators. I would personally prefer to use an IOC scoring model that aims to reduce the number of false positives rather than using one that attempts to minimize the direct cost of IOC monitoring.

Pruning old IOCs

RFC 9424 states that “IOCs should be removed from detection at the end of their life to reduce the likelihood of false positives”. But how do we know if an IOC has reached end of life?

I’ve previously mentioned that researchers have found that most C2 servers are used for 5 days or less. The optimal number of days to monitor for an IOC depends on several factors, but in general we’re talking about a couple of weeks since last sighting for an IP address and maybe a little longer for domain names. The obvious exception here is DGA and RDGA domains, which typically have a lifetime of just 24 hours.

The research paper Taxonomy driven indicator scoring in MISP threat intelligence platforms introduces an interesting concept, where a score is calculated for each IOC based on factors like confidence, age and decay rate. The IOC can be considered dead or expired when the score reaches zero or if it goes below a specified threshold. The following graph from the MISP paper shows an example of how the score for an IP address IOC could decay over time.

Image: Figure 8 from Taxonomy driven indicator scoring in MISP threat intelligence platforms

Recommendations

When publishing IOCs, make sure to also include a date for when it was last confirmed to be active, aka “last seen”.
Ask your threat intel vendor if they can provide a last seen date for each of their indicators, or if they have some other way to determine the freshness of their indicators.
Ensure that the IOCs you monitor for are pruned based on age or freshness to reduce the risk (and cost) for false positives.
Prioritize long lived IOCs over short lived ones, for example by striving to use indicators higher up in the pyramid of pain, but only when this can be done without increasing the false positive rate.

Online Network Forensics Class

Erik Hjelmvik — Mon, 20 Oct 2025 05:30:00 GMT

I will teach a live online network forensics training on February 23-26. The full title of the class is Network Forensics for Incident Response, where we will analyze PCAP files containing network traffic from hackers and malware.

The training is split into four interactive sessions running from 13:00 to 17:00 CET (7am to 11am EDT), so that you have the other half of the day free to either practice what you learned in class or catch up with your normal job routine. The number of attendees is limited in order to provide a good environment for taking questions. A maximum of 15 attendees will be accepted. The registration will be closed once we reach this attendee limit.

📅 Dates: February 23-26 (4 days)
⏲️ Time: 13:00 to 17:00 CET (7am to 11am EDT)
💸 Price: € 920 EUR per student (828 EUR if registering before January 31)

The target audience is blue teams, incident responders and SOC analysts. The training has also been greatly appreciated by law enforcement digital forensics investigators who have taken it in the past.

Training Content

We will analyze a 14 GB PCAP data set captured on an Internet connected network with multiple clients, an AD server, a web server, an android tablet and some embedded devices. As you’ve probably guessed, the capture files contain traffic from multiple intrusions by various attackers, including APT style attackers and botnet operators. The initial attack vectors are using techniques like exploitation of web vulnerabilities, spear phishing, a supply chain attack and a man-on-the-side attack! In this training you'll get hands-on experience analyzing PCAP files containing C2 and backdoor protocols, such as Cobalt Strike, TrickBot, njRAT and Meterpreter.

See our training page for more info about the “Network Forensics for Incident Response” class.

To sign up for the class, simply send an email to sales@netresec.com with your name and invoice address. We will then send you a PayPal payment link that you can use to complete your training registration.

Hope to see you there!

Cheers,
Erik Hjelmvik
Creator of NetworkMiner and founder of Netresec

Gh0stKCP Protocol

Erik Hjelmvik — Wed, 24 Sep 2025 09:40:00 GMT

Gh0stKCP is a transport protocol based on KCP, which runs on top of UDP. Gh0stKCP has been used to carry command-and-control (C2) traffic by malware families such as PseudoManuscrypt and ValleyRAT/Winos4.0.

@Jane_0sint recently tweeted about ValleyRAT using a new UDP based C2 protocol. I wanted to take a closer look at the protocol, so I downloaded the PCAP from any.run and opened it with CapLoader. To my surprise CapLoader claimed that the C2 traffic was using a known protocol called “KCP”.

The protocol detection feature in CapLoader compares traffic in TCP and UDP sessions to statistical models of known protocols. This means that no protocol specification or RFC is required to identify a protocol. All that is needed is some example traffic to build a protocol model from (see this XenoRAT detection video for a demonstration of this feature). In this case CapLoader’s KCP protocol model was built from UDP based C2 traffic from PseudoManuscrypt, which was reported to have been using KCP.

What is KCP?

KCP is a UDP based protocol designed as a low-latency alternative to TCP. The protocol was created by Lin Wei in the early 2010s, primarily to transport p2p voice chat audio in games. The protocol is, however, very generic and can be used to transport basically any type of data. The KCP protocol specification includes the following packet structure:

The first field “conv” is a 32 bit (4 byte) unique ID for a KCP session. This conversation ID is used to uniquely identify a connection and will remain constant throughout the connection. KCP doesn’t include any handshake mechanism for establishing new sessions, which means that KCP endpoints typically start transmitting payload data already in the first KCP packet.

The Gh0stKcp Protocol

The UDP based KCP C2 protocol used by PseudoManuscrypt as well as the ValleyRAT C2 traffic that CapLoader reported being “KCP” both deviated from the original KCP specification in several ways. For instance, KCP packets have a 24 byte header, which means that packets shorter than 24 bytes can’t be KCP. In fact, the KCP source code actually ignores UDP packets that carry less than 24 bytes of payload. Yet, both the PseudoManuscrypt and ValleyRAT UDP C2 traffic initially transmit several 12-byte packets.

Image:Flow transcript of Gh0stKCP traffic in CapLoader

These 12-byte Gh0stKCP handshake packets are generated by an open source library called HP-Socket, which includes a custom Automatic Repeat reQuest (ARQ) handshake mechanism.

The following behavior can be deduced by examining UDP traffic from Valley RAT or by analyzing the UDP handshake mechanism in HP-Socket's ArqHelper.h.

The client (bot) starts by sending an empty UDP packet to the C2 server, followed by a UDP packet carrying a 12 byte payload structured like this:

        4f bb 01 00 xx xx xx xx 00 00 00 00
      

The first four bytes can be decoded as follows:

4f bb = Magic bytes
01 = Handshake command
00 = Handshake is not completed

The “xx” bytes represent a KCP conversation ID (conv) proposed by the bot. This initial handshake packet can easily be detected and alerted on with the following Suricata IDS signature:

        alert udp $HOME_NET any -> $EXTERNAL_NET any (msg:"Gh0stKCP handshake"; dsize:12; content:"|4f bb 01 00|"; offset:0; depth:4; content:"|00 00 00 00|"; within:8; distance:4; classtype:trojan-activity; reference:url,https://netresec.com/?b=259a5af; sid:1471101; rev:1;)
      

The C2 server also transmits a UDP packet containing a 12 byte handshake using the exact same structure as the client. However, the C2 server proposes a 32 bit conversation ID of its own. In “normal” KCP implementations the client and server agree on a single shared conversation ID, but Gh0stKCP actually uses one separate ID for each direction. This allows the server to transmit its handshake packet without having seen the client’s handshake.

        4f bb 01 00 yy yy yy yy 00 00 00 00
      

The “yy” bytes represent the C2 server’s 32-bit conversation ID (conv).

The communicating parties frequently re-transmit this initial handshake packet until they have received a handshake from the other end.

Upon receiving the other end’s handshake both the bot and C2 server acknowledge the other end’s conversation ID with a UDP packet carrying the following 12 byte payload:

        4f bb 01 00 xx xx xx xx yy yy yy yy
      

Where “xx” is the sender’s conversation ID and “yy” is the other end’s conversation ID. After having received the other end’s acknowledgment packet both parties additionally transmit a final ack packet, indicating that the handshake is completed and they will start communicating using KCP. This final ack packet is identical to the previous one, except the fourth byte (handshake complete flag) has changed from 0x00 to 0x01.

        4f bb 01 01 xx xx xx xx yy yy yy yy
      

From this point on Gh0stKCP communicates using the KCP protocol, with the exception that each end transmits packets using their own conversation ID rather than a common ID. The KCP traffic that follows can therefore be parsed and inspected in Wireshark with help of a KCP Lua parser, such as CandyMi’s kcp_dissector.lua.

Image: KCP traffic from ValleyRAT sample any.run in Wireshark

Finally, the Gh0stKCP session is terminated by sending a UDP packet containing the following hard coded 16 bytes:

        be b6 1f eb da 52 46 ba 92 33 59 db bf e6 c8 e4
      

This unique byte sequence is defined in HP-Socket as s_szUdpCloseNotify, which can be detected with the following Suricata IDS signature:

        alert udp any any -> any any (msg:"Gh0stKCP close"; dsize:16; content:"|be b6 1f eb da 52 46 ba 92 33 59 db bf e6 c8 e4|"; offset:0; depth:16; classtype:trojan-activity; reference:url,https://netresec.com/?b=259a5af; sid:1471102; rev:1;)
      

Hole Punching in NAT Firewalls

The elaborate handshake procedure used by Gh0stKCP introduces a significant delay before the C2 session is established. The handshake takes up to 500ms to complete, which is much slower than a normal TCP 3-way handshake. KCP is typically used because of its low-latency properties, but the handshake routine ruins any chance for quick establishment of Gh0stKCP sessions.

The intricate ARQ handshake routine does, however, allow for hole punching in firewalls, aka “NAT traversal”, which enables the protocol to be used for peer-to-peer communication. This p2p-enabling property could potentially be used to relay C2 communication through one or several bots, even if those bots are behind separate NAT firewalls.

Detecting Gh0stKCP with Snort and YARA

CapLoader can detect when the KCP protocol is used. However, only a few security analysts have a CapLoader license. We have therefore decided to release Surucata signatures and a YARA rule that can be used to detect Gh0stKCP.

The Suricata signatures included in this blog post can also be downloaded from here:
https://github.com/Netresec/Suricata/blob/main/netresec.rules

Our Gh0stKCP YARA rule is based on Steve Miller’s “RareEquities_KCP” rule, from Mandiant’s 2020 blog post APT41 Initiates Global Intrusion Campaign Using Multiple Exploits. Steve’s original YARA rule provides generic detection of software that uses the original KCP library. We’ve extended that rule to also look for HP-Socket’s characteristic 16-byte close command.

https://github.com/Netresec/YARA/blob/main/Gh0stKCP.yar

IOC List

Many of the IOCs in the list below are old, which is why you might not want to use them for alerting. They are included here primarily for researchers and analysts who wish to perform retrohunting to discover malware samples that use GhostKCP.

2021 (PseudoManuscrypt)

UDP 34.64.183.91:53
UDP 34.97.69.225:53
UDP 160.16.200.77:53
UDP 167.179.89.78:53
UDP 185.116.193.219:53
UDP 198.13.62.186:53
UDP email.yg9[.]me:53
UDP facebook.websmails[.]com:53
UDP google.vrthcobj[.]com:53

2022 (PseudoManuscrypt)

UDP 34.142.181.181:53

2025 (ValleyRAT / Winos4.0)

UDP 27.124.3.234:8443
UDP 43.133.39.217:80
UDP al17[.]tk:80
UDP xiaoxiao.fenghua678.eu[.]cc:8443

Attribution

Use of ValleyRAT is often attributed to the APT group Silver Fox (银狐), but ValleyRAT and Gh0stKCP could be used by other threat actors as well.