Skip to main content
OT Atlas

Hunting · Field playbook

Find the threat. Preserve the process.

A practical workflow for investigating OT and supporting IT telemetry using open-source and publicly accessible defensive tools. Start with network behaviour, pivot through logs and indicators, enrich carefully, map activity to ATT&CK, and build an evidence-backed threat hypothesis.

Start the huntExplore threat groups
Last reviewed
  1. 01Telemetry
  2. 02Baseline
  3. 03Anomaly
  4. 04Pivot
  5. 05Enrichment
  6. 06TTPs
  7. 07Attribution hypothesis
  8. 08Escalation

Operational safety comes first

OT threat hunting must respect operational safety and change control. Do not actively scan PLCs, safety controllers, RTUs, field devices, or production control networks unless the asset owner has explicitly approved the activity. The workflows on this page prioritise passive telemetry and offline analysis.

Protect your own data

Never upload proprietary PCAPs, confidential logs, firmware, engineering projects, or sensitive internal binaries to public analysis services. Hash-only lookups reveal nothing about your environment; uploads do.

What you need

Minimum useful telemetry

You do not need everything. You need enough to establish normal in one zone and follow a lead across the boundary.

Network

The highest-value OT telemetry, and the safest to collect. Nothing here touches a controller.

  • NetFlow / IPFIX from boundary and core switches
  • Firewall session logs (allowed and denied)
  • DNS query and response logs
  • DHCP leases for host-to-address resolution over time
  • VPN session logs including source geography
  • Proxy logs for OT-supporting IT
  • Passive packet capture from SPAN or TAP
  • North-south traffic at the IT/OT boundary
  • Remote-access traffic to jump hosts and gateways
Windows

Engineering workstations, HMIs and OT servers are usually Windows. Collect from IT-side and approved OT-supporting hosts only.

  • Security event log — logon, logoff, account and privilege events
  • Sysmon where deployed and approved
  • PowerShell script block and module logging
  • Scheduled task creation and modification
  • Service installation events
  • Interactive, network and remote logon events
  • Process creation with command line
  • SMB share access and file events
  • RDP session events
  • Defender or other endpoint telemetry where available
Linux and Unix

Historians, gateways, appliances and increasingly edge devices.

  • auth.log / secure — authentication outcomes
  • syslog and journald
  • SSH authentication and session records
  • cron and systemd timer activity
  • Process execution auditing where available
  • Package and firmware update events
  • Local network connection state
OT-specific

Collect only where it is already produced and safe to retrieve. Never enable new logging on a live controller without engineering approval and a change record.

  • Engineering workstation application logs
  • HMI audit logs and operator action records
  • SCADA audit trails
  • Historian authentication and query logs
  • OPC server and client logs
  • Controller programming and download records
  • Configuration-change events from asset management tooling
  • Remote-access gateway and jump host session logs
  • Industrial firewall logs
  • Asset inventory export as ground truth

Toolkit

Tools you can obtain and operate yourself

Open-source software is separated from publicly accessible intelligence services — they carry very different data-handling obligations.

Wireshark

Open source

Network & PCAP · Entry · Works offline

Input — PCAP / PCAPNG

  • PCAP inspection
  • Conversation statistics
  • Protocol analysis
  • Stream reconstruction
  • Timing analysis

OT notes — Ships dissectors for Modbus, DNP3, S7comm, ENIP/CIP, IEC 60870-5-104 and BACnet, so OT sessions are readable without custom work. Analyse captures offline on an analyst workstation, not on an OT host.

Project link (opens in a new tab)

tshark

Open source

Network & PCAP · Intermediate · Works offline

Input — PCAP / PCAPNG

  • Command-line packet analysis
  • Bulk field extraction
  • Display filtering
  • Conversation statistics
  • Scripted workflows
tshark -r capture.pcap -q -z conv,tcp

Lists every TCP conversation with byte and packet counts. Low-volume or unexpected peers stand out immediately and become your first leads.

OT notes — The fastest way to triage a large capture before opening the GUI. Everything runs against a saved file — no interaction with the live network.

Project link (opens in a new tab)

Zeek

Open source

Network & PCAP · Intermediate · Works offline

Input — PCAP or live SPAN/TAP

  • Convert PCAP into structured logs
  • Connection metadata
  • DNS, TLS and HTTP records
  • File extraction records
  • Protocol behaviour notices
zeek -Cr capture.pcap

Produces conn.log, dns.log, ssl.log (or tls.log), http.log, files.log and notice.log in the working directory. conn.log is where most OT hunts start.

OT notes — Zeek's ICS protocol packages add Modbus, DNP3, S7comm, ENIP and BACnet logs. Running Zeek against a saved capture is entirely passive.

Project link (opens in a new tab)

zeek-cut

Open source

Network & PCAP · Intermediate · Works offline

Input — Zeek logs

  • Column extraction from Zeek logs
  • Frequency analysis
  • Rare-connection workflows
zeek-cut id.orig_h id.resp_h id.resp_p service < conn.log | sort | uniq -c | sort -n

Counts every source/destination/port/service tuple and sorts ascending, so the rarest communicating pairs appear first. Investigate the top of the list against your asset inventory.

OT notes — The classic offline rarity workflow. Remember that in OT, a once-a-quarter connection is often legitimate maintenance — rarity is a lead, not a verdict.

Project link (opens in a new tab)

Suricata

Open source

Network & PCAP · Intermediate · Works offline

Input — PCAP or live SPAN/TAP

  • Offline PCAP inspection
  • Signature matching
  • Protocol logging
  • IDS alerting
suricata -r capture.pcap -l ./suricata-output

Runs your rule set against a saved capture and writes eve.json and fast.log to the output directory. No packets are sent to the network.

