NETRESEC Network Security Blog - Tag : NSM

rss Google News

OT Networks Still Need Monitoring

CERT Polska recently published a follow-up report detailing the hack of a Polish combined heat and power (CHP) plant in December 2025.

CERT Polska’s report concludes with several important recommendations, including protecting OT systems through network segmentation and monitoring traffic entering and leaving OT networks. It has now been more than 15 years since I first publicly advocated almost exactly these same two recommendations in my blog post Monitor Those Control System Networks.

One might get the impression that nothing has changed during those 15 years, but I can attest that many OT systems now have effective perimeter protection. Operators of critical infrastructure are also beginning to embrace the concept of network security monitoring for OT systems.

Unfortunately, it appears that the hacked CHP plant in Poland did not have sufficient perimeter protection or network security monitoring in place. The apparent lack of monitoring and logging also left CERT Polska with very limited forensic data. As the report states, “Due to the lack of logs, our investigation relied on the development and testing of hypotheses.” Despite these limitations, I am very impressed by the level of technical detail that CERT Polska were able to reconstruct during their investigation of the CHP hack.

Attack Path

As CERT Polska outline in their report, the attackers’ initial access vector was an Internet-facing FortiGate VPN at a wind farm. From the VPN device, they pivoted via a Teltonika cellular 5G router into a WAGO PLC, which ultimately gave them access to the control system network of a CHP plant.

Attack path from the Internet to the CHP network

Image: Attack path from the Internet to the CHP network

The lack of perimeter protection, which would otherwise have prevented direct connections between different remote sites, gave the attackers access to the PLCs and other industrial equipment that directly controlled the physical process at the CHP plant.

With that type of access, attackers do not need to exploit a vulnerability. They can simply issue “normal” commands over the OT network to shut down the process at the plant. In this specific case, the attackers performed the following operations, apparently in an attempt to cause maximum disruption:

  • Switched multiple Siemens S7 PLCs to STOP mode
  • Enabled password protection on Siemens S7 PLCs to prevent operators from switching them back to RUN mode
  • Changed the configurations of several industrial serial device servers and network switches, making them inaccessible from the network

Siemens S7-1500 PLC in STOP mode, from CERT Polska’s report

Image: Siemens S7-1500 PLC in STOP mode, from CERT Polska’s report

As a result of the attack, a steam turbine and the system used to produce process water in the CHP plant were both shut down on December 29.

Network Security Monitoring

Better perimeter protection might have prevented the initial access path used against the Polish CHP plant. However, it is not always easy for asset owners and operators to identify every boundary around an OT environment or segment it without affecting operations. This is where network security monitoring plays an important role.

OT networks are often well suited to passive monitoring. Most industrial protocols are unencrypted, communication patterns are more deterministic than those in enterprise networks, and traffic volumes are often modest. By monitoring OT network traffic and alerting on suspicious or anomalous behavior and known attack techniques, defenders may be able to detect an intrusion early enough to investigate, contain, and stop it before destructive actions are carried out.

Examples of useful detections include:

  • Reconnaissance activity, such as TCP SYN scans
  • Attempts to access canary or honeypot systems that normal operations should not touch
  • Connections from unexpected systems to ICS-specific ports, such as TCP ports 102, 502, 2404, 5094, 20000, 44818 and 47808
  • Potentially dangerous protocol commands, such as putting a PLC into STOP mode, changing its operating mode, downloading a new program, or modifying its configuration outside a scheduled maintenance window
  • New communication paths, such as traffic between IP address pairs that have not previously communicated

The Polish incident illustrates the value of detecting reconnaissance activity, not just the final destructive commands. The disruptive actions occurred on December 29, but CERT Polska uncovered malicious activity as early as December 18.

Log from the Teltonika RUTX50 cellular router

Image: Log from the Teltonika RUTX50 cellular router

This suggests that the attackers had access to the environment more than 10 days before the destructive actions. This period is known as the dwell time: the time between an attacker gaining access to an environment and being detected or taking disruptive action.

