NetSim Cyber examples

Worked examples · NetSim Cyber 15.1

Four end-to-end examples of NetSim Cyber on live power-system traffic. In each example, a Threat Agent is in the communication path. In three examples, the Threat Agent changes the traffic. In the fourth, it inspects the traffic and drops packets that fall outside a defense profile. Each section gives the setup, the steps and the measured result.

Back to NetSim Cyber Protocol simulators

The examples

Select an example to go to its section.

Example 1 · Attack C37.118 synchrophasor attacks Six attack modes on a live PMU stream, as the PDC shows them. PMU→PDC Manager TCP 4712Built-in attacker Go to example → Example 2 · Attack IEEE 9-bus with MATLAB/Simulink False data injection on the Bus 6 voltage makes a supervisory controller open a breaker. Simulink→Controller TCPUDPModbus TCP Go to example → Example 3 · Attack Modbus replay Recorded FC04 responses from the Normal scenario hide a live overvoltage from the Master. Slave→Master TCP 502FC04Replay Go to example → Example 4 · Defense Synchrophasor monitoring and defense One Python callback modifies, inspects and drops C37.118 packets. PMU→Filter→PDC Manager Python callback50 / 60 Hz Go to example →

What all the examples have

All four examples use the same three parts. The sections below give only the data that is different for each example.

Traffic path

The source and the destination are Real Nodes in the NetSim Cyber scenario. A Threat Agent is between them. The Application Traffic Filter selects the flow by source, destination and port.

Attack or filter

A built-in protocol attacker (Synchrophasor or Modbus) or a Python Packet Modifier script operates on each selected packet. The script can modify the payload, drop the packet, or add delay.

Captures

NetSim Cyber writes four captures: PRE.pcap (source traffic), MOD.pcap (modified), POST.pcap (forwarded) and DROP.pcap (dropped). The destination shows the effect.

C37.118 synchrophasor attacks

The Threat Agent changes a live IEEE C37.118-2005 stream between the PMU simulator and the PDC Manager. The PDC shows the effect of each attack, and the stream stays connected. The 2011 profile operates in the same procedure with the 2011 simulators and attacker profile.

Setup

Profile
IEEE C37.118-2005
Source
PMU simulator, TCP port 4712
Destination
PDC Manager
Hosts
Three systems: PMU source, NetSim Cyber host, PDC destination. NetSimCyberClient.exe on the two endpoints sends the traffic through NetSim Cyber. Static routing is an alternative.
Attacker
Built-in Synchrophasor attacker, 2005 profile

Steps

  1. Put the Threat Agent between the PMU and PDC Real Nodes.
  2. Set the Application Traffic Filter to the PMU source, the PDC destination and the TCP port.
  3. Select the Synchrophasor attacker with the 2005 profile. Start the simulation.
  4. Start the PMU, then connect the PDC Manager. The attacker reads the stream layout and phasor list from the first configuration frame.
  5. Apply an automatic attack or a manual injection. Monitor the PDC.

Start sequence

Start NetSim Cyber and the attacker before PMU traffic starts. If the PMU and the PDC complete their handshake first, the attacker does not see the configuration frame. Then the phasor list possibly does not load.

Attack modes shown

ModeEffect at the PDC
Increment biasSelected phasor magnitudes increase by an offset.
Decrement biasSelected phasor magnitudes decrease by an offset.
Ramp / driftSelected magnitudes change slowly, as with sensor drift.
Noise / jitterSelected magnitudes change at random.
Frequency overrideThe frequency field changes to the value that the attacker sets.
Manual injectionMagnitude, angle, frequency or ROCOF change to values that the user types in.
NetSim IEEE C37.118-2005 Attacker window with the Automatic tab, attack categories Data, Time and Status, and Increment Bias selected
The IEEE C37.118-2005 attacker. Each automatic attack scales with the signal range in a window of the most recent samples. The Manual and Replay tabs are next to Automatic.
PDC voltage plots for three phasors before and after an increment bias attack. After the attack starts, all three traces step up.
Increment bias. The three phasor magnitudes at the PDC step up when the attack starts.
PDC frequency plot before and after a frequency override attack. The frequency changes from 60 Hz to 59 Hz.
Frequency override. The PDC frequency changes from 60 Hz to 59 Hz.