OT notes — Use in offline PCAP mode for hunting. If deployed live, deploy on a TAP or SPAN in detection mode only — never inline on a control network.

Project link (opens in a new tab)

Arkime

Open source

Network & PCAP · Advanced · Works offline

Input — Live capture or PCAP import

  • Indexed packet search
  • Session investigation
  • Large PCAP collections
  • Session-to-session pivoting

OT notes — Valuable at the IT/OT boundary where you want to retain and search weeks of full packet data for retrospective hunts.

Project link (opens in a new tab)

nfdump

Open source

Flow analysis · Intermediate · Works offline

Input — NetFlow / IPFIX

  • Flow analysis
  • Source and destination summaries
  • Traffic volume profiling
  • Port analysis
  • Time-window comparison

OT notes — Flow is often the only telemetry available deep in a plant. It is enough to find new communicating pairs and beacon-like periodicity.

Project link (opens in a new tab)

SiLK

Open source

Flow analysis · Advanced · Works offline

Input — NetFlow / IPFIX

  • Flow aggregation
  • Filtering at scale
  • Historical trend analysis
  • High-volume datasets

OT notes — Well suited to comparing this week's communicating-pair set against a baseline month.

Project link (opens in a new tab)

pmacct

Open source

Flow analysis · Advanced · Works offline

Input — Network interface, NetFlow, sFlow

  • Flow collection
  • Aggregation and export
  • Long-term traffic accounting

OT notes — An open-source collection option where commercial flow collectors are not available.

Project link (opens in a new tab)

Chainsaw

Open source

Log & endpoint · Intermediate · Works offline

Input — Windows EVTX

  • Windows event hunting
  • Sigma rule execution against EVTX
  • Rapid triage of exported logs

OT notes — Works on exported EVTX files, so you can triage an engineering workstation's logs on an analyst machine instead of installing anything on the host.

Project link (opens in a new tab)

Hayabusa

Open source

Log & endpoint · Entry · Works offline

Input — Windows EVTX

  • Fast Windows event triage
  • Timeline generation
  • Detection summaries

OT notes — Produces a compact timeline that pairs well with the log-correlation step of an OT investigation.

Project link (opens in a new tab)

Timesketch

Open source

Log & endpoint · Intermediate · Works offline

Input — Normalised timeline data (CSV, Plaso, JSONL)

  • Collaborative timeline analysis
  • Multi-source correlation
  • Annotating an investigation

OT notes — Useful when OT, IT and engineering all contribute events to a single incident timeline.

Project link (opens in a new tab)

Velociraptor

Open source

Log & endpoint · Advanced · Works offline

Input — Endpoint artefacts

  • Targeted artefact collection
  • Hunting across approved Windows estates
  • Forensic triage packages

OT notes — Use only where collection is operationally approved — IT systems, jump hosts, approved engineering workstations and Windows infrastructure. Do not deploy agents to HMIs, controllers, safety systems or any device under vendor support constraints without written approval.

Agent deployment is a change. Treat it as one: approval, change record, rollback plan, and never on a safety-related device.

Project link (opens in a new tab)

Sigma

Open source

Detection logic · Intermediate · Works offline

Input — Log events

  • Portable behavioural detection logic
  • Sharing detections across SIEM platforms
  • Converting hunt findings into standing detections

OT notes — The natural way to turn a successful one-off OT hunt into a repeatable detection without locking yourself to one SIEM vendor.

Project link (opens in a new tab)

YARA

Open source

Detection logic · Intermediate · Works offline

Input — Files and memory images

  • Local file classification
  • Known malware family matching
  • Suspicious binary pattern hunting

OT notes — Runs entirely locally — the right answer when a sample cannot leave the organisation.

Project link (opens in a new tab)

jq

Open source

Log & endpoint · Entry · Works offline

Input — JSON

  • Structured log analysis
  • Filtering Suricata eve.json
  • Reshaping API and intelligence output

OT notes — Indispensable for working with eve.json, Velociraptor output and threat intelligence exports offline.

Project link (opens in a new tab)

MISP

Open source

Threat intelligence platform · Intermediate · Works offline

Input — Indicators, events, sightings

  • Internally managed indicator sharing
  • Correlation across events
  • Community sharing with sector peers

OT notes — Self-hosted, so indicators derived from your own environment never leave your control. Sector ISACs commonly share through MISP.

Project link (opens in a new tab)

OpenCTI

Open source

Threat intelligence platform · Advanced · Works offline

Input — STIX 2.1 objects

  • Relating actors, malware, campaigns and infrastructure
  • ATT&CK mapping
  • Indicator lifecycle management

OT notes — Self-hosted knowledge graph — a good place to hold your own version of the relationships shown in the Rosetta Stone.

Project link (opens in a new tab)

VirusTotal

Public service

Public intelligence service · Entry · Requires internet

Input — Hashes, files, domains, URLs, IP addresses

  • Hash reputation
  • File relationships
  • Domain, URL and IP context
  • Certificate context
  • Communicating files and passive relationships

OT notes — A public commercial platform, not open-source software. Hash-only lookups reveal nothing about your files; uploads do.

Do not upload confidential binaries, internal files, proprietary engineering software, firmware, or sensitive samples to VirusTotal unless organizational policy explicitly allows it. Prefer hash-only lookups whenever possible.

Project link (opens in a new tab)

MalwareBazaar

Public service

Public intelligence service · Entry · Requires internet

Input — Hashes, samples

  • Known malware sample context
  • Family tagging
  • Hash lookup

OT notes — Query by hash first. Sample submission is public.

Anything submitted becomes available to the research community. Query by hash unless you intend to publish the sample.

Project link (opens in a new tab)

ThreatFox

Public service