Had the intrusion been detected early, this dwell time would have provided multiple opportunities for defenders to contain it before the attackers carried out their disruptive actions.

Long dwell times are common in attacks against OT systems. Attackers may spend weeks or months learning about the environment, identifying important assets, and determining how to disrupt the physical process. In some cases, access to critical infrastructure is established as part of pre-positioning, where a state-sponsored threat actor gains and maintains access to an OT environment without immediately causing disruption, preserving the ability to deliver a destructive payload at a later point. This makes early detection especially important, even when an intrusion does not initially appear to be affecting plant operations.

Captured network traffic, preferably stored as PCAP files, is one of the most valuable sources of evidence when analyzing a suspected attack against an OT system. It can help investigators reconstruct the attacker’s activity, validate alerts, and identify affected systems. If the captured traffic is stored on a system that is not accessible from the OT network, the risk of an attacker tampering with the evidence is reduced.

This is one reason we have been teaching Network Forensics for Industrial Control Systems for more than 10 years. Feel free to reach out if you want to learn more about our network forensics training.

Siemens S7 Advisory

On a related note, the NSA, CISA, FBI, DOE, and EPA published a joint cybersecurity advisory titled Defending Against an Active Threat to Siemens S7 Series PLCs on August 19 (PDF). In the advisory, the authoring agencies called for mitigation measures such as verifying network segmentation and monitoring network traffic to detect and alert on anomalous or malicious activity. These recommendations are very much in line with what CERT Polska stated in their report, as well as with what I have been recommending since 2011.

The question isn't whether we should implement these recommendations, 15+ years of evidence answers that. The question is what it will take to make them happen.

Posted by Erik Hjelmvik on Monday, 31 August 2026 11:50:00 (UTC/GMT)

Tags: #Netresec #NSM #ICS #ASCII-art

Short URL: https://netresec.com/?b=2686c28


Detecting Cobalt Strike and Hancitor traffic in PCAP

This video shows how Cobalt Strike and Hancitor C2 traffic can be detected using CapLoader.

I bet you’re going:

😱 OMG he’s analyzing Windows malware on a Windows PC!!!

Relax, I know what I’m doing. I have also taken the precaution of analyzing the PCAP file in a Windows Sandbox, which just takes a couple of seconds to deploy and run.

The capture file I’m looking at is called “2021-05-13-Hancitor-traffic-with-Ficker-Stealer-and-Cobalt-Strike.pcap” and can be downloaded from here: https://malware-traffic-analysis.net/2021/05/13/index.html

CapLoader’s Services tab shows us that the connections to TCP 80 and 443 on 103.207.42.11 are very periodic, with a detected period of exactly 1 minute. CapLoader successfully identifies the protocols for these two services as Cobalt Strike over HTTP and Cobalt Strike over SSL, respectively. The third service in this list is also very periodic, that’s the Hancitor trojan beaconing to its C2 server every two minutes.

Services tab in CapLoader

CapLoader uses machine learning to identify the application layer protocol based on the behavior of the traffic, not the port number. This means that there can be false positives, i.e. the protocol classification that CapLoader gives a flow or service might be wrong. It is more common, however, for CapLoader to yield false negatives, which means that it can't identify the protocol. The detection of Cobalt Strike inside of HTTP and SSL traffic was recently introduced in the latest 1.9 release of CapLoader. I expected this feature to detect Cobalt Strike traffic in HTTP, but I was delighted to see that CapLoader often detects even TLS encrypted Cobalt Strike beaconing with really good precision!

As shown in the video, the Cobalt Strike beacon config can easily be extracted from the network traffic using NetworkMiner and Didier Stevens’ 1768 K python script.

The output from Didier’s 7868.py tool looks something like this:

0x0001 payload type 0 windows-beacon_http-reverse_http
0x0002 port 80
0x0003 sleeptime 60000
0x0004 maxgetsize 1048576
0x0005 jitter 0
0x0007 publickey 30819f30[...]
0x0008 server,get-uri '103.207.42.11,/ca'
[...]

As you can see, it uses HTTP for transport with a “sleeptime” of 1 minute (60000 ms) and 0% jitter. This means that a new connection will be made to the Cobalt Strike C2 server every minute. The fact that there was no jitter is what gives this service such a high value in CapLoader’s “Periodicity” column.

Network Forensics Training

Are you interested in learning more about how to analyze network traffic from Cobalt Strike and other backdoors, malware and hacker tools? Then take a look at the live online network forensics classes I will be teaching in September and October!

Posted by Erik Hjelmvik on Monday, 31 May 2021 08:30:00 (UTC/GMT)

Tags: #Netresec #Cobalt Strike #CobaltStrike #periodicity #Protocol Identification #PIPI #CapLoader #1768.py #Windows Sandbox #PCAP #NSM #video #videotutorial

Short URL: https://netresec.com/?b=21536fc


Examining Malware Redirects with NetworkMiner Professional

This network forensics video tutorial covers analysis of a malware redirect chain, where a PC is infected through the RIG Exploit Kit. A PCAP file, from Brad Duncan's malware-traffic-analysis.net website, is opened in NetworkMiner Professional in order to follow a redirect chain via a couple of hacked websites before delivering malware to the PC.

Resources
https://www.malware-traffic-analysis.net/2014/11/16/index.html
Meadgive on VirusTotal
CVE-2014-0569 Flash Exploit on VirusTotal
CVE-2012-0507 Java Exploit on VirusTotal
NetworkMiner Professional

IOCs
www.ciniholland.nl
24corp-shop.com
stand.trustandprobaterealty.com
793b698a82d999f1eb75525d050ebe16
f8482f5c4632fe237d062451b42393498a8d628ed9dee27147251f484e837a42
7b3baa7d6bb3720f369219789e38d6ab
e2e33b802a0d939d07bd8291f23484c2f68ccc33dc0655eb4493e5d3aebc0747
1e34fdebbf655cebea78b45e43520ddf
178be0ed83a7a9020121dee1c305fd6ca3b74d15836835cfb1684da0b44190d3

Check out our series of network forensic video tutorials for more tips and tricks on how to analyze captured network traffic.

Posted by Erik Hjelmvik on Monday, 26 February 2018 11:19:00 (UTC/GMT)

Tags: #Netresec #Professional #NetworkMiner #NetworkMiner Professional #malware_traffic #malware #NSM #PCAP #videotutorial #video #tutorial

Short URL: https://netresec.com/?b=1829909


Zyklon Malware Network Forensics Video Tutorial

We are releasing a series of network forensics video tutorials throughout the next few weeks. First up is this analysis of a PCAP file containing network traffic from the "Zyklon H.T.T.P." malware.

Analyzing a Zyklon Trojan with Suricata and NetworkMiner

Resources
https://www.malware-traffic-analysis.net/2017/07/22/index.html
https://github.com/Security-Onion-Solutions/security-onion
https://www.arbornetworks.com/blog/asert/wp-content/uploads/2017/05/zyklon_season.pdf
http://doc.emergingthreats.net/2017930

IOCs
service.tellepizza.com
104.18.40.172
104.18.41.172
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3pre) Gecko/20070302 BonEcho/2.0.0.3pre
gate.php
.onion
98:1F:D2:FF:DC:16:B2:30:1F:11:70:82:3D:2E:A5:DC
65:8A:5C:76:98:A9:1D:66:B4:CB:9D:43:5C:DE:AD:22:38:37:F3:9C
E2:50:35:81:9F:D5:30:E1:CE:09:5D:9F:64:75:15:0F:91:16:12:02:2F:AF:DE:08:4A:A3:5F:E6:5B:88:37:D6

Posted by Erik Hjelmvik on Monday, 05 February 2018 07:30:00 (UTC/GMT)