IEEE 9-bus with MATLAB/Simulink

An IEEE 9-bus plant in Simulink sends the Bus 6 voltage to a MATLAB supervisory controller. The controller sends a breaker command back. NetSim Cyber applies false data injection (FDIA) to the voltage in the measurement path, and the controller acts on the false value. The same loop operates over TCP, UDP and Modbus TCP.

IEEE 9-bus plantSimulink, Bus 6 breaker NetSim CyberChanges Bus 6 voltage Supervisory controllerMATLAB, limit check

← Command path: the controller sends the breaker command back to Simulink. In these examples, the command path does not go through the Threat Agent.

Controller logic

0.95 pu ≤ V6 ≤ 1.05 pu → command 0 (close breaker) if not → command 1 (open breaker)

These limits are settings for this example only. Do not use them as protection settings for a power system in operation.

Setup

Plant
IEEE 9-bus model in Simulink. Sample period 0.05 s.
Tested with
MATLAB R2023a, Instrument Control Toolbox, Windows 10/11 64-bit
NetSim Cyber
Two Real Nodes, one Threat Agent, one application filter
Package
Simulink model, controller scripts, Python packet modifier, Wireshark Lua dissectors. Sample configuration Cyber_IEEE 9-Bus_Example.

Three communication variants

VariantMeasurement pathCommand pathAttackFirst trip in the plot
TCP24-byte frame to controller server, port 500118-byte frame from controller server, port 5002Python packet modifier ieee9bus_bus6_fdia.py: V6 − 0.07 puAbout 4.4 s
UDP24-byte datagram to port 500118-byte datagram, port 5003 to port 5002Same script: V6 − 0.07 puAbout 8.0 s
Modbus TCPFC04 response from the Simulink server, port 502. Registers 0–1, FLOAT32 ABCDFC05 write to coil 0Built-in Modbus attacker: Gaussian noise/jitter on FC04 addresses 0–1About 14.0 s

The trip times come from the plots of the example runs. They are not measurements of protection performance.

Two plots against simulation time. Top: Bus 6 voltage received by the TCP controller decreases below the 0.95 pu lower limit in three intervals. Bottom: the breaker command goes to open in the same intervals.
TCP with NetSim Cyber. The received voltage decreases below 0.95 pu, and the controller sends the open command (1).
Two plots against simulation time. Top: Bus 6 voltage received over Modbus goes across the two limits between about 14 and 30 seconds. Bottom: the FC05 breaker command changes to open each time.
Modbus TCP with NetSim Cyber. Noise on the FC04 voltage goes across the two limits. Each time, the controller sends an FC05 open command.
Measurement frame and packet captures (TCP and UDP)
BytesFieldTypeDescription
0–1Headeruint16Measurement-frame identifier
2–5Sequenceuint32Frame number
6–13TimestampdoubleSimulink simulation time, s
14–21Bus 6 voltagedoubleVoltage magnitude, pu. The packet modifier changes this field.
22Breaker stateuint80 closed, 1 open
23Statusuint8Frame status
Field, sequence 427PREMOD
Simulation time21.3 s21.3 s
Bus 6 voltage1.000321 pu0.930321 pu
Breaker stateClosed (0)Closed (0)

Multi-byte fields are little-endian. The breaker byte stays the same in the changed frame. The breaker change shows in a subsequent frame, after the controller command gets to Simulink.

Result

The controller acts on the value that it receives from the network. In the baseline runs, the attacker is off, the voltage stays near 1.0 pu, and the breaker stays closed. The plant-side Bus 6 scope shows the physical value, not the false network value.

Modbus replay

The Threat Agent records FC04 input-register responses while the Modbus Slave is in the Normal scenario. Then the Slave goes to the Overvoltage scenario. During replay, the Master receives the recorded values, and the overvoltage stays hidden.