Public intelligence service · Entry · Requires internet

Input — IOCs

  • Indicator context
  • Malware family association
  • Bulk IOC export for local matching

OT notes — Export the feed and match locally against your own logs rather than querying every observable individually.

Project link (opens in a new tab)

URLhaus

Public service

Public intelligence service · Entry · Requires internet

Input — URLs, domains

  • Malicious URL infrastructure context
  • Payload delivery tracking

OT notes — Use for context only. Never browse to or probe reported adversary infrastructure.

Project link (opens in a new tab)

AlienVault OTX

Public service

Public intelligence service · Entry · Requires internet

Input — IOCs, pulses

  • Community indicator context
  • Campaign pulses
  • Related-sample discovery

OT notes — A public intelligence platform with community-contributed content — corroborate before acting on any single pulse.

Project link (opens in a new tab)

Methodology

The ten-stage investigation

Work the stages in order. Record what you did at each one.

01Define the hypothesisStart with a falsifiable statement, not a hunch and not an actor name.

A hunt without a hypothesis becomes an aimless log review. Write a single sentence that evidence can disprove, and record it before you look at data.

Workable hypotheses

  • An unauthorized system is communicating from the business network toward OT.
  • A compromised engineering workstation is communicating with infrastructure it does not normally contact.
  • A valid account is being used differently from its established baseline.
  • An external destination may be acting as command-and-control infrastructure.
  • An engineering workstation may have initiated an unusual controller interaction.

Rule

A hypothesis is not an attribution. Naming a threat group at step one biases every subsequent decision.

02Establish the baselineYou cannot find abnormal until normal is written down.

In most plants the baseline is the durable output of hunting — more valuable than any single finding. Capture it in a form the next analyst can reuse.

Baseline these

  • Normal communicating pairs per zone
  • Normal ports, protocols and function usage
  • Normal time-of-day activity profile
  • Normal remote-access sources and accounts
  • Engineering workstation peers
  • Historian peers and query patterns
  • HMI to controller relationships
  • Normal DNS behaviour and resolvers
  • Which assets have any internet access at all
  • Usual administration paths and jump hosts

OT nuance

In OT, 'rare' is often more valuable than 'blocked'. A connection that occurs once every several months may be legitimate maintenance. Context decides.

03Hunt network flowsFlow and firewall data are the cheapest, safest starting point in an industrial environment.

Work top-down: rarity first, then boundary crossings, then administrative protocols. Every step here is read-only analysis of data you already collect.

Rare external destinations

  • First-seen destinations for a host or zone
  • Low-frequency outbound connections
  • Unexpected geographies or hosting providers
  • Destinations contacted by exactly one internal host
  • Unusual session durations
  • Repetitive, periodic connections
  • Any egress from systems that should have none

IT-to-OT boundary crossing

  • New communication from corporate workstations, domain controllers or VPN clients
  • …toward jump hosts, historians, engineering workstations, HMIs or OT servers
  • Approved paths must be baselined first, or everything looks suspicious

Unexpected remote administration

  • RDP, SSH, SMB, WinRM and vendor remote-access sessions on new paths
  • Administrative protocols initiated by hosts that never previously used them
  • Sessions outside declared maintenance windows

Pivot

Source host → destination IP → DNS record → TLS metadata → host process and authentication context.

04PCAP deep divePackets prove what crossed the wire; logs explain who caused it.

Work from a saved capture on an analyst workstation. Nothing in this step generates traffic on a control network.

Procedure

  • Identify the suspicious conversation from flow or Zeek output
  • Extract source and destination, including any NAT translation
  • Determine the protocol and whether it belongs in that zone
  • Review session timing, duration and periodicity
  • Compare against the historical baseline for that pair
  • Inspect DNS and TLS metadata (SNI, certificate, JA3-style fingerprints)
  • Correlate with firewall and host logs for the same window
  • Extract files only where appropriate and permitted
  • Hash extracted artefacts locally
  • Enrich hashes without uploading confidential content

Analyst sidebar

Packet content proves what crossed the wire. Logs help explain who or what caused it. You usually need both to escalate.

05OT protocol investigationPassive, behaviour-focused analysis of industrial protocol traffic.

This step is detection-oriented. It describes what to look for in captured traffic — it does not describe generating, replaying or modifying control commands, and you should never do so on a production network.

Protocols to profile: Modbus TCP, DNP3, S7comm and S7comm-Plus, EtherNet/IP and CIP, OPC UA, BACnet, IEC 60870-5-104, IEC 61850 where supported, and vendor engineering traffic.

Behaviours worth investigating

  • New communicating pairs speaking an industrial protocol
  • A change in command direction between two known peers
  • Write operations where the baseline shows only reads
  • Controller programming or download events
  • Unusual engineering-workstation relationships
  • Industrial protocol use from non-engineering assets
  • First-seen client systems for a controller
  • Protocol use crossing unexpected Purdue levels

Safety boundary

Do not actively poll, scan, fuzz or replay industrial protocol traffic against production devices. Analyse what the network already carried.

06Log correlationBuild one timeline around the suspicious event.

Anchor on the network event, then walk outward in both directions until the story is complete or the evidence runs out.

Events to align on the timeline

  • VPN authentication
  • Windows or Linux logon
  • RDP or SSH session start
  • Process execution with command line
  • PowerShell script block activity
  • Scheduled task or cron creation
  • New service installation
  • SMB session and file access
  • DNS query
  • Firewall session
  • Controller or HMI interaction
  • Configuration change record

Timeline shape

Identity → Host → Network → OT interaction → Follow-on activity. If a link in that chain is missing, say so explicitly in the note.

07Hash triageA decision tree that starts inside your environment, not on the internet.

Internal evidence is authoritative for your estate. Public services add context, not truth.

