Offensive Security
Red Team Operations AI Red Teaming OT & IoT Red Teaming Adversary Emulation
AI Automation
AI Automation for Business
Consulting
Advisory & Consulting
Company
Intel About Request a briefing
Line 01 — Offensive Security

OT & IoT Red Teaming.

Offensive testing for SCADA, ICS and the connected devices you ship or depend on. The objective is never to prove we can stop a process — it's to prove how far an adversary gets before anyone notices, and to stop deliberately at a line you set in writing.

ot_survey.py — passive phase · redacted
# passive OT survey — listen only, nothing transmitted
from stealthbyte import ot, purdue, roe

def survey(site: Site):
    # 01 — span port capture; no active scanning on L1/L2
    tap    = ot.passive_tap(site.core_switch, mode="listen")
    assets = ot.fingerprint(tap, protos=[
        "modbus", "dnp3", "s7comm", "enip", "iec61850"])

    # 02 — place assets in zones, find undocumented conduits
    zones     = purdue.classify(assets, levels=range(0, 4))
    crossings = purdue.find_conduits(zones, undocumented=True)

    # 03 — the stop line is contractual, not discretionary
    return roe.halt_before(crossings, at="controller_write")
01
Service definition

Availability is the
whole point.

IT security inverted

In IT, confidentiality usually leads and a short outage is survivable. In OT the order reverses: safety first, then availability, then integrity, and confidentiality last. A technique that is routine on a corporate network — an aggressive port scan, a credential spray, a reboot to clear state — can trip a protection relay or halt a line.

So the tradecraft changes. We work passively until active work is explicitly authorised, we test destructive techniques against lab or vendor-equivalent hardware rather than your plant, and every engagement carries a written stop line we do not cross.

The flat network nobody drew

Almost every site we assess believes its OT network is segmented. What we usually find is a handful of undocumented conduits — an engineering laptop with two NICs, a vendor maintenance VPN, a historian that talks to both sides, a wireless bridge installed for a commissioning job in 2019 and never removed.

You need this if a safety or production incident would be a board-level event, if a regulator expects evidence rather than a policy document, or if you ship connected devices whose firmware has never been attacked by anyone friendly.

SCADA & ICS assessment

PLCs, RTUs, HMIs, historians and engineering workstations — enumerated, fingerprinted and tested against the protocols they actually speak.

IT / OT segmentation testing

We start in the enterprise network and try to reach the process network the way an intruder would, documenting every conduit that shouldn't exist.

Device & firmware attack

Hardware teardown, debug interface access, firmware extraction and analysis, secure-boot review, and the cloud APIs the device pairs with.

Compliance-mapped evidence

Findings mapped to IEC 62443 zones and conduits, ATT&CK for ICS, and the sector regime you report against — written to survive an audit.

02
Scope model

Scoped by level,
not by IP range.

We scope against the Purdue reference model, because that's the language your engineers already use. Each level is explicitly in or out, and the boundary where active testing stops is agreed before anyone touches a keyboard.

L5 · L4

Enterprise & business network

Corporate IT, ERP, email, domain services — the usual starting position for an intruder.

Full active testing
L3.5

Industrial DMZ

Jump hosts, patch servers, historians, remote-access brokers and vendor VPN terminations.

Primary objective
L3

Site operations

Engineering workstations, domain controllers for OT, historians and reporting systems.

Active · authorised windows
L2

Supervisory control

HMIs, SCADA servers, alarm management and operator interfaces.

Read-only by default
L1

Basic control

PLCs, RTUs, DCS controllers and protection relays.

Passive · lab for active
L0

Physical process

Sensors, actuators, drives and the equipment that moves the world.

Never in scope
Protocols in regular scope
Modbus TCP / RTU DNP3 S7comm EtherNet/IP · CIP PROFINET IEC 61850 · MMS / GOOSE IEC 60870-5-104 BACnet OPC UA MQTT · CoAP BLE · Zigbee LoRaWAN
03
How it works

Four phases.
One stop line.

Safety planning & rules of engagement

Joint session with your process safety and engineering leads. We agree scope by Purdue level, prohibited techniques, maintenance windows, an abort phrase, and a named engineer who can halt the engagement instantly.

Duration1–2 weeks

Passive discovery & architecture review

Span-port capture, traffic fingerprinting and asset inventory without transmitting to control devices. Compared against your network diagrams — the gap between the two is usually the finding that matters most.

ImpactZero touch

