Hunt playbook
Default Credentials and Internet-Exposed Field Devices
Find control devices that are reachable from the internet or still using factory-default credentials, before an opportunistic actor does.
Hypothesis
One or more control devices are internet-reachable, still hold factory-default credentials, or both.
Why this hunt matters
The 2023 targeting of Unitronics controllers at US water utilities required no exploit — only a device on the public internet with an unchanged default password. This is the highest-yield, lowest-effort hunt available to a small operator.
Scope
Assets: plc, hmi, rtu, remote-access-gateway, iiot-gateway
Protocols: pcom, modbus-tcp, ethernet-ip, bacnet-ip, dnp3
Data sources required
- External attack-surface scan of owned and cellular-carrier address ranges
- Internet-exposure search services (Shodan, Censys) filtered to your ASN and site addresses
- Firewall and cellular router NAT / port-forward configuration
- Device account inventories and vendor default-credential lists
- Inbound connection logs at each remote site
Baseline needed first
- No control device is directly reachable from the internet; remote access is brokered through a gateway with multi-factor authentication
- Every device has a site-unique password recorded in a credential store
Hunt steps
- 01Enumerate every public address the organisation holds, including cellular SIM pools and contractor-provided links
- 02Scan those ranges for control-protocol ports — 20256/TCP and 5900/TCP (Unitronics), 502, 44818, 20000, 47808 and any vendor-specific port in use
- 03Cross-check public exposure search services for your organisation name, ASN and site addresses
- 04Pull NAT and port-forward rules from every site router and cellular gateway; treat each rule as a finding until justified
- 05Test each reachable device against the vendor default credential for that family, with change authorisation
- 06Review device and gateway logs for successful authentication from source addresses outside the operating region
- 07Confirm each site has a documented manual operating procedure if the controller must be taken offline
Indicators of interest
- A control protocol port answering from a public address
- Successful login from a foreign or hosting-provider source address
- Device password matching the vendor default
- An HMI screen, device name or setpoint changed with no work order
- A port-forward rule that no one can attribute to a project
Triage
- What process does the device control, and what happens if it is manipulated?
- How long has the exposure existed, and do logs cover that period?
- Is there evidence of successful authentication, or only connection attempts?
- Does the site have a manual fallback?
Likely false positives
- Vendor or integrator remote-support access that is authorised but poorly documented
- Carrier-grade NAT making a device appear reachable in a scan when it is not
- Honeypots or test units deliberately exposed by a security team
Escalation
- Any successful authentication from an unexpected source
- Any exposed device controlling a safety-related or public-health process
- Evidence of program download, setpoint change or HMI defacement
Containment options
- Remove the port forward or place the device behind a VPN before anything else
- Rotate the device password and any shared site credential
- Restore the program and HMI screens from a known-good offline backup if tampering is suspected
- Move the site to manual operation while integrity is being confirmed
Validation
- Repeat external scan returns no control-protocol ports
- Credential inventory shows a unique, non-default password per site
- Recurring monthly exposure scan is scheduled and owned
Why should I care?
Containment in OT is a joint decision. Isolating a device can be the safest action or the one that stops production — operations decides, security advises.