Order of operations

  • Search internal logs and EDR telemetry for the hash first
  • Search any local malware repository or previous case data
  • Search VirusTotal by hash only
  • Note first-seen and last-seen dates
  • Read detection names sceptically — vendor labels are not families
  • Review the signing certificate and its validity
  • Review contacted domains and IP addresses
  • Review related and similar files
  • Map to a malware family only where evidence supports it
  • Compare with public reporting for that family
  • Sweep the hash across your whole environment

Rule

A hash match can identify a file. It does not prove actor attribution.

08OSINT pivotingExpand from one observable to an infrastructure picture — passively.

Primary chain: Hash → File / malware → Certificate → Domain → Passive DNS → IP → ASN / hosting → Related infrastructure → Other samples → Campaign reporting → Threat-group hypothesis.

Also useful: Domain → IP → TLS certificate → sibling domains, and IP → passive DNS → domains → files → reports.

Hard rule

Do not interact with suspected adversary infrastructure. No probing, no credential attempts, no exploitation, no active scanning. Use passive intelligence sources only.

09Map behaviour to ATT&CKUse both ATT&CK Enterprise and ATT&CK for ICS, and record evidence beside every mapping.

Label every row as Observed, Inferred, or Reported by an external source. Mixing those three is how weak assessments get published.

Example evidence table — every row states its basis.
ObservationEvidenceATT&CKBasisConfidence
Unusual RDP into a jump hostWindows security log + firewall sessionT1021.001ObservedHigh
Rare outbound TLS from historianZeek ssl.log + firewallT1071.001ObservedMedium
Controller programming eventEngineering application logT0843ObservedHigh
Known malicious hash on engineering hostLocal disk + EDRT1204.002ObservedHigh
Credential access from network deviceVendor advisory pattern matchT1552Reported by external sourceLow

Distinguish

Observed = you have the artefact. Inferred = you reasoned from adjacent evidence. Reported = someone else saw it elsewhere.

10Build the attribution hypothesisState a confidence level, and state what would change it.

High confidence — multiple independent behavioural and infrastructure relationships align with authoritative reporting.

Moderate confidence — several characteristics align, but important evidence remains missing.

Low confidence — only limited indicators or generic behaviour overlap.

Insufficient evidence — no defensible actor assessment. This is a legitimate and common outcome.

Never

Never attribute a threat group based only on an IP, domain, filename, hash label, malware name, country, or one ATT&CK technique.

Enrichment

Passive pivot paths

Every step below is a lookup against passive sources. None of it touches adversary infrastructure.

Primary chain

  1. Hash
  2. File / malware
  3. Certificate
  4. Domain
  5. Passive DNS
  6. IP
  7. ASN / hosting
  8. Related infrastructure
  9. Other samples
  10. Campaign reporting
  11. Threat-group hypothesis

Domain-first

  1. Domain
  2. IP
  3. TLS certificate
  4. Sibling domains
  5. Registration data

Address-first

  1. IP
  2. Passive DNS
  3. Domains
  4. Files
  5. Public reports

Do not touch adversary infrastructure

No probing, no credential attempts, no exploitation, no active scanning of suspected adversary hosts. Passive intelligence sources only — active interaction alerts the adversary and can create legal exposure.

Hunt packs

Reusable hunts you can run this week

Each pack states its hypothesis, the telemetry it needs, the baseline it assumes, and the threat groups publicly reported using similar behaviour.

NetworkRare external destination from an OT-supporting host

Hypothesis

A host that supports operations is communicating with an external destination it has never contacted before.

Why it matters

OT-supporting hosts have small, stable egress profiles. A genuinely new external peer is one of the highest-signal leads available.

Required telemetry

  • NetFlow / IPFIX
  • Firewall session logs
  • DNS logs
  • Zeek conn.log and ssl.log

Baseline first

Set of external destinations per OT-supporting host over 90 days.

Escalation condition

Destination has no business justification and the source host can reach OT assets.

Procedure

  1. 01Extract all external destinations per source host for the hunt window
  2. 02Subtract the 90-day baseline set to leave first-seen destinations
  3. 03Resolve each destination through DNS logs and passive DNS
  4. 04Check hosting provider, ASN and certificate details
  5. 05Correlate with process and authentication events on the source host

Evidence to collect

  • Flow records
  • Firewall session entries
  • DNS resolution chain
  • TLS certificate details
  • Host process context

Common false positives

  • New vendor cloud service
  • Software or firmware update endpoints
  • Newly enrolled monitoring agents
  • CDN address churn for an existing service

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

NetworkNew IT-to-OT communication path

Hypothesis

A corporate system has begun communicating with an OT asset over a path that is not in the approved conduit list.

Why it matters

Almost every published OT intrusion crossed this boundary using a path someone had forgotten about.

Required telemetry

  • Boundary firewall logs
  • NetFlow at the DMZ
  • Zeek conn.log
  • Conduit / firewall policy documentation

Baseline first

Documented approved conduits with source, destination, port and business owner.

Escalation condition

Any unapproved path terminating at Level 2 or below.

Procedure

  1. 01List every distinct source/destination/port tuple crossing the boundary
  2. 02Diff against the approved conduit list
  3. 03For each unapproved tuple, identify owning system and business purpose
  4. 04Confirm whether a firewall rule change preceded the traffic
  5. 05Escalate anything reaching engineering workstations, historians or controllers

Evidence to collect

  • Boundary flow records
  • Firewall rule change history
  • Asset inventory entries for both endpoints

Common false positives

  • Approved but undocumented conduits
  • Temporary project connectivity
  • Backup and patching infrastructure

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

NetworkUnexpected engineering workstation peer

Hypothesis

An engineering workstation is communicating with a system outside its normal peer set.