Tags: #Netresec #PCAP #Trojan #video #tutorial #videotutorial #NetworkMiner #SecurityOnion #Suricata #malware #network #forensics #NSM #malware_traffic

Short URL: https://netresec.com/?b=182b4ac


Enable file extraction from PCAP with NetworkMiner in six steps

NetworkMiner can reassemble files transferred over protocols such as HTTP, FTP, TFTP, SMB, SMB2, SMTP, POP3 and IMAP simply by reading a PCAP file. NetworkMiner stores the extracted files in a directory called “AssembledFiles” inside of the NetworkMiner directory.

NetworkMiner 2.1.1 with Files tab open.
Files extracted by NetworkMiner from the DFRWS 2008 challenge file suspect.pcap

NetworkMiner is a portable tool that is delivered as a zip file. The tool doesn’t require any installation, you simply just extract the zip file to your PC. We don’t provide any official guidance regarding where to place NetworkMiner, users are free to place it wherever they find it most fitting. Some put the tool on the Desktop or in “My Documents” while others prefer to put it in “C:\Program Files”. However, please note that normal users usually don’t have write permissions to sub-directories of %programfiles%, which will prevent NetworkMiner from performing file reassembly.

Unfortunately, previous versions of NetworkMiner didn’t alert the user when it failed to write to the AssembledFiles directory. This means that the tool would silently fail to extract any files from a PCAP file. This behavior has been changed with the release of NetworkMiner 2.1. Now the user gets a windows titled “Insufficient Write Permissions” with a text like this:

User is unauthorized to access the following file:
C:\Program Files\NetworkMiner_2-1-1\AssembledFiles\cache\FILENAME

File(s) will not be extracted!

Follow these steps to set adequate write permissions to the AssembledFiles directory in Windows:

  1. Open the Properties window for the AssembledFiles directory
  2. Open the “Security” tab
  3. Press “Edit” to change permissions
  4. Select the user who will be running NetworkMiner
  5. Check the “Allow”checkbox for Write permissions
  6. Press the OK button

Press Edit to change permissions for AssembledFiles folder

If you are running NetworkMiner under macOS (OS X) or Linux, then please make sure to follow our installation instructions, which include this command:

sudo chmod -R go+w AssembledFiles/

Once you have set up the appropriate write permissions you should be able to start NeworkMiner and open a PCAP file in order to have the tool automatically extract files from the captured network traffic.

Posted by Erik Hjelmvik on Friday, 03 March 2017 09:44:00 (UTC/GMT)

Tags: #NetworkMiner #PCAP #NSM

Short URL: https://netresec.com/?b=173588e


10 Years of NetworkMiner

I released the first version of NetworkMiner on February 16, 2007, which is exactly 10 years ago today.

NetworkMiner 0.79 in Windows XP

One of the main uses of NetworkMiner today is to reassemble file transfers from PCAP files and save the extracted files to disk. However, as you can see in the screenshot above, the early versions of NetworkMiner didn’t even have a Files tab. In fact, the task that NetworkMiner was originally designed for was simply to provide an inventory of the hosts communicating on a network.

How it all started

So, why did I start designing a passive asset detection system when I could just as well have used a port scanner like Nmap to fingerprint the devices on a network? Well, I was working with IT security at the R&D department of a major European energy company at the time. As part of my job I occasionally performed IT security audits of power plants. During these audits I typically wanted to ensure that there were no rouge or unknown devices on the network. The normal way of verifying this would be to perform an Nmap scan of the network, but that wasn’t an option for me since I was dealing with live industrial control system networks. I knew from personal experience that a network scan could cause some of the industrial control system devices to drop their network connections or even crash, so active scanning wasn’t a viable option. Instead I chose to setup a SPAN port at a central point of the network, or even install a network TAP, and then capture network traffic to a PCAP file during a few hours. I found the PCAP files being a great source, not only for identifying the hosts present at a network, but also in order to discover misconfigured devices. However, I wasn’t really happy with the tools available for visualizing the devices on the network, which is why I stated developing NetworkMiner in my spare time.