Setup

Experiment
Modbus_Replay, in the supplied workspace
Endpoint
127.0.0.1:502, Unit ID 1
Function
FC04 Read Input Registers, start address 0, count 10
Signals
Voltage phases A, B and C, current, frequency. FLOAT32, ABCD byte order.
Poll interval
500 ms
Replay buffer
19 FC04 responses, a 9.5 s loop

Steps

  1. Start the Modbus Slave in the Normal scenario. Start the NetSim Cyber simulation, then start Master polling.
  2. In the Modbus attacker Replay tab, select FC04. Record, then stop. The attacker shows “Buffer is ready”.
  3. Set the Slave to the Overvoltage scenario. Phase voltages go to about 124 V, and the Master shows 124 V.
  4. Start replay. The attacker puts the next recorded body into each live FC04 response of the same length.
  5. Stop replay. The Master shows the live 124 V again.
Master graph of Voltage Phase A. The trace is near 124 V, but in two shaded Replay ON intervals it decreases to the recorded value near 110 V.
Voltage Phase A at the Master. In the two Replay ON intervals, the recorded signal near 110 V hides the live overvoltage near 124 V.
StepAttacker modeSlaveMaster
RecordRECORDNormal, about 110 VValues from the Normal scenario, kept in the buffer
Overvoltage, before replayOFFOvervoltage, about 124 VLive value near 124 V
Replay onREPLAYStays near 124 VRecorded signal near 110 V
Replay offOFFStays near 124 VLive value near 124 V
Packet captures
Capture, tcp.port == 502Packets
PRE1008
MOD80 replaced FC04 responses
POST1008
DROP0
Transaction ID 457PREMOD and POST
Byte count2020
TCP payload29 bytes29 bytes
First register pair17144, 28817115, 64337
Phase A voltage124.0022 V109.9909 V

PRE and POST contain the same number of packets. For each packet that it gets, the Threat Agent forwards one changed live packet. It adds no replay packet. The transaction ID, Unit ID, function code and length stay the same. Only the register values change.

Conditions for replay

Replay applies only when the recorded body and the live body have the same length. Use the same function code, start address, count and poll interval when you record and when you replay. The loop time is the number of recorded responses multiplied by the poll interval.

Synchrophasor monitoring and defense

A Python Packet Modifier script starts the installed synchrophasor attacker. Then the script inspects the C37.118-2005 DATA frames that come from the attacker. If the measurements stay in the defense profile, the packet continues to the PDC. If a drop condition occurs, the script drops the full packet. The example operates with 50 Hz and 60 Hz PMUs.

Follow the packet

Show:
01 Traffic 02 Inspect and state 03 Check 04 Verdict 05 Outcome TCP traffic selected packet invoke first payload CFG-2 DATA Hz, rate baseline drop=True drop=False POST.pcap commit state only for a forwarded packet PMU simulator CFG-2 and DATA over TCP PRE.pcap Source traffic capture Packet Modifier One callback per packet Installed attacker Can change payload values Frame extraction Complete C37.118 frames CFG-2 state PMU IDs, nominal Hz, rate Accepted state Voltage baseline, frequency Defense profile Hz, ROCOF, voltage Packet verdict Full IP packet Drop packet Recorded in DROP.pcap Forward, commit state Current payload reinjected PDC Manager Export shows receipt

Move the diagram left or right to see all of it.

Select a box

Modify, inspect, decide

Each packet that the Application Traffic Filter selects goes through one callback. In the callback, the attacker can change the payload. Then the callback inspects each complete frame and returns one verdict for the packet. Select a box in the diagram to read its function.

Setup

PMU
One C37.118-2005 station, PMU ID 7734, 50 Hz, 30 DATA frames/s, CFG FORMAT 0x000E (floating-point phasors, frequency and ROCOF)
PDC
PDC Manager on loopback TCP, PMU source port 4712
Script
payload_modifier_synchrophasor2005_filter.py, the only Packet Modifier script. It starts the installed attacker.
Captures
PRE, MOD, POST and DROP
Version
NetSim Cyber 15.1.11 or later