Why it matters

The engineering workstation is the bridge between IT-style compromise and controller-level consequence.

Required telemetry

  • Zeek conn.log
  • Windows security and process logs
  • Engineering application logs
  • Firewall logs

Baseline first

Peer set, protocols and time profile for each engineering workstation.

Escalation condition

New peer is external, or the workstation contacted a controller with no change record.

Procedure

  1. 01Enumerate all peers per engineering workstation for the window
  2. 02Diff against baseline peer set
  3. 03Classify each new peer: controller, server, IT host, external
  4. 04Correlate with logged-on user and running processes
  5. 05Check for archive creation or bulk file access on the host

Evidence to collect

  • Connection records
  • Logon events
  • Process creation events
  • File access records

Common false positives

  • Commissioning of new equipment
  • Engineer working on an unfamiliar cell
  • Vendor support session

ATT&CK mappings

Groups reported using similar behaviour

NetworkEngineering workstation communicating externally

Hypothesis

An engineering workstation has direct or proxied internet egress.

Why it matters

Most engineering hosts should have no internet path at all. Any egress is both a finding and a control gap.

Required telemetry

  • Proxy logs
  • Firewall egress logs
  • DNS logs
  • NetFlow

Baseline first

Documented egress policy for engineering hosts (ideally: none).

Escalation condition

Sustained or encrypted egress with no approved business purpose.

Procedure

  1. 01Identify all egress attempts, allowed and denied, from engineering hosts
  2. 02Group by destination category and volume
  3. 03Investigate any allowed egress that is not an approved update service
  4. 04Check for tunnelling software or remote-support agents on the host

Evidence to collect

  • Proxy and firewall records
  • Installed software inventory
  • Process network connections

Common false positives

  • Approved vendor update services
  • Licence activation servers
  • Time synchronisation

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

Remote accessNew remote-access source

Hypothesis

Remote access into the environment originated from a source that has not been seen before.

Why it matters

Edge devices and remote access are the most consistently reported initial-access path into OT-supporting networks.

Required telemetry

  • VPN logs
  • Remote access gateway logs
  • Jump host session logs
  • Firewall logs

Baseline first

Historical source addresses, geographies, devices and accounts per remote-access user.

Escalation condition

New source reached OT-supporting systems, or MFA was bypassed or absent.

Procedure

  1. 01List all successful remote-access sessions with source address and account
  2. 02Diff sources and geographies against the per-account baseline
  3. 03Check authentication method used and whether MFA was satisfied
  4. 04Trace what each new-source session reached after connecting

Evidence to collect

  • VPN session records
  • Authentication logs
  • Post-connection flow records

Common false positives

  • Staff travel
  • ISP address changes
  • New corporate egress ranges

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

IdentityAbnormal RDP usage

Hypothesis

RDP is being used along a path or at a time that does not match administrative practice.

Why it matters

RDP is the workhorse of lateral movement into OT-supporting Windows estates.

Required telemetry

  • Windows security logs (4624 type 10, 4648)
  • Firewall session logs
  • Jump host logs

Baseline first

Approved administrative source hosts, accounts and maintenance windows.

Escalation condition

RDP chain terminating on an OT-supporting host from a non-administrative source.

Procedure

  1. 01Extract all RDP logons with source host and account
  2. 02Diff source hosts against the administrative host inventory
  3. 03Flag sessions outside maintenance windows
  4. 04Check for chained sessions (workstation → server → OT host)

Evidence to collect

  • Logon events with source
  • Session duration
  • Chained session graph

Common false positives

  • Emergency support
  • New administrator
  • Helpdesk tooling

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

IdentityAbnormal SSH usage

Hypothesis

SSH sessions are reaching Linux-based OT infrastructure from unexpected sources or accounts.

Why it matters

Historians, gateways and appliances often accept SSH with weakly governed keys.

Required telemetry

  • auth.log / secure
  • Appliance session logs
  • Firewall logs
  • Zeek conn.log

Baseline first

Approved SSH sources, accounts and key inventory per host.

Escalation condition

Unmanaged key, or privileged logon from outside the administrative range.

Procedure

  1. 01Extract all successful SSH authentications with source and method
  2. 02Identify key-based logons whose key is not in the managed inventory
  3. 03Flag root or shared-account logons
  4. 04Correlate with subsequent command execution where auditing exists

Evidence to collect

  • Authentication records
  • Key fingerprints
  • Session flow records

Common false positives

  • Automation and monitoring accounts
  • Vendor maintenance
  • Newly issued keys

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

EndpointLiving-off-the-land behaviour

Hypothesis

Built-in operating system tooling is being used for discovery, credential access or movement outside normal administration.

Why it matters

The most consistently reported OT-adjacent intrusion tradecraft uses no malware at all.

Required telemetry

  • Process creation with command line
  • PowerShell script block logs
  • Windows security logs
  • Sysmon where deployed

Baseline first

Which administrative binaries are normally executed, by whom, on which hosts.

Escalation condition

Discovery chain followed by credential-access tooling or boundary traversal.

Procedure

  1. 01Extract execution of discovery and administration binaries (wmic, netsh, net, nltest, ntdsutil, reg, vssadmin, tasklist)
  2. 02Filter to hosts and accounts where such execution is not routine
  3. 03Look for chained discovery within short windows
  4. 04Check for volume shadow copy or NTDS access attempts
  5. 05Correlate with remote-access sessions and boundary flows

Evidence to collect

  • Process command lines
  • Parent-child process chains
  • Account context
  • Correlated network sessions

Common false positives

  • Administrator scripting
  • Inventory and compliance tooling
  • Software deployment agents

Groups reported using similar behaviour

Related Atlas content

EndpointSuspicious PowerShell