Network Forensics

As I continued improving NetworkMiner I pretty soon ended up writing my own TCP reassembly engine as well as parsers for HTTP and the CIFS protocol (a.k.a SMB). With these protocols in place I was able to extract files downloaded through HTTP or SMB to disk with NetworkMiner, which turned out to be a killer feature.

Monthly downloads of NetworkMiner from SourceForge
Image: Monthly downloads of NetworkMiner from SourceForge

With the ability to extract file transfers from PCAP files NetworkMiner steadily gained popularity as a valuable tool in the field of network forensics, which motivated me to make the tool even better. Throughout these past 10 years I have single-handedly implemented over 60 protocols in NetworkMiner, which has been a great learning experience for me.

NetworkMiner Milestones

Looking Forward

People sometimes ask me what I’m planning to add to the next version of NetworkMiner. To be honest; I never really know. In fact, I’ve realized that those with the best ideas for features or protocols to add to NetworkMiner are those who use NetworkMiner as part of their jobs, such as incident responders and digital forensics experts across the globe.

I therefore highly value feedback from users, so if you have requests for new features to be added to the next version, then please feel free to reach out and let me know!

Posted by Erik Hjelmvik on Thursday, 16 February 2017 09:11:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #NSM #ICS

Short URL: https://netresec.com/?b=17218c7


PacketCache lets you Go Back in Time

PacketCache logo

Have you ever wanted to go back in time to get a PCAP of something strange that just happened on a PC?
I sure have, many times, which is why we are now releasing a new tool called PacketCache. PacketCache maintains a hive of the most important and recent packets, so that they can be retrieved later on, if there is a need.

Network forensics and incident response is performed post-event, but requires that packet have already been captured during the event to be analyzed. Starting a network sniffer after a suspected intrusion might provide useful insight on what the intruders are up to, but it is much better to be able to go back in time to observe how they gained access to the network and what they did prior to being detected. Many companies and organizations combat this problem by setting up one or several solutions for centralized network packet capturing. These sniffers are typically installed at choke-points on the network, such as in-line with a firewall. However, this prevents the sniffers from capturing network traffic going between hosts on the same local network. Intruders can therefore often perform lateral movement on a compromised network without risk getting their steps captured by a packet sniffer.

Logo for Back to the Future series logo - public domain

USB broadband modem, credit: Game Gavel (cc-by-sa-3.0)
Image by Game Gavel
We're now trying to improve the situation for the defenders by releasing PacketCache, which is a free (Creative Commons licensed) Windows service that is designed to continuously monitor the network interfaces of a computer and store the captured packets in memory (RAM). PacketCache monitors all IPv4 interfaces, not just the one connected to the corporate network. This way traffic will be captured even on public WiFi networks and Internet connections provided through USB broadband modems (3G/4G).

By default PacketCache reserves 1% of a computer's total physical memory for storing packets. A computer with 4 GB of RAM will thereby allow up to 40 MB of packets to be kept in memory. This might not seem like much, but PacketCache relies on a clever technique that allows it to store only the most important packets. With this technique just 40 MB of storage can be enough to store several days worth of “important” packets.

The “clever technique” we refer to is actually a simple way of removing packets from TCP and UDP sessions as they get older. This way recent communication can be retained in full, while older data us truncated at the end (i.e. only the last packets are removed from a session).

PacketCache services in services.msc

To download PacketCache or learn more about this new tool, please visit the official PacketCache page:
https://www.netresec.com/?page=PacketCache

PCAP or it didn't happen!

Posted by Erik Hjelmvik on Wednesday, 28 September 2016 11:45:00 (UTC/GMT)

Tags: #PacketCache #PCAP #NSM #forensics #Windows #sniffer #memory #DFIR

Short URL: https://netresec.com/?b=169d0d2