By RUGERO Tesla (@404Saint).
IEC 61850 is another one of those protocols that becomes more interesting the deeper you go.
At first glance, it looks like another industrial protocol to dissect: identify the transport, decode the messages, enumerate the data model, and look for places where authentication or authorization is missing and that description turns out to be inadequate.
IEC 61850 is an ecosystem of communication models rather than a single protocol. MMS operates over the station bus and provides a comparatively conventional client/server interface. GOOSE and Sampled Values operate directly over Ethernet and introduce an entirely different set of assumptions around multicast, timing, state, sequencing, and data integrity. That difference became the central theme of this research.
I spent several days building an isolated IEC 61850 laboratory around libIEC61850, examining SCL configuration, MMS sessions, control operations, GOOSE, Sampled Values, and process-bus behavior. The work combined packet captures, custom Python tooling, native library examples, malformed-input testing, and direct observation of the simulated IEDs. There was also an unexpected historical component.
During the research, Parker McCauley pointed me toward Bruce Muschlitz, a former UCA conformance-testing participant, with a simple instruction:
Ask Bruce about the UCA decision dart board.
That conversation eventually led to an older 9-2LE Sampled Value capture, a legacy Excel visualization tool, and several observations about how real conformance testing used to be performed. So this article is both a protocol-security study and a record of how the investigation evolved.
1. Establishing the IEC 61850 Architecture
Before touching packets, I wanted a clear model of what I was actually testing.
The laboratory was divided conceptually into three communication areas:
IEC 61850 Laboratory
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
SCL / Station Bus Process Bus
Configuration │ │
│ ┌─────┴─────┐
│ │ │
MMS GOOSE SV
│ │ │
TCP/102 Ethernet Ethernet
The difference matters because MMS and the process-bus protocols do not provide the same security boundaries. MMS uses ISO-on-TCP and exposes an application-layer model containing logical devices, logical nodes, data objects, and control points. GOOSE and Sampled Values are much closer to the wire. They are Layer 2 Ethernet protocols identified by EtherTypes rather than TCP or UDP ports.
That immediately creates different questions for a security researcher.
For MMS:
- What can a client discover?
- Can it establish a session anonymously?
- What objects are exposed?
- Which operations require authorization?
- Are control operations protected?
For GOOSE and SV:
- Who is allowed to publish?
- How is publisher state represented?
- How are sequence numbers interpreted?
- What happens when frames originate from an unexpected source?
- Can subscribers distinguish legitimate traffic from manipulated traffic?
The architecture primer established these questions before the experiments began.
2. SCL: The Configuration Is Part of the Attack Surface
The first formal phase examined the SCL configuration rather than immediately attacking the network protocols. IEC 61850 systems rely heavily on configuration describing IED capabilities, logical nodes, communication parameters, datasets, and relationships between devices.
That means some of the information required to understand the operational system may exist before a single application-layer packet is exchanged.
Figure 1. SCL configuration analysis from the laboratory. The configuration provided the structural baseline used for subsequent MMS and process-bus experiments.
This was important for the rest of the research because the later experiments were not performed against an abstract IEC 61850 endpoint. They were performed against a specific configured data model. The configuration therefore became the reference against which observed behavior could be interpreted.
3. MMS: Finding the Station-Bus Attack Surface
The next phase moved into MMS. The laboratory IED exposed MMS through ISO-on-TCP on port 102. Once a connection could be established, the interesting question was no longer whether TCP/102 was reachable. It was what the server was willing to disclose and execute after the connection. The first step was enumeration.
A custom Python harness was used to inspect the MMS information model and map the exposed hierarchy.
MMS
│
├── Logical Devices
│ │
│ └── Logical Nodes
│ │
│ └── Data Objects
│ │
│ └── Data Attributes
│
└── Control Objects
Figure 2. MMS data-model enumeration performed against the laboratory IED.
The important observation was that the server exposed a meaningful operational model after session establishment. This matters because IEC 61850 does not merely expose registers in the way a simple legacy industrial protocol might. The client is interacting with a structured information model. Once that model is known, the next question becomes much more interesting: Which parts of that model can actually be manipulated?
4. MMS Control: Discovery Became Manipulation
The third phase focused on control operations. The initial attempt to write directly to a control value did not behave as a naive writable register would. The server rejected the operation because of its data-typing and control semantics. That failure was useful.
It demonstrated that a failed raw write does not necessarily mean the underlying control point is protected. IEC 61850 provides higher-level control services through the ACSI model, and the correct operation path produced a very different result.
The laboratory demonstrated that a properly constructed control operation could alter the simulated control state without an authentication mechanism being enforced by the tested configuration.
Figure 3. Laboratory observation of MMS control operations against the simulated IED.
This became one of the more important distinctions in the research:
A protocol implementation can correctly enforce its application semantics while still providing insufficient security authorization.
The server knew that the request had to be structured correctly. It did not necessarily know whether the requester should have been allowed to perform it. That is central to industrial protocol security.
5. Leaving TCP Behind: The Process Bus
At this point the research became considerably more interesting. MMS had given me a structured client/server interaction model but GOOSE and Sampled Values did not.
Both operate directly over Ethernet.
Ethernet
│
├── 0x88B8 → GOOSE
│
└── 0x88BA → Sampled Values
The laboratory used Linux network namespaces and a virtual Ethernet bridge to create an isolated process-bus environment.
The basic topology was:
br-processbus
/ \
/ \
ns-ied1 ns-sub1
│ │
veth-ied1 veth-sub1
The IED and subscriber could therefore exchange Layer 2 traffic without involving the physical network. That gave me a controlled environment for examining the actual Ethernet frames.
Figure 4. Process-bus traffic observed inside the isolated laboratory bridge.
This was also where the security model changed. There was no TCP session to authenticate. There was no client/server connection in the conventional sense. A subscriber observes Ethernet frames and interprets them according to the protocol semantics. That makes source identity, state numbers, sequence numbers, timing, and cryptographic protection much more important.
6. GOOSE State Is More Than Payload
GOOSE frames contain state and sequencing information that allows subscribers to reason about publisher behavior.
Among the fields examined were:
stNum
sqNum
TAL
stNum represents the state number while sqNum tracks sequencing within a state.
The Time Allowed to Live value provides another important piece of information about the expected timing behavior of a message. These fields are not merely metadata. They influence how a subscriber interprets the stream. That means manipulating them can potentially affect the subscriber's view of system state even when the underlying payload appears structurally valid. The research therefore moved from passive dissection into controlled anomaly injection.
7. GOOSE and SV Injection
The fifth phase tested how the process-bus environment reacted to deliberately manipulated traffic.
The experiments included:
- unauthorized source MAC addresses;
- extreme
stNumvalues; - sequence-number manipulation;
- quality-field manipulation;
- Sampled Value frequency anomalies.
Figure 5. Controlled GOOSE state-number manipulation using an unauthorized source.
The purpose was not to demonstrate a production attack. The laboratory was used to determine how the simulated protocol participants interpreted abnormal frames. A structurally valid frame can therefore become interesting from a security perspective even when the Ethernet frame itself is perfectly ordinary.
7.1 Quality Metadata
One experiment modified the quality information associated with the transmitted measurement.
Figure 6. Controlled quality-field manipulation during process-bus testing.
This illustrates an important property of industrial telemetry: The numerical value is only part of the information being transmitted. A measurement may be accompanied by metadata describing its quality or validity. An attacker who changes the metadata does not necessarily need to modify the numerical value itself to influence how downstream systems interpret the measurement. That creates a useful difference between: Value integrity + Metadata integrity. They both matter.
7.2 Sampled Value Frequency
The same principle appeared in Sampled Values. Sampled Value streams are time-dependent. Their usefulness depends not only on the numbers being transmitted, but also on the temporal characteristics of the stream.
One controlled experiment introduced a frequency mismatch into the SV traffic.
Figure 7. Controlled Sampled Value frequency anomaly observed during the process-bus experiment.
This became particularly interesting later, when I began studying the historical 9-2LE material provided by Bruce Muschlitz.
8. The Unexpected Detour: A Conversation With UCA History
The IEC 61850 research took an unexpected turn before the formal security work was finished. Parker McCauley had commented on one of my research updates and, after seeing IEC 61850 in the list, told me, "Good luck on IEC 61850." When I replied that I was diving into GOOSE and MMS and would bring PCAPs, he suggested I contact Bruce Muschlitz and ask about the UCA decision dart board. And I did.
Bruce explained that he had worked in UCA conformance testing and that one of his major contributions involved the initial accreditation of testers. One detail immediately caught my attention. A significant part of that accreditation process involved manually inspecting PCAP logs to verify that testers were generating the correct stimulus and correctly interpreting the device-under-test response. There was no sophisticated automated pipeline doing the work for them.
And Bruce had built an Excel-based tool to visualize Sampled Value data because raw packet streams were not particularly useful for understanding waveform behavior.
He eventually sent me two historical artifacts:
Template_SV_viewer_rev4p0.xlsm
Sample240.pcap
That changed the direction of one part of the research.
9. Reconstructing a Legacy 9-2LE Sampled Value Analysis Workflow
The Excel tool was designed specifically around the fixed dataset structure of IEC 61850-9-2LE. Rather than simply opening the spreadsheet and treating it as a black box, I decided to reproduce the relevant analysis path in Python.
The pipeline became:
Sample240.pcap
│
▼
Ethernet
│
▼
VLAN detection
│
▼
EtherType 0x88BA
│
▼
ASN.1 / BER
│
▼
SV ASDU
│
▼
0x87 seqData
│
▼
9-2LE fixed dataset
│
├── Ia
├── Ib
├── Ic
├── In
├── Va
├── Vb
├── Vc
└── Vn
For the 9-2LE capture, the fixed dataset made the parsing problem unusually deterministic.
Each of the eight measurement channels occupies eight bytes:
4 bytes → measurement
4 bytes → quality
giving:
8 channels × 8 bytes = 64 bytes
The parser extracted the values, tracked smpCnt, and reconstructed the signals as time-series data. The result was much easier to understand than a terminal full of integer values. The three-phase relationships became visible. The frequency, the neutral channel became visible, and anomalies that would be easy to miss in a packet table became obvious when represented as waveforms.
10. Why Bruce Used Excel
There was an amusing practical lesson here.
My first instinct was essentially:
Why Excel?
Python, Scapy, Matplotlib and a few lines of code were enough to build a native analysis pipeline. Bruce's answer was much more practical. Many engineering workstations used for conformance testing were heavily restricted. Installing a new application could be difficult. Excel, however, was already there. That meant an Excel macro could be deployed to systems where installing a dedicated analysis application was not realistic.
Bruce himself admitted that Python would have been preferable if there had been a free choice. That was a useful reminder that engineering tooling is often constrained by the environment in which it has to operate, not by what would be technically elegant.
11. What the Historical Capture Revealed
The supplied Sample240.pcap became the baseline for the independent parser. The capture contained a 9-2LE Sampled Value stream with the fixed dataset structure described above.
The reconstructed measurements showed recognizable three-phase behavior and allowed the current and voltage channels to be viewed as continuous signals rather than isolated packet fields.
That difference is important because, Wireshark is excellent at telling you that a field contains a value.
It is much less useful for answering questions such as:
Is this waveform periodic?
Are the phases behaving consistently?
Is the frequency correct?
Is the neutral channel behaving as expected?
Did the signal suddenly become noise?
Bruce had made the same observation from a conformance-testing perspective. One of the common anomalies he encountered was simply bad input data: a source that was producing noise when it should have been producing a meaningful signal.
Another was using the wrong input frequency, such as 50 Hz where 60 Hz was expected. Those are not necessarily protocol parsing errors, they are measurement-integrity problems, and packet inspection alone can make them surprisingly difficult to see.
12. One Important Correction to the 9-2LE Parser
Bruce also caught an important limitation in my initial parser design. I had been treating the 0x87 tag as though it represented a universally fixed 64-byte payload. That is only appropriate when the 9-2LE fixed dataset is already known. It does not generalize to newer IEC 61869-9 implementations where dataset contents are declared through configuration.
He also pointed out that a frame may contain multiple 0x87 TLVs, particularly at higher sampling rates. That matters because a parser that simply searches for the first 0x87 tag and consumes 64 bytes is not a general IEC 61850 Sampled Value parser. It is a 9-2LE-specific parser. That difference is now explicit in the research. This is exactly the sort of implementation boundary that is easy to miss when working only from a single capture.
13. The Dataset Design Question
The historical discussion also exposed an interesting design trade-off. Bruce described an earlier idea involving a fixed dataset intended to make merging units and subscribers effectively plug-and-play.
The concept was attractive:
Merging Unit
│
│ fixed dataset
▼
Any compatible subscriber
The subscriber would already know what each position represented. The eventual direction taken by IEC 61869-9 instead required more reliance on dataset configuration, including information available through SCL. That saves bits on the wire but moves some complexity into configuration and interpretation.
It is a classic engineering trade-off:
Simpler wire format
vs.
More flexible configuration
Neither choice is inherently a security vulnerability, but every additional layer of configuration and interpretation creates another boundary that security researchers and conformance testers need to understand.
14. What the Research Actually Demonstrated
After several days in the laboratory, the IEC 61850 attack surface looked considerably different from when I started. The research demonstrated that the protocol stack has several distinct security boundaries.
MMS
The laboratory showed:
- session establishment without native identity authentication in the tested configuration;
- structured information-model enumeration;
- exposed control objects;
- successful control execution without an enforced authentication boundary;
- correct rejection of malformed or semantically invalid operations in some cases.
GOOSE
The experiments examined:
- Layer 2 multicast delivery;
- publisher state;
- sequence tracking;
- Time Allowed to Live;
- unauthorized source behavior;
- manipulated state numbers;
- manipulated quality metadata.
Sampled Values
The research examined:
- Layer 2 transmission;
- ASN.1 BER structure;
- fixed 9-2LE dataset parsing;
- sample-counter continuity;
- waveform reconstruction;
- phase relationships;
- frequency behavior;
- quality metadata.
The most important conclusion is not that IEC 61850 is "insecure." That would be an unnecessarily broad claim. The more useful conclusion is that different parts of the IEC 61850 ecosystem rely on very different trust assumptions, and those assumptions need to be examined independently.
15. Protocol Integrity Is Not Measurement Integrity
One of the strongest lessons from the research was the need to separate two concepts.
Protocol integrity
EtherType
VLAN
ASN.1 / BER structure
ASDU structure
Dataset length
Sequence fields
Quality fields
Measurement integrity
Waveform continuity
Amplitude
Frequency
Phase relationship
Channel consistency
Neutral behavior
A frame can be perfectly valid from a protocol perspective while carrying a measurement that makes no physical sense. The inverse is also true. An unusual waveform does not automatically mean that the packet was maliciously modified. Equipment faults, bad configuration, synchronization problems, sensor problems, and capture artifacts can all produce unusual telemetry.
That became one of the central principles of this research:
A valid packet is not necessarily a trustworthy measurement.
16. What I Did Not Claim
There is a temptation in protocol-security research to turn every interesting observation into a vulnerability claim. I deliberately avoided doing that here. The laboratory used simulated IEC 61850 components and controlled packet injection. The GOOSE and SV manipulation experiments demonstrate how the tested environment responded to abnormal traffic. They do not establish that every commercial IED or merging unit will behave the same way. Likewise, the MMS observations apply to the specific libIEC61850 configuration used in the laboratory. The historical Sample240.pcap establishes a useful analytical baseline, but it does not represent every legitimate 9-2LE waveform. The research therefore treats implementation behavior, protocol behavior, and physical-system behavior as separate layers.
17. Why the PCAPs Matter
The PCAP files are not included merely because packet captures look impressive in a research repository. They are the evidence behind the observations.
For each major phase, the repository contains the corresponding capture alongside the analysis script and screenshots. That makes it possible to move through the research in the same direction I did. The screenshots provide a quick visual record, the PCAPs provide the raw evidence, the scripts provide the experimental mechanism, and the notes explain what the evidence means.
18. A Few Lessons From the Laboratory
The most useful lessons from this research were not individual packet fields.
Start with the architecture
Jumping directly into packets makes complex protocols harder to understand. The SCL model, communication planes, logical nodes, datasets, and service relationships provide the context required to interpret the packets correctly.
Treat different communication planes differently
MMS, GOOSE, and Sampled Values are not simply three encodings of the same protocol. They operate under different transport and trust assumptions.
Capture everything
A terminal output can tell you that something happened, but a PCAP can show exactly what happened on the wire.
Visualize telemetry
For Sampled Values in particular, numerical output is not enough, awaveform can reveal a problem that is almost invisible in a packet table.
Separate implementation behavior from specification behavior
A laboratory implementation can accept something that the specification does not intend, or reject something that a researcher expected to work. Both observations are valuable, but they should not be confused.
Preserve the ugly parts of the research
Some of the most useful observations came from things that initially did not work. The MMS connection problems, virtual-interface behavior, parser assumptions, and 9-2LE-specific limitations all became useful once they were understood. A reproducible research record should document those boundaries instead of pretending the experiment was perfectly linear.
19. Final Findings
The IEC 61850 laboratory produced several concrete observations:
- SCL provides valuable structural context for interpreting the operational attack surface.
- The tested MMS configuration allowed session establishment without an authentication boundary.
- The exposed MMS information model could be enumerated and used to identify operational control objects.
- Properly structured control operations could alter simulated control state without authentication being enforced by the tested configuration.
GOOSE operates directly over Layer 2 Ethernet, creating a fundamentally different security model from MMS.
GOOSE state and sequencing fields provide important context for subscriber behavior and therefore deserve security monitoring.
Controlled manipulation of GOOSE state and quality information demonstrated the relevance of metadata integrity, not just payload integrity.
Sampled Value analysis benefits substantially from waveform reconstruction rather than packet-level inspection alone.
9-2LE's fixed dataset makes lightweight parsing practical, but that assumption must not be generalized to newer IEC 61850 Sampled Value implementations.
Protocol validity and measurement plausibility are separate security properties.
Historical conformance-testing practice reinforces the value of PCAP inspection and visualization when validating industrial communication behavior.
The observations are specific to the laboratory implementation and configuration and should not be generalized to all IEC 61850 deployments.
20. Closing
IEC 61850 turned out to be exactly as difficult as I was warned. Not because the packets are impossible to decode, but because there is much more to the system than the packets. MMS introduces a structured application model. GOOSE introduces Layer 2 event communication and state tracking. Sampled Values introduce continuous telemetry where the meaning of a packet depends partly on what the signal looks like over time. SCL ties much of that behavior back to configuration, and security has to account for all of it.
The most useful result of the research was therefore not a list of malformed frames or unauthenticated operations. It was a better model of where trust actually exists. And perhaps the most unexpected part was discovering that the same discipline used in modern packet-level security research was already being applied years ago by engineers manually inspecting PCAPs for conformance.
Repository
The complete laboratory, research notes, scripts, PCAP captures, and supporting screenshots are available in the accompanying repository.
The laboratory was conducted entirely against locally controlled IEC 61850 simulation infrastructure. No production substations, IEDs, merging units, or operational power systems were targeted.
Acknowledgment
This research was partially informed by historical technical guidance from Bruce Muschlitz, formerly involved in UCA conformance-testing work.
Bruce provided the historical Template_SV_viewer_rev4p0.xlsm tool and Sample240.pcap capture, along with technical context concerning 9-2LE Sampled Values, merging-unit testing, waveform visualization, dataset design, and conformance-test PCAP analysis. The Python parser and visualization workflow used in this research were independently implemented from the supplied material. I am grateful for the opportunity to learn from that history.
Top comments (0)