CISA mixup of IOC domains

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)

Posted by Erik Hjelmvik on Thursday, 26 February 2026 09:35:00 (UTC/GMT)

Tags: #IOC​

njRAT runs MassLogger

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

Posted by Erik Hjelmvik on Monday, 02 February 2026 19:39:00 (UTC/GMT)

Tags: #njRAT​ #NetworkMiner Professional​ #malware-traffic-analysis.net​

Decoding malware C2 with CyberChef

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:

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

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

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.

Posted by Erik Hjelmvik on Tuesday, 20 January 2026 12:10:00 (UTC/GMT)

Tags: #Netresec​ #CyberChef​ #XOR​ #PCAP​ #CapLoader​ #PowerShell​ #Video​ #videotutorial​

Latrodectus BackConnect

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:

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.

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!

Posted by Erik Hjelmvik on Wednesday, 10 December 2025 13:00:00 (UTC/GMT)

Tags: #BackConnect​ #IcedID​ #VNC​ #Keyhole​ #NetworkMiner​

NetworkMiner 3.1 Released

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.

Posted by Erik Hjelmvik on Monday, 01 December 2025 08:20:00 (UTC/GMT)

Tags: #NetworkMiner​ #NetworkMiner Professional​ #njRAT​

Optimizing IOC Retention Time

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.

Posted by Erik Hjelmvik on Thursday, 06 November 2025 12:05:00 (UTC/GMT)

Tags: #IOC​ #IDS​ #ASCII-art​

Online Network Forensics Class

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

Posted by Erik Hjelmvik on Monday, 20 October 2025 05:30:00 (UTC/GMT)

Tags: #Training​ #network forensics​ #PCAP​