Hypothesis

PowerShell is executing encoded, downloaded or obfuscated content on an OT-supporting host.

Why it matters

PowerShell provides download, execution, credential access and lateral movement in one signed binary.

Required telemetry

  • Script block logging (4104)
  • Module logging (4103)
  • Process creation (4688)
  • Proxy and DNS logs

Baseline first

Which hosts legitimately run PowerShell automation and what those scripts look like.

Escalation condition

Downloaded content executed on a host with a path to OT.

Procedure

  1. 01Extract script block events containing encoding, download or reflection patterns
  2. 02Group by host and account, excluding known automation
  3. 03Reconstruct multi-part script blocks before judging intent
  4. 04Correlate any download URL with proxy and DNS records

Evidence to collect

  • Reconstructed script content
  • Process ancestry
  • Network fetch records

Common false positives

  • Legitimate management scripts
  • Vendor installers
  • Monitoring agents

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

EndpointNew scheduled task

Hypothesis

A scheduled task was created on an OT-supporting host outside change control.

Why it matters

Scheduled tasks are the quietest durable persistence available on Windows and require no malware.

Required telemetry

  • Windows event 4698 / 4702
  • Task Scheduler operational log
  • Process creation
  • Change records

Baseline first

Inventory of legitimate scheduled tasks per host role.

Escalation condition

Task runs an interpreter or unsigned binary, or runs as SYSTEM with no change record.

Procedure

  1. 01Extract task creation and modification events for the window
  2. 02Diff against the per-role task inventory
  3. 03Inspect the action, trigger and run-as account for each new task
  4. 04Correlate creation time with logon and remote-access events

Evidence to collect

  • Task XML definition
  • Creating account and source session
  • Subsequent executions

Common false positives

  • Patch and deployment tooling
  • Vendor software installs
  • Backup jobs

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

EndpointNew service creation

Hypothesis

A new Windows service was installed on an OT-supporting host.

Why it matters

Service installation is both a persistence technique and a common precursor to remote execution tooling.

Required telemetry

  • Windows event 7045 and 4697
  • Process creation
  • File system telemetry
  • Change records

Baseline first

Expected service set per host role.

Escalation condition

Unsigned binary, temp-directory path, or randomly named service.

Procedure

  1. 01Extract service installation events for the window
  2. 02Diff against the expected service set for that role
  3. 03Review binary path, signature status and location
  4. 04Correlate with the session that installed it

Evidence to collect

  • Service name and binary path
  • Signature status
  • Installing account

Common false positives

  • Legitimate software installation
  • Vendor support tooling
  • Agent upgrades

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

NetworkDNS anomalies

Hypothesis

DNS is being used as a command-and-control or exfiltration channel from an OT-supporting network.

Why it matters

DNS is frequently permitted outbound even where nothing else is.

Required telemetry

  • DNS query logs
  • Zeek dns.log
  • Firewall UDP/53 sessions
  • Proxy logs

Baseline first

Normal query volume, domain diversity and resolver usage per host.

Escalation condition

Sustained tunnelling pattern from a host with OT reachability.

Procedure

  1. 01Rank hosts by unique domains queried and total query volume
  2. 02Look for long labels, high entropy and unusual record types
  3. 03Identify hosts bypassing approved resolvers
  4. 04Correlate resolved addresses with subsequent connections

Evidence to collect

  • Query records with timestamps
  • Domain entropy statistics
  • Resolver used
  • Follow-on connections

Common false positives

  • Security product telemetry
  • CDN and cloud service churn
  • Misconfigured resolvers

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

NetworkLong-lived, low-volume connections

Hypothesis

A session has stayed open for an unusually long time while transferring very little data.

Why it matters

Tunnels and interactive backdoors look exactly like this, and they hide well in busy flow data.

Required telemetry

  • NetFlow / IPFIX
  • Zeek conn.log
  • Firewall session logs

Baseline first

Normal session duration and byte-count distribution per service.

Escalation condition

Long-lived session to an external or unapproved destination.

Procedure

  1. 01Filter sessions above a duration threshold and below a byte threshold
  2. 02Group by source, destination and service
  3. 03Exclude known keep-alive and monitoring services
  4. 04Investigate remaining sessions with host and identity context

Evidence to collect

  • Session duration and byte counts
  • Service classification
  • Host process context

Common false positives

  • Monitoring and polling services
  • OT protocols with persistent sessions
  • Remote console sessions left open

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

NetworkBeacon-like periodic connections

Hypothesis

A host is contacting a destination at a regular interval consistent with automated check-in.

Why it matters

Periodicity survives encryption. You do not need to see the payload to see the rhythm.

Required telemetry

  • NetFlow / IPFIX
  • Zeek conn.log
  • Proxy logs

Baseline first

Known polling intervals of legitimate OT and IT services — OT is full of legitimate periodicity.

Escalation condition

Regular check-in to an external destination with no owner.

Procedure

  1. 01Compute inter-arrival times per source/destination pair
  2. 02Flag pairs with low variance in interval
  3. 03Exclude documented polling services and their intervals
  4. 04Check jitter, byte-count consistency and destination reputation

Evidence to collect

  • Interval distribution
  • Byte-count consistency
  • Destination context

Common false positives

  • SCADA polling
  • Historian collection
  • Update checks
  • Monitoring agents

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

EndpointFirst-seen executable hash

Hypothesis

An executable never before observed in the environment appeared on an OT-supporting host.

Why it matters

OT estates change slowly. A genuinely new binary on an engineering host is worth a look.

Required telemetry

  • Process creation with hash
  • EDR file events
  • Software inventory

Baseline first

Hash inventory of executables observed across the estate.

Escalation condition

Unsigned binary in a user-writable path with no software record.

