← Back to Writeups

DoS Attacks in an ICS Lab: LAND + SYN Flood

For authorized or educational use only.

This writeup documents a controlled Denial-of-Service (DoS) attach against an ICS-style setup (OpenPLC + ScadaBR). The focus is practical: setup the VMs, run a LAND attack and SYN flood, validate in Wireshark, and compare hping3 vs Metasploit behavior.

Everything below is for authorized testing in an isolated environment.

Setup and configuration

You can reproduce this easily in either of these layouts:

Option A: 3 VMs (fully virtualized)

  • Attacker: Kali VM #2 (10.211.55.8)
  • PLC: Kali VM #1 running OpenPLC Runtime (10.211.55.6)
  • HMI: Windows 11 VM running ScadaBR (10.211.55.3)

Option B: 2 VMs + 1 local machine

  • Attacker (Host): macOS laptop (172.17.183.243)
    • You can use and OS, but I used MacOS and figured out some important limitations noted below.
  • PLC VM: Kali + OpenPLC (10.211.55.6)
  • HMI VM: Windows 11 + ScadaBR (10.211.55.3)

In both layouts, the HMI (Human Machiene Interface) remained connected to the PLC in ScadaBR and the graphical view worked during baseline testing.

Attack 1: LAND attack

Local Area Network Denial of Service: a layer 4 (transport) TCP SYN source & destination IP address spoof.

Command used

sudo hping3 -V -c 3000 -d 100 -S -p 502 -s 80 -k -a 10.211.55.6 10.211.55.6

Why this is a LAND attack

The packet is spoofed so source and destination resolve to the same host (10.211.55.6), forcing the target to process self-referential traffic.

Wireshark validation filter

ip.src == 10.211.55.6 && ip.dst == 10.211.55.6 && tcp.dstport == 502

Wireshark showed repeated SYN traffic that appeared to originate from the PLC and return to itself on Modbus port 502, creating abnormal connection behavior and unnecessary stack load.

Attack 2: SYN flood with hping3

Command used

sudo hping3 -V -S --flood -p 502 10.211.55.6

Wireshark validation filter

tcp.flags.syn == 1 && tcp.flags.ack == 0 && tcp.port == 502

Large volumes of incomplete connection requests were visible (many SYN, no completed handshakes). In this lab run, the attacker-side networking could become the bottleneck before the PLC fully degraded.

Metasploit on macOS M4 Pro: limitations reached

I initially used my local macOS machine as the attacker to keep tools available outside class/lab VMs.

What worked

  • Metasploit installation with Rosetta 2
  • Launching msfconsole by pointing directly to the embedded Ruby/runtime path

What failed

Running auxiliary/dos/tcp/synflood on macOS produced a PacketFu crash:

[-] Auxiliary failed: NoMethodError undefined method '[]' for nil
...
packetfu ... StructFu#typecast

Practical cause

The module relies on raw packet crafting (packetfu) and macOS networking restrictions can break this path even with sudo, especially on Apple Silicon workflows where compatibility layers are involved.

Workaround used

Move the attacker role to a dedicated Kali VM and run Metasploit there.

Metasploit SYN flood from Kali attacker VM

After switching attacker execution to Kali VM #2 (10.211.55.8), the module ran as expected.

Commands used

sudo msfconsole
use auxiliary/dos/tcp/synflood
set RHOSTS 10.211.55.6
set RPORT 502
run

Wireshark validation filter

tcp.flags.syn == 1 && tcp.port == 502

You can tighten this to only initial SYN requests with:

tcp.flags.syn == 1 && tcp.flags.ack == 0 && tcp.port == 502

Hping3 vs Metasploit

  • Both generated SYN-heavy traffic and incomplete TCP sessions against PLC port 502.
  • hping3 profile: more manual and pattern-consistent.
  • Metasploit profile: more automated and appeared faster/more bursty.
  • Key operational difference: tool compatibility. hping3 worked reliably from macOS host, while Metasploit SYN flood required moving to Kali VM.

Recovery and prevention notes

If a host is impacted by LAND/SYN-flood style traffic:

  • Isolate from attack traffic quickly (ACL/firewall, especially targeted service port).
  • Clear stressed connection state (service restart, stack reset, controlled reboot if needed).
  • For ICS, default to safe state while communications recover.

To reduce recurrence:

  • Block spoofed/self-referential packets (src == dst) at network boundaries.
  • Enforce ingress/egress filtering.
  • Add IDS/IPS signatures for malformed LAND patterns and SYN flood behavior.
  • Use segmentation so only trusted HMI systems can reach PLC service ports.
  • Enable rate-limiting/SYN protections on exposed interfaces.
  1. LAND and SYN flood traffic are easy to validate with the right Wireshark filters.
  2. The same attack concept can look operationally different depending on tooling.
  3. On macOS M4 Pro, Metasploit DoS modules that depend on low-level packet crafting may hit platform limitations; a Linux attacker VM is the most reliable path for repeatable offensive testing.