How do attackers use GOOSE messages?

How GOOSE messages become an attack path

GOOSE is designed for low-latency event delivery inside substation networks, so the attack surface is less about confidentiality and more about trust in message timing, origin, and state changes. If an attacker can inject, alter, delay, or replay traffic on that path, they may be able to influence protection logic, trigger nuisance trips, or create unsafe instability in equipment that assumes the stream is legitimate.

The important point is that GOOSE abuse is operationally powerful because protection systems often act on the message before a human can intervene. That means integrity failures can have immediate physical consequences, and even brief manipulation can be enough to alter relay behaviour or disturb coordination between devices.

In practice, the attack path is usually local to the control environment rather than internet-facing. That makes segmentation, switch hardening, device trust, and engineering workstation hygiene central to reducing exposure, especially where multiple relays, bay controllers, and substation automation devices share the same broadcast domain.

What spoofing, replay, and delay accomplish

Attackers use spoofing when they want a device to accept a false event as if it came from a trusted publisher. Replay is useful when they want to repeat an old but valid message at the wrong time, which can confuse state-dependent logic. Delay attacks are different: they do not need to forge content, only to interfere with timing so that protection decisions occur too late or out of sequence.

Those techniques can produce different outcomes depending on the scheme design. A false trip can open breakers unnecessarily, while a blocked or late message can prevent a protective action that should have occurred. In both cases, the attack goal is to disturb the control logic that depends on timely and authentic event delivery.

GOOSE also creates an opportunity for subtle manipulation because the traffic can look routine at packet level while still being operationally harmful. Attackers do not need to disrupt every frame, only enough of the critical sequence to create uncertainty, degrade coordination, or push equipment into a less stable operating state.

Why defenders need protocol-level monitoring, not just perimeter controls

GOOSE traffic should be treated as a high-value control plane, not ordinary east-west traffic. A useful defensive model is to segment OT networks tightly, restrict which devices can publish and subscribe, and watch for changes in publisher identity, sequence patterns, or unexpected traffic bursts that do not fit normal substation behaviour.

Defenders should also validate how protection schemes behave under malformed or degraded traffic. The practical test is not whether packets exist, but whether relays, logic controllers, and interlocks fail safely when messages arrive late, out of order, duplicated, or from an untrusted source.

Because GOOSE abuse is often about trust abuse inside an otherwise internal network, monitoring should include engineering workstations, switch configurations, and any device that could be used to inject or relay traffic. When suspicious behavior appears, the response should focus on proving message provenance and impact on protection state, not only on finding malware.

Risk and Threat Considerations

GOOSE misuse can create immediate safety and availability risk because protection logic may act on a forged or delayed event before operators can verify it. The same trust that makes the protocol effective in normal operations also makes it attractive for adversaries seeking fast disruption with little visible payload.

Failure mechanism: An attacker gains a path into the control network, then injects, replays, or delays GOOSE frames so relay logic sees a false state, misses a real event, or loses coordination with peer devices.

Impact: The result can be false trips, blocked protection, unstable switching behavior, equipment stress, or wider operational disruption across the substation and connected process.

Practitioner Guidance

What to verify: Confirm which devices are legitimate GOOSE publishers, which subscribers depend on them, and what “normal” timing looks like for each protection function. If those baselines are not known, anomaly detection will be noisy and response decisions will be weak.

What to prioritise: Protect the paths that can actually change protection state, especially the publishers and network segments that can influence breaker control or interlocking. The most important assets are often the least visible to traditional IT monitoring.

Decision rule: If a message can alter a protective action, treat source validation, segmentation, and fail-safe testing as mandatory. If a control can only be checked after an event, it is too late for prevention and must be paired with resilience testing.

Practitioner takeaway: The core challenge is not packet inspection alone, it is preserving trust in time-critical control messages when a single forged or delayed event can alter physical behavior.

Related resources from NHI Mgmt Group

• How do attackers use list planting?
• How do attackers use invisible Unicode?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?