NetSim Cyber Q&A
Power-system protocols · Attack library · OT detection testing
Questions on protocol-aware cyber attack simulation for power-system communication networks:
what the Threat Agent does to a live protocol stream, which attacks exist for IEEE C37.118,
IEC 61850, Modbus TCP, DNP3 and IEC 60870-5-104, how a testbed is assembled with or without
hardware, and how the results are used to validate detection. Q1 to Q5 cover scope and
positioning. Q6 to Q29 cover the product in detail.
On this page
Twenty-nine questions in five parts, from what the tool is to what it does
not do.
Part 1: Scope and positioning
What the platform is, what it deliberately leaves to other tools, and who
uses it.
Q1. What is NetSim Cyber?
NetSim Cyber is a platform for modelling, simulating and analysing cyber attacks on
power-system communication networks. It is placed between a source device and a destination
device, intercepts the protocol traffic flowing between them, applies configured attack
logic to specific protocol fields, and forwards the result.
Supported traffic includes IEEE C37.118 synchrophasor, IEC 61850 GOOSE, R-GOOSE, MMS and
Sampled Values, Modbus TCP, DNP3, IEC 60870-5-104, and custom TCP/IP protocols. The source
may be a PMU, IED, RTU, PLC, relay or simulator; the destination may be a PDC, SCADA master,
HMI, subscriber or control application.
Q2. What is a protocol-aware cyber attack simulator, and why
does it matter for OT?
A protocol-aware simulator parses the structure of the industrial protocol instead of
treating packets as opaque byte streams, so an attack can target a field that carries
physical meaning: a phasor magnitude, a ROCOF value, a Modbus holding register, a GOOSE
stNum.
This matters because the most damaging grid attacks do not break communication. They keep
the session alive and change the values inside valid frames. From the receiver's point of
view the link is healthy and the data is wrong, and that is a far harder case for monitoring
to catch than a dropped session.
Q3. Does NetSim Cyber perform penetration testing, exploit
devices, or deploy malware?
No. NetSim Cyber works on an assume-breach premise: it starts once the adversary already has
a position on the OT network. Gaining that access, through phishing, IT compromise or an
insider, is out of scope and remains with your IT security and red teams.
What NetSim Cyber models is what an adversary does after that point, and the effect of it on
the power system. All of it runs in a controlled laboratory environment.
Q4. Does NetSim Cyber simulate the power system itself?
NetSim Cyber ships with built-in protocol simulators that generate and receive
standards-conformant traffic for every supported protocol, so a complete attack testbed can
be built in software. Those simulators are measurement generators: the values they carry
come from configurable value and waveform models, including constant and sine profiles and
physics-informed frequency, voltage and load-flow angle behaviour, rather than from a
load-flow or electromagnetic-transient solution of an electrical network model.
That is enough to develop an attack, validate protocol parsing, generate datasets, and test
whether a receiving application reacts. When the study needs full grid dynamics, pair
NetSim Cyber with a real-time simulator such as RTDS, OPAL-RT or Typhoon HIL. The real-time
simulator is the digital twin of the power system; NetSim Cyber is the digital twin of the
communication and cyber layer. Together they form the complete cyber-physical testbed.
Q5. Who uses NetSim Cyber?
- Utilities and national grid operators assessing attack impact on production
infrastructure.
- Protection, SCADA and substation automation engineers validating relay logic and
process-bus integrity.
- OT and ICS cybersecurity teams validating protocol-aware detection and countermeasures.
- Cyber-physical power system researchers and laboratory integrators.
- Defence and critical-infrastructure agencies preparing for cyber-kinetic scenarios.
- Product validation teams testing devices, simulators and protocol implementations.
- Universities and training organisations teaching CPPS security with reproducible
experiments.
Part 2: How it works
The Threat Agent, the deployment modes, and the workflow from an empty
scenario to a live attack.
Q6. What is the Threat Agent?
The Threat Agent is the logical attack node placed in the communication path between source
and destination. It filters traffic by source node, destination node, protocol and port,
intercepts matching packets, parses the protocol, applies the payload or timing
modification, and forwards the frame.
It does not corrupt packets at random. Every modification is driven by the selected
protocol-aware attack model, and traffic outside the configured filter passes through
untouched.
Q7. What happens to CRCs and checksums after a field is
modified?
They are recalculated after mutation. A C37.118 frame keeps its 0xAA sync byte and a valid
CRC-CCITT, a DNP3 frame keeps valid header and block CRCs, and transport checksums are
rebuilt.
The modified packet is therefore indistinguishable from a legitimate one to any receiver
that validates only framing and checksums. That is precisely the condition your detection
layer has to catch, which is why the fidelity matters.
Q8. What deployment modes are available?
Single-system deployment. The source simulator, the Threat Agent and the
destination simulator all run on one PC. This suits attack development, protocol
validation, training, demonstration and dataset generation.
Multiple-system deployment. The source and destination run on separate
machines or on real devices, and the NetSim Cyber PC sits inline in the communication path.
This adds real network interfaces, device delays and system-level timing.
The usual practice is progressive: develop and validate the attack on one machine, then
repeat it distributed against real equipment.
Q9. How is traffic routed through the NetSim Cyber machine in a
distributed setup?
Three methods are documented: manual static routes on the source and destination systems,
automatic configuration through NetSimCyberClient.exe, and a two-NIC gateway in
which the NetSim Cyber PC has IP forwarding enabled and routes between two subnets.
The three-system topology, source on one machine, NetSim Cyber on the second, destination on
the third, is documented with example IP configuration and connectivity verification
steps.
Q10. What does the end-to-end workflow look like?
- Launch NetSim Cyber and open or create a simulation.
- Select the deployment type: traffic local to this system, or traffic passing through it
inline.
- Build the scenario on the grid, adding source and destination nodes with a Threat Agent
between them.
- Configure the Application Traffic Filter with the node pair, protocol and port.
- Select the built-in attacker for that protocol, or import a custom Python attacker.
- Run the simulation, then set the parameters in the attacker interface and start the
attack.
Q11. Can attack parameters be changed while the simulation is
running?
Yes. The attacker interface provides Start Attack, Modify Attack and Stop Attack. Parameters
can be updated live while traffic flows, and stopping the attack restores normal forwarding.
A single run can therefore carry a clean baseline segment, an attack segment, and a recovery
segment, which is what a before-and-after comparison needs.
Q12. Which ports are used in the traffic filter?
| Protocol |
Transport port |
Typical endpoints |
| Modbus TCP | 502 | PLC or RTU to SCADA HMI or master |
| DNP3 | 20000 | Outstation to SCADA master |
| IEC 60870-5-104 | 2404 | Controlled station to master station |
| IEEE C37.118 | 4712 or 1410, as configured | PMU to PDC |
Why it matters: the filter is what confines the attack to
the intended stream and leaves the rest of the laboratory network untouched.
Part 3: Protocols and the attack library
Which standards are covered, what can be manipulated in each, and how to add
an attack of your own.
Q13. Which protocols and standards are supported?
- IEEE C37.118 synchrophasor, 2005 and 2011 profiles, with the 2024 model supported as a
variant.
- IEC 61850 GOOSE, Routed GOOSE, MMS and Sampled Values.
- Modbus TCP.
- DNP3, IEEE 1815.
- IEC 60870-5-104.
- User-defined TCP/IP protocols, through the custom attacker API.
Q14. What is in the attack library?
The library spans signal-level attacks and network or protocol-level attacks, grouped in
five categories: data integrity, timing, availability, replay, and protocol-field
manipulation.
The documented attack types are noise injection, ramp, increment and decrement, pulse or
surge, frequency and ROCOF manipulation, time-synchronisation and timestamp attacks,
replay, fixed delay, PER-based packet drop, speed and bandwidth suppression, packet
manipulation, DoS, virtual SYN flood, real SYN flood and RST flood. Counting the
per-protocol variants exposed in the attacker interfaces, this comes to more than forty
attacks.
The availability attacks are parameterised rather than brute-force: speed in Mbps sets an
effective bandwidth ceiling, fixed delay in milliseconds shifts forwarding time, and packet
error rate sets a drop probability applied per packet.
Q15. How do I test a false data injection attack on a PMU to
PDC synchrophasor stream?
Place the Threat Agent between the PMU, or PMU simulator, and the PDC, filter on the
synchrophasor port, and select the IEEE C37.118 attacker with the matching profile. The
attacker has three tabs.
- Automatic: increment bias, decrement bias, pulse or surge, ramp or
drift, noise or jitter with proportional-range, Gaussian, uniform or spike behaviour,
angle bias, frequency override, whole-second SOC shift, sub-second fine time shift,
and the STAT sync-error, data-modified and config-changed status bits. The 2011 profile
adds FRACSEC time-quality corruption. A packet attack probability applies to eligible
attacks.
- Manual: enable individual phasor rows and enter replacement magnitude
and angle values, with optional frequency and ROCOF overrides.
- Replay: record live phasor values or replay them from a CSV containing
magnitude, angle in degrees, frequency and ROCOF.
Sequencing note: start NetSim Cyber and have the attacker
ready before PMU traffic starts. The first configuration frame is what loads the stream
layout and the phasor list into the attacker, and station and phasor targeting is
unavailable until it has been observed.
Q16. What can be attacked in IEC 61850 GOOSE and Sampled Values
traffic?
GOOSE: stNum, sqNum and
timeAllowedToLive overrides, the simulation flag, and dataset values of
boolean, float and unsigned type, reached through BER tag parsing and
allData field discovery.
Sampled Values: smpCnt and smpSynch overrides and
the seqData payload, including Va, Vb, Vc, Vn and Ia through In, at 80 or 256
samples per period.
The objectives these support are false breaker trip indication, corrupted protection relay
logic, and process-bus integrity testing. The simulation flag matters in its own right,
because it is what distinguishes test traffic from live traffic on a substation bus.
Q17. What can be attacked in Modbus TCP and DNP3?
Modbus TCP: register increment and decrement, ramp drift, jitter,
fixed-value injection, manual override by register address, and coil or discrete bit set,
clear and flip. The attacker parses the MBAP header and rebuilds the response, targeting
function codes FC01 to FC04, while the built-in simulator covers FC01 to FC06, FC15 and
FC16.
DNP3: false data injection into analog inputs, binary inputs and counters,
replay through the interceptor path, unauthorised direct-operate and select-operate control
using CROB objects, link-status reconnaissance and integrity polling, time-skew writes,
enabling or disabling unsolicited responses, cold and warm restart, and DoS flooding.
Framing starts at 0x05 0x64 with header and block CRCs, transport segmentation and object
groups parsed, and both solicited and unsolicited modes supported.
Q18. What can be attacked in IEC 60870-5-104 telecontrol
traffic?
Telemetry value modification, status indication manipulation, replay of valid messages,
delay of telecontrol messages, packet drop, and time-tag manipulation, on the master to
controlled-station link over TCP 2404.
The information objects involved are single-point and double-point indications, measured
values, commands, integrated totals and time-tagged events. The effect to study is on
control-centre visibility and on how commands are interpreted, which is the same ground
Industroyer2 operated on.
Q19. Can I write my own attack for a proprietary or novel
protocol?
Yes, through the custom payload modifier API. You implement a single Python callback:
def modify_payload(ipv4, ipv6, tcp, udp, payload, iopath):
It fires on every packet matching the Application Traffic Filter. Inspect and rewrite the
writable payload buffer in place, return True when you modified it
and False when you did not, and import the file through Import Custom Attacker
in the Select Attack Protocol window. The iopath argument gives access to the
simulation I/O path for logs, configuration files or external attack parameters.
Novel and proprietary attack logic can therefore be modelled without touching the core
engine.
Part 4: Testbed integration
What you connect at each end, and what you need before you can start.
Q20. What are the three ways to run NetSim Cyber?
- Connect a real-time simulator. Wire NetSim Cyber to RTDS, OPAL-RT or
Typhoon HIL. The simulator drives the grid dynamics; NetSim Cyber attacks the traffic in
between.
- Connect physical equipment. Put real protection relays and IEDs, from
vendors such as SEL or Siemens, on the wire, and test how they respond to manipulated
protocol traffic.
- Use the built-in simulators. With neither a simulator nor field devices
available, NetSim Cyber generates the protocol traffic itself and attacks run
standalone.
Across all three, the same question is being answered: does your own intrusion detection and
monitoring catch the attack, before it matters on the live grid?
Q21. Which external simulators and devices does it integrate
with?
Typhoon HIL, OPAL-RT, RTDS, MATLAB and Simulink, SCADA systems, and real PMUs, PDCs, IEDs,
RTUs, PLCs, protection relays, substation gateways and control-centre applications. The
product page additionally lists HYPERSIM, PSCAD, OpenPMU and
openPDC.
In every case the external system is the source or the destination of the protocol traffic,
and NetSim Cyber is the intermediate system that intercepts it.
Q22. What are the built-in simulators, and what are they built
on?
| Protocol |
Source simulator |
Destination simulator |
Open-source framework |
| IEEE C37.118 | PMU simulator | openPDC or PDC subscriber | pyPMU, openPDC |
| IEC 61850 | IED or relay publisher | GOOSE subscriber and analyzer | libiec61850 |
| Modbus TCP | PLC or RTU simulator | SCADA HMI or Modbus master | pymodbus, QModMaster |
| DNP3 | RTU simulator | SCADA master | OpenDNP3 |
| IEC 60870-5-104 | IEC-104 slave | IEC-104 master station | lib60870 |
Why both ends ship: source side and destination side are
both provided, so a complete attack testbed fits on one workstation, with no live grid and
no HIL, PMU or SCADA hardware placed at risk.
Q23. Do I need external hardware to get started, and what are
the software prerequisites?
No hardware is needed. Single-system deployment with the built-in simulators runs on one
Windows PC.
The documented prerequisites are a supported Python runtime with PySide6 and pyqtgraph, the
.NET runtime, administrator privileges for packet interception, and a writable workspace
containing the PythonUserCode folder. The manual includes an installation verification
procedure and a troubleshooting summary for dependency, permission and routing problems.
Part 5: Outcomes and limits
What comes out of a run, where it fits in red team and blue team work, and
what is out of scope.
Q24. Can I reproduce documented real-world grid attack
campaigns?
The protocol behaviour behind them, yes, in a lab. The 2015 Ukraine attack and Industroyer,
also known as CrashOverride, operated on IEC-101, IEC-104 and IEC 61850. Industroyer2 was
reworked against IEC-104 substation control traffic in Ukraine in 2022. FrostyGoop abused
Modbus TCP against OT controllers in 2024 to cut heating to civilians in winter.
Each of those protocol interactions is in the NetSim Cyber attack library, so the
corresponding manipulations can be recreated safely and repeatedly against your own
monitoring stack. What is reproduced is the protocol-level effect, not the malware or the
intrusion route that delivered it.
Q25. How do I use NetSim Cyber to validate an IDS or train a
detection model?
Run the same scenario with the attack off and then on, and capture both. Attack start, stop,
type and parameters are all under your control and timestamped, so the resulting traffic is
labelled by construction, which is what supervised anomaly and intrusion detection models
need.
The same runs answer the operational question directly: did your IDS, your SOC playbook and
your analysts flag a stream that stayed perfectly valid on the wire? Scenarios are
reproducible, so a detection improvement can be measured against the identical attack
rather than against a fresh one.
Q26. What does a result actually look like?
Take a ramp attack on a Modbus TCP holding register carrying Voltage Phase A. Before the
attack the master reads a stable 109.97 to 110.04 V, a spread of 0.07 V. Under ramp
injection the same register climbs from 109.97 to 110.39 V, a continuous linear drift of
0.42 V.
There is no protocol error, no dropped session and no transport-layer alarm throughout.
Detection has to come from the data itself, and demonstrating that is the point of the
exercise.
Q27. Where does NetSim Cyber fit in red team and blue team
work?
It is the reproducible adversary. On the red side it supplies protocol-aware attacks,
wire-valid packets that standard monitoring does not flag, timestamped scenarios generated
on demand, and safe recreations of real campaigns.
On the blue side it lets you tune IDS, IPS and anomaly detection, exercise SOC playbooks,
train analysts, build labelled data for detection models, and run device, vendor and product
security testing. One controllable adversary, used to train, test and prove the defence
before it goes live.
Q28. What does NetSim Cyber not do?
- It does not solve the electrical power system. Grid dynamics come from a paired
real-time simulator, as described in Q4.
- It does not cover initial access, exploitation or malware delivery.
- Cyber attack detection algorithms are not supported in the current release and are
under development.
- Cyber attack countermeasures are not supported in the current release and are under
development.
Detection remains the job of the tools and the people that the platform is designed to
test, which is the intended division of labour rather than a gap to be worked around.
Q29. How is an evaluation arranged?
Write to sales for an evaluation. A typical evaluation starts
single-system with the built-in simulators, so a scenario can be built and an attack
validated on one machine, and then moves to a distributed setup against your own relays,
SCADA master or real-time simulator. The
NetSim Cyber product page covers the feature set, the
architecture and the publication list in more detail.
Evaluation
Run a protocol-aware attack against your own defences
Request a demonstration or an evaluation license. A protocol, a source, and a destination are
enough to build a scenario, and the built-in simulators mean the first experiment needs no
hardware at all. Bring your own relays, SCADA master or real-time simulator when you are ready
to test against the real thing.
Sources, scope and trademarks
Sources. The answers on this page are drawn from the NetSim Cyber technology
library and user manual (v15.1) and from the NetSim Cyber product documentation, and describe the
product as of July 2026. Capabilities change between releases; confirm the current position with
Tetcos, and tell us if anything here is out of date so we can correct
it.
Scope. NetSim Cyber is a laboratory tool for post-exploitation impact analysis on
power-system communication traffic. It is not a penetration-testing framework, it does not deliver
exploits or malware, and it is intended for use on controlled testbeds and equipment that the user
is authorised to test. Nothing on this page is guidance for attacking systems in production.
Attack campaign references. Statements about the 2015 Ukraine power grid attack,
Industroyer and CrashOverride, Industroyer2, FrostyGoop and Volt Typhoon summarise publicly
reported incident analysis. They are cited to identify the protocols involved, and no claim is made
about any specific victim, vendor or product.
Trademarks. RTDS is a trademark of RTDS Technologies Inc. OPAL-RT and HYPERSIM are
trademarks of OPAL-RT Technologies, Inc. Typhoon HIL is a trademark of Typhoon HIL, Inc. MATLAB and
Simulink are registered trademarks of The MathWorks, Inc. PSCAD is a trademark of Manitoba Hydro
International Ltd. SEL is a trademark of Schweitzer Engineering Laboratories, Inc. Siemens is a
trademark of Siemens AG. All other product and company names are trademarks of their respective
owners, used here solely to identify the products discussed. Tetcos is not affiliated with,
endorsed by, sponsored by or certified by any of them, and no such relationship is implied.