Procedure

  1. 01Extract executed hashes for the window
  2. 02Diff against the environment hash baseline
  3. 03Check signature and publisher for each new hash
  4. 04Perform hash-only reputation lookup
  5. 05Sweep the estate for other occurrences

Evidence to collect

  • Hash values
  • File path and signer
  • Execution context
  • Prevalence in the estate

Common false positives

  • Software updates
  • Vendor tooling
  • Engineer utilities

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

EndpointKnown malicious hash present

Hypothesis

A hash matching public malicious reporting exists in the environment.

Why it matters

Confirmation is quick, but scope is what matters — one match is never the whole story.

Required telemetry

  • EDR telemetry
  • Process creation logs
  • File inventory
  • Backup indexes

Baseline first

Not applicable — this is a matching hunt.

Escalation condition

Any confirmed match on a host that can reach OT assets.

Procedure

  1. 01Match your curated malicious hash list against local telemetry
  2. 02For any hit, preserve the artefact and its metadata before anything else
  3. 03Establish first appearance and delivery path
  4. 04Sweep for the same hash and for related file names and paths
  5. 05Only then consult public sources for family context

Evidence to collect

  • File and hash
  • Creation timestamps
  • Delivery path
  • Execution history

Common false positives

  • Security tooling quarantine copies
  • Deliberate test samples
  • Stale detection lists

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

OT protocolProtocol use from an unexpected Purdue level

Hypothesis

An industrial protocol is being used across a Purdue boundary where it should not appear.

Why it matters

Level discipline is the architectural control. Traffic that ignores it usually means a forgotten path or a compromise.

Required telemetry

  • Zeek ICS logs
  • Boundary firewall logs
  • NetFlow
  • Asset inventory with level assignment

Baseline first

Which protocols are expected between each pair of levels.

Escalation condition

Programming-capable protocol crossing from Level 3 or above directly to Level 1.

Procedure

  1. 01Map every industrial protocol session to source and destination Purdue level
  2. 02Flag sessions that skip a level or cross an unapproved boundary
  3. 03Identify the owning system and business purpose for each
  4. 04Verify against the conduit documentation

Evidence to collect

  • Session records with level annotation
  • Asset inventory entries
  • Conduit documentation

Common false positives

  • Flat networks that predate segmentation
  • Temporary project connectivity
  • Incorrect level assignment in inventory

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

OT protocolUnexpected controller write or programming behaviour

Hypothesis

A controller received a write or programming operation that does not match an approved change.

Why it matters

Controller logic defines physical behaviour. This is the highest-consequence event class in the environment.

Required telemetry

  • Passive protocol metadata
  • Controller audit logs where supported
  • Engineering software logs
  • Change records

Baseline first

Which hosts perform writes or downloads, to which controllers, in which windows.

Escalation condition

Any programming event without a change record, and any event involving a safety controller.

Procedure

  1. 01Identify every source that issued a write or programming function in the window
  2. 02Diff against the approved engineering host inventory
  3. 03Match each event to a change record and a named engineer
  4. 04Compare controller program checksums with the known-good baseline
  5. 05Review authentication events on the source host around each event

Evidence to collect

  • Protocol metadata for the session
  • Controller audit entries
  • Change record
  • Checksum comparison

Common false positives

  • Emergency changes without paperwork
  • Vendor commissioning
  • Online edits during troubleshooting

ATT&CK mappings

Groups reported using similar behaviour

OT protocolNew ICS protocol communicating pair

Hypothesis

Two devices are speaking an industrial protocol to each other for the first time.

Why it matters

Industrial communication topology is close to static. New pairs are rare and meaningful.

Required telemetry

  • Zeek ICS logs
  • OT IDS session data
  • NetFlow
  • Asset inventory

Baseline first

Full communicating-pair matrix per protocol over at least 30 days.

Escalation condition

New client to a controller from a host with no engineering role.

Procedure

  1. 01Build the current pair matrix per protocol
  2. 02Diff against the baseline matrix
  3. 03Classify each new pair by device role
  4. 04Determine whether a project, commissioning or maintenance activity explains it

Evidence to collect

  • Pair matrix diff
  • Session timestamps
  • Asset inventory roles

Common false positives

  • New equipment commissioning
  • Redundancy failover to a standby server
  • Device replacement with a new address

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

Remote accessNew vendor remote-access path

Hypothesis

A vendor is connecting through a path or tool that is not part of the approved remote-access design.

Why it matters

Vendor connectivity is the most commonly under-governed access into OT.

Required telemetry

  • Remote-access gateway logs
  • Firewall logs
  • Installed software inventory
  • Vendor access register

Baseline first

Approved vendor accounts, tools, hours and target systems.

Escalation condition

Unsupervised, always-on vendor access reaching Level 2 or below.

Procedure

  1. 01List all vendor-account sessions and the tools used
  2. 02Identify any remote-support software not in the approved list
  3. 03Check whether sessions were supervised and time-bounded
  4. 04Trace what each session reached

Evidence to collect

  • Session records
  • Tool identification
  • Supervision records
  • Target systems reached

Common false positives

  • Approved emergency support
  • Vendor tool upgrades
  • New contract not yet registered

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

IdentityAccount used from a new host

Hypothesis

A valid account authenticated from a host it has never used before.

Why it matters

When the tradecraft is living-off-the-land, valid-account anomalies are frequently the only signal available.

Required telemetry

  • Windows security logs
  • VPN logs
  • Linux auth logs
  • Directory sign-in logs

Baseline first

Host set per account over 90 days.

Escalation condition

Privileged or engineering account from an unmanaged host.

Procedure

  1. 01Build the account-to-host matrix for the window
  2. 02Diff against the 90-day baseline
  3. 03Prioritise privileged and engineering accounts
  4. 04Correlate with remote access sessions and subsequent activity

Evidence to collect

  • Authentication events
  • Source host identification
  • Follow-on session activity

Common false positives

  • Hardware refresh
  • Role change
  • Shared engineering workstations

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

IdentityAccount used outside the expected maintenance window

Hypothesis

An account with a strictly scheduled purpose was used outside its window.

Why it matters

OT work is scheduled work. Off-schedule use of a maintenance account is a strong, low-noise signal.

Required telemetry

  • Authentication logs
  • Change management calendar
  • Remote-access logs

Baseline first

Declared maintenance windows per account and per system.

Escalation condition

Off-window use with no emergency change and OT reachability.

Procedure

  1. 01Join authentication events to the maintenance calendar
  2. 02Extract events outside declared windows
  3. 03Confirm each against emergency change records
  4. 04Escalate unexplained off-window privileged use

Evidence to collect

  • Authentication timestamps in UTC
  • Calendar entries
  • Change records

Common false positives

  • Emergency work
  • Time zone confusion between records
  • Automation running on a different schedule

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

Remote accessNew VPN geography

Hypothesis

A remote-access session originated from a country or network the account has never used.

Why it matters

Cheap to run, easy to explain to management, and effective against credential reuse.

Required telemetry

  • VPN logs with source address
  • Directory sign-in logs
  • Geolocation reference data

Baseline first

Country and ASN set per account.

Escalation condition

Unexplained new geography combined with access to OT-supporting systems.

Procedure

  1. 01Geolocate all remote-access sources for the window
  2. 02Diff against the per-account country and ASN baseline
  3. 03Check for impossible travel between consecutive sessions
  4. 04Confirm travel with the account owner through an out-of-band channel

Evidence to collect

  • Session source addresses
  • Geolocation and ASN
  • Session sequence timing

Common false positives

  • Genuine travel
  • VPN and privacy services used by staff
  • Inaccurate geolocation data

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

NetworkHistorian communicating with an unknown internet host

Hypothesis

A process historian is exchanging data with an external destination that is not an approved service.

Why it matters

The historian holds the process record. Exfiltration from it is quiet and highly informative to an adversary.

Required telemetry

  • Firewall egress logs
  • NetFlow
  • Historian application and authentication logs
  • DNS logs

Baseline first

Approved historian integrations and their destinations.

Escalation condition

Unapproved destination with meaningful outbound volume.

Procedure

  1. 01List all external destinations contacted by historian systems
  2. 02Diff against the approved integration list
  3. 03Review historian query and authentication logs for the same window
  4. 04Assess data volume against normal integration volume

Evidence to collect

  • Egress records with byte counts
  • Historian query logs
  • Authentication events

Common false positives

  • Cloud analytics integrations
  • Vendor support telemetry
  • Reporting services

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

NetworkFirewall policy path unexpectedly exercised

Hypothesis

A permissive firewall rule that normally sees no traffic has started being used.

Why it matters

Every environment has legacy rules nobody dares remove. The day one starts carrying traffic is the day to look.

Required telemetry

  • Firewall rule hit counters
  • Session logs with rule identifiers
  • Policy documentation

Baseline first

Rule hit-count profile over the previous quarter.

Escalation condition

Newly active permissive rule carrying traffic toward OT.

Procedure

  1. 01Export rule hit counts and compare against the baseline period
  2. 02Identify rules moving from zero to non-zero
  3. 03Inspect the sessions matching each newly active rule
  4. 04Feed the result into rule cleanup as well as the investigation

Evidence to collect

  • Rule hit deltas
  • Matching session records
  • Rule ownership documentation

Common false positives

  • New project traffic
  • Failover paths becoming active
  • Test activity

ATT&CK mappings

Groups reported using similar behaviour

Related Atlas content

Documentation

Investigation note template

Copy this into your case system. Times in UTC.

Copyable template

OT HUNT INVESTIGATION NOTE
==========================
Hunt ID:
Analyst:
Date / UTC window:        [YYYY-MM-DDTHH:MMZ] to [YYYY-MM-DDTHH:MMZ]

HYPOTHESIS
  Statement:
  Falsifiable by:

ENVIRONMENT
  Site / zone:
  Purdue levels in scope:
  Process criticality:

SYSTEMS INVOLVED
  Host / asset            Role                Purdue level

EVIDENCE SOURCES
  [ ] NetFlow / IPFIX     [ ] Firewall logs   [ ] PCAP
  [ ] DNS                 [ ] VPN             [ ] Windows logs
  [ ] Linux logs          [ ] Historian       [ ] EWS logs
  [ ] Remote access       [ ] Controller audit

TIMELINE (all times UTC)
  Timestamp               Event               Source of record

INDICATORS
  Type      Value                             Context

BEHAVIOURS OBSERVED

ATT&CK MAPPINGS
  Observation             Technique           Basis (observed/inferred/reported)

THREAT INTELLIGENCE REFERENCES
  Publisher / title / date / URL

ATTRIBUTION CONFIDENCE
  [ ] High  [ ] Moderate  [ ] Low  [ ] Insufficient evidence
  Rationale:
  What would change this assessment:

OPERATIONAL IMPACT ASSESSMENT
  Process affected:
  Safety implications:
  Availability implications:

ESCALATION DECISION
  Escalated to:
  Time (UTC):

CONTAINMENT RECOMMENDATION
  (Coordinated with operations before any action touching the process)

EVIDENCE PRESERVATION
  Artefacts collected:
  Storage location / hash manifest:

FOLLOW-UP HUNTS

Why should I care?

The durable output of a hunt is rarely a detection. It is a written baseline, a documented conduit, and a note the next analyst can pick up six months from now.