Segmentation & pivot testing

Active work from the enterprise side toward the industrial DMZ and site operations, chaining identity, remote access and misconfiguration. Anything below the agreed level is demonstrated on lab or vendor-equivalent hardware instead.

Duration2–5 weeks

Reporting, mapping & retest

Board narrative, engineering detail, zone-and-conduit findings mapped to IEC 62443 and ATT&CK for ICS, and a remediation plan written for people who cannot simply reboot production. Free retest within 90 days.

Included90-day retest
Representative path · enterprise to industrial DMZ · halted at the stop line
01OSINT · supplier and site reconnaissanceRecon2d
02Initial access · phish against engineering staffT08656h
03Valid accounts · shared vendor credentials reusedT085940m
04Remote services · maintenance VPN into the DMZT088625m
05Passive capture · control traffic observedT08423h
06Asset discovery · controllers and HMIs identifiedT08461h
STOPAuthorised stop line — no command issued to any controllerBy contract

Illustrative composite. Technique references follow MITRE ATT&CK for ICS.

04
What you get

Three reports.
Three audiences.

01

The Board Brief

What an intruder could reach, what it would have meant for safety and production, and what to fund first. Written for a board and, where relevant, for your regulator.

02

The Engineering Report

Asset inventory as found, every conduit discovered, reproducible steps, and packet captures preserved. Written for the controls engineers who own the plant.

03

The Zone & Conduit Plan

Segmentation model as it should be, mapped to IEC 62443, sequenced so it can be delivered during real maintenance windows rather than in theory.

05
Engagement models

Three ways to run it.

Scope, timeline and cost are all set in a scoping conversation under NDA.

Passive survey
Custom quote
Zero touch · 2–3 weeks
  • Listen-only asset inventory and traffic analysis
  • Architecture review against your diagrams
  • Undocumented conduit discovery
  • Safe on live plant — nothing transmitted to controllers
Start with a survey
Segmentation test
Custom quote
IT → OT pivot · 4–7 weeks
  • Enterprise foothold to industrial DMZ, adversary-style
  • Identity, remote access and vendor pathway abuse
  • Active work above the agreed level only
  • Full reporting set, all three documents
  • 90-day retest included
Most common
Device programme
Custom quote
Product security · per device
  • Hardware teardown and firmware extraction
  • Debug interface, secure boot and update-chain review
  • Companion app and cloud API testing
  • Pre-certification evidence for product regimes
Test a device
06
Common questions

Before you engage.

Will you break something?

Not by design, and the engagement is structured so that it isn't left to judgement in the moment. Active techniques below the agreed Purdue level are out of scope on live plant — we demonstrate those against lab or vendor-equivalent hardware. Destructive techniques are never in scope. A named engineer of yours can halt everything with a single phrase, and we test that channel before we start.

Can you test without touching production at all?

Yes, and for a first engagement it's often the right call. A passive survey uses span-port capture and transmits nothing to control devices. It reliably finds the things that matter most — undocumented IT/OT conduits, forgotten remote access, assets nobody knew were on the network — with no process risk at all.

Do you need to shut the plant down?

No. Passive work runs during normal operation. Anything active is scheduled into windows you nominate, which for most sites means planned maintenance or a low-demand shift. We plan around your outage calendar rather than asking for one.

How does this map to IEC 62443 or our regulator?

Findings are written against zones and conduits so they drop into an IEC 62443 programme directly, and techniques are referenced to MITRE ATT&CK for ICS. If you report under a sector regime — NERC CIP, NIS2, a national CNI scheme, or a product regime for connected devices — tell us during scoping and the evidence is structured for that audience. We'll also tell you plainly where a red team is not the control an auditor actually wants.

Our devices aren't industrial — we ship consumer IoT. Still relevant?

Yes. The device programme covers connected products generally: teardown, firmware extraction and analysis, debug interfaces left enabled, update-chain and secure-boot weaknesses, and the companion app and cloud API that usually turn out to be the real attack surface. It's frequently bought ahead of a product security certification or a major customer's security review.

How quickly can you start?

Scoping happens under NDA with a written brief inside 72 hours. OT engagements carry a longer runway than IT work because safety planning is real work — typical lead time from signature to first active day is four to six weeks, and passive phases can often begin sooner.

Find the conduit
before they do.

Scoping conversations happen under NDA, with a written brief inside 72 hours. Start with a passive survey if production risk is the thing holding you back.