Callback contract

NETSIM_PACKET_API_VERSION = 2 selects the seven-argument modify_payload() callback. Its context argument identifies the TCP flow. The callback returns one dictionary for each packet:

modified
True when the callback changed payload bytes
drop
True to reject the packet and record it in DROP.pcap
extra_delay_ms
Extra delay for the packet, in ms

Detection profile

MeasurementDrop condition, 50 Hz PMUPersistence
FrequencyBelow 47.08 Hz or above 51.67 Hz0.16 s (5 samples at 30 frames/s)
ROCOFAbsolute reported or frequency-derived average above 3.0 Hz/sWindow of 0.1 s or more for each PMU
UndervoltageBelow 0.50 pu of the baseline2.0 s (60 samples at 30 frames/s)
OvervoltageAbove 1.20 pu of the baseline0.16 s (5 samples at 30 frames/s)
Where the limits come from

The values come from IEEE Std 1547-2018. Table 18 gives the 60 Hz UF2 and OF2 values, 56.5 Hz and 62.0 Hz, each with a 0.16 s clearing time. For a 50 Hz PMU, the script scales them by 50/60, which gives 47.08 Hz and 51.67 Hz. A PMU that sets 60 Hz in CFG-2 uses 56.5–62.0 Hz directly.

Table 13 gives UV2 at 0.50 pu for 2.0 s and OV2 at 1.20 pu for 0.16 s. Table 21 gives the Category III ROCOF value of 3.0 Hz/s. IEEE Std 1547 does not give a procedure to discard packets. The example uses these values only as the limits of its profile.

These limits cannot tell a real grid disturbance from injected data. A production detector must also do protocol and consistency checks. Examples are C37.118 STAT flags, timestamp continuity, CRC validation and cross-measurement plausibility checks.

Results

TestDrop conditionResult
Frequency, 55 HzThe first condition that occurs. With a sudden override, the frequency-derived ROCOF condition usually occurs before the 0.16 s frequency condition.Console shows the condition. Dropped packets go to DROP.pcap.
ROCOF, 5 Hz/sOne of the two 0.1 s ROCOF averages above 3.0 Hz/sConsole reports a ROCOF drop. The PDC holds its last accepted value.
Overvoltage, 120 kV0.16 s above 1.20 puThe first persistence samples can get to the PDC. After that, the filter drops each packet in which the condition occurs.
Undervoltage, 30 kV2.0 s below 0.50 puThe first persistence samples can get to the PDC. After that, the filter drops each packet in which the condition occurs.
PDC Manager graph of Station A phase A voltage near 76 kV with a short spike to 120 kV, next to the attacker Manual Injection tab with phase A magnitude set to 120000
Overvoltage test, 50 Hz PMU. The attacker sets phase A to 120 kV. The system is 132 kV, so the nominal phase voltage is 76.2 kV, and 120 kV is about 1.57 pu. Only the first samples get to the PDC. Then the filter drops the packets.

Packet-level operation

The verdict applies to the full IP packet. If a drop condition occurs for one station in a multi-station packet, the filter drops the full packet. The filter inspects TCP retransmissions, but each C37 SOC/FRACSEC sample counts one time only. A frequency or ROCOF condition stays latched until the filter gets 0.16 s of new safe samples.

Related pages

To use these examples on your setup, or to get more data about one, use the Tetcos contact page.

NetSim Cyber The Threat Agent, the attack library for each protocol, and the setups for NetSim Cyber. Protocol simulators The PMU, PDC Manager and Modbus simulators used in these examples: parameters, defaults and signal models. NetSim Cyber Q&A Common questions about testbeds, IDS validation and attack datasets.

Trademarks

MATLAB and Simulink are registered trademarks of The MathWorks, Inc. Modbus is a trademark of Schneider Electric. Wireshark is a registered trademark of the Wireshark Foundation. All other product and company names are trademarks of their respective owners, used here only to identify the products discussed.