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?

  1. Launch NetSim Cyber and open or create a simulation.
  2. Select the deployment type: traffic local to this system, or traffic passing through it inline.
  3. Build the scenario on the grid, adding source and destination nodes with a Threat Agent between them.
  4. Configure the Application Traffic Filter with the node pair, protocol and port.
  5. Select the built-in attacker for that protocol, or import a custom Python attacker.
  6. 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 TCP502PLC or RTU to SCADA HMI or master
DNP320000Outstation to SCADA master
IEC 60870-5-1042404Controlled station to master station
IEEE C37.1184712 or 1410, as configuredPMU 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.118PMU simulatoropenPDC or PDC subscriberpyPMU, openPDC
IEC 61850IED or relay publisherGOOSE subscriber and analyzerlibiec61850
Modbus TCPPLC or RTU simulatorSCADA HMI or Modbus masterpymodbus, QModMaster
DNP3RTU simulatorSCADA masterOpenDNP3
IEC 60870-5-104IEC-104 slaveIEC-104 master stationlib60870

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.