1200kmSECURITY RESEARCH
Loading interactive filters…

1200KM / simulation

T1691 Block Operational Technology Message — Attack Simulation

Adversaries may block messages between systems and devices in an OT/ICS environment to disrupt processes. Messages typically fall into two categories: (1) reporting messages that contain telemetry data about the current state of systems, devices, and processes and (2) command messages that contain instructions to control systems, devices, and processes. Both types of messages are critical for the proper functioning of industrial control…

Complete technique description

Adversaries may block messages between systems and devices in an OT/ICS environment to disrupt processes. Messages typically fall into two categories: (1) reporting messages that contain telemetry data about the current state of systems, devices, and processes and (2) command messages that contain instructions to control systems, devices, and processes. Both types of messages are critical for the proper functioning of industrial control processes and failure of the messages to reach their intended destinations could inhibit response functions or create an unsafe condition that could have physical impacts.[Bonnie Zhu, Anthony Joseph, Shankar Sastry 2011][Electricity Information Sharing and Analysis Center; SANS Industrial Control Systems March 2016]

Adversaries may block communications by either making modifications to software (System Firmware, Module Firmware, Hooking, and Rootkit) and services (Service Stop, Denial of Service) on systems and devices or by positioning themselves between systems and devices and intercepting and blocking the communications such as the case with an Adversary-in-the-Middle attack.

Official technique definition · Open in the interactive matrix

Parent and sub-techniques

Related pages are navigation context. Their tools, rules and lab results are not automatically inherited.

Detection telemetry and configuration

These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.

Network Traffic Flow · source-mapped

DC0078 collection page — Collect Zeek conn.log, Suricata flow events or exporter equivalents, including observation point and sampling settings.

Providers and collection configuration

  • Zeek: Connection and protocol metadata from traffic visible to the sensor.
  • Suricata EVE: Configured flow, alert, DNS, HTTP, TLS and protocol records.
  • AWS VPC Flow Logs: IP traffic metadata alternative; no packet payload or DNS answer history, and some traffic is not logged.
  • Use an authorized lab TAP/SPAN, virtual mirror or gateway interface. Define which traffic crosses it; avoid assuming visibility into every segment.
  • Enable the required Zeek analyzers or Suricata EVE event types. Export logs with sensor identity, clock synchronization and flow correlation identifiers.
  • Monitor capture loss, truncation and exporter sampling. Capture payload only with approval and restrictive retention; encryption normally prevents plaintext inspection.

Required normalized fields: source_ip, destination_ip, destination_port, protocol, bytes_sent, bytes_received.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0078",
  "collector": "illustrative-lab-collector",
  "observation": {
    "source_ip": "192.0.2.10",
    "destination_ip": "198.51.100.20",
    "destination_port": 443,
    "protocol": "tcp",
    "bytes_sent": 128,
    "bytes_received": 512
  }
}

Visibility limits: Flows are not packet payloads. NAT, asymmetric routes, encryption, missing mirrors and sampling can hide attribution or content. A destination connection alone does not prove malicious intent.

Process Creation · source-mapped

DC0032 collection page — Collect Sysmon ProcessCreate (1); preserve ProcessGuid and parent identifiers. Security 4688 is an alternative with separate audit/command-line settings.

Providers and collection configuration

  • Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
  • Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
  • Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.
  • On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
  • Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
  • For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_guid, image, parent_image, command_line, user.

<EventFiltering>
  <ProcessCreate onmatch="include">
    <Image condition="is">C:\Windows\System32\whoami.exe</Image>
  </ProcessCreate>
</EventFiltering>

This fragment only selects the named process. It is not a complete production policy. Inspect the installed schema with sysmon64 -s; preserve existing rules, then apply the reviewed complete configuration with sysmon64 -c <configuration-file>.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0032",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "image": "C:\\Windows\\System32\\whoami.exe",
    "parent_image": "C:\\Windows\\System32\\cmd.exe",
    "command_line": "whoami",
    "user": "LAB\\analyst"
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

Process/Event Alarm · source-mapped

DC0109 collection page — Export alarm/event history with setpoint context and lifecycle transitions; retain suppressed/shelved state when provided.

Providers and collection configuration

  • Agree the measurement points, read-only interfaces, sampling intervals and safety boundary with the process owner. Use a simulator or non-production fixture.
  • Subscribe to supported audit/alarm events or approved historian exports. Preserve source timestamp, quality, engineering units, asset/tag identity and clock offset.
  • Compare independent measurements and record gaps/latency. Do not enable intrusive polling, change controller logic or alter safety setpoints merely to generate logs.

Required normalized fields: tag, alarm, threshold, value, acknowledged.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0109",
  "collector": "illustrative-lab-collector",
  "observation": {
    "tag": "LAB.TankLevel",
    "alarm": "high_level",
    "threshold": 80,
    "value": 82,
    "acknowledged": false
  }
}

Visibility limits: There is no universal PLC event ID or configuration command. Visibility depends on vendor, protocol and process. An alarm or process deviation demonstrates an effect, not necessarily a cyberattack.

Detection rules and analytic guidance

Open the dedicated detection workspace · Existing query engineering

DET0903 Detection of Block Operational Technology Message

MITRE detection strategy

AN2046 Analytic 2046

Real-time monitoring identifies iptables/nftables rule changes on Industrial Control System (ICS) Linux gateways that selectively block one ICS communication traffic type. OT operational-fidelity gate: Alert only when the action is not attributable to an authorized operator/engineering source for the specific target and function, and it is either outside an approved change/maintenance window or lacks matching change-control context; where telemetry permits, require corroborating device, configuration, or process-state effect. Suppress activity that fully matches approved maintenance, commissioning, failover, recovery, or tested control procedures.

Platforms: Linux.

  • Process Creation — auditd:SYSCALL; channel Linux Audit SYSCALL/EXECVE/SOCKADDR records (configured audit rule): syscall=execve; command line invokes iptables/nftables to change ICS traffic filtering or redirection outside the authorized network-administration baseline.

AN2213 Analytic 2213

Real-time monitoring identifies an abrupt cessation of expected Industrial Control System (ICS) protocol traffic between a Supervisory Control and Data Acquisition (SCADA)/control server and a field device, without a corresponding device alarm or scheduled maintenance event, while the device remains reachable for at least some traffic types. This technique-level analytic synthesizes Command Message blocking (T1691.001) and Reporting Message blocking (T1691.002). OT operational-fidelity gate: Alert only when the action is not attributable to an authorized operator/engineering source for the specific target and function, and it is either outside an approved change/maintenance window or lacks matching change-control context; where telemetry permits, require corroborating device, configuration, or process-state effect. Suppress activity that fully matches approved maintenance, commissioning, failover, recovery, or tested control procedures.

Platforms: Embedded.

  • Process/Event Alarm — operationaldb:AlarmEvent; channel expected communication absent for device_ip without corresponding device-generated alarm explaining the gap.
  • Network Traffic Flow — NSM:Connections; channel one Industrial Control System (ICS) traffic type (command or reporting) to/from device_ip ceases while other traffic types continue normally.

AN2266 Analytic 2266

Real-time monitoring identifies Windows host-based firewall or network policy changes that selectively block Industrial Control System (ICS) communication traffic types from Supervisory Control and Data Acquisition (SCADA)/Distributed Control System (DCS) hosts. OT operational-fidelity gate: Alert only when the action is not attributable to an authorized operator/engineering source for the specific target and function, and it is either outside an approved change/maintenance window or lacks matching change-control context; where telemetry permits, require corroborating device, configuration, or process-state effect. Suppress activity that fully matches approved maintenance, commissioning, failover, recovery, or tested control procedures.

Platforms: Windows.

No structured log-source mapping supplied by this analytic.

Source rule directory and observation requirements

No exact-tagged Sigma source rule was imported. This does not establish that the technique is undetectable; the MITRE guidance and collection requirements remain relevant.

Before treating a rule as coverage

  1. Read the actual condition and logsource; identify attacker-side, victim-side or third-party visibility.
  2. Map native sensor fields, parse times and identities, then compile for the selected backend.
  3. Replay a behavior-positive case, a normal control, an authorized look-alike and a missing-telemetry case.
  4. Record matches and misses with rule version and source events. No match is inconclusive when required telemetry is absent.

Anomaly-based detection

No exact technique-specific Atlas model is present for T1691 in the selected source snapshot. The following is a design worksheet, not a newly validated model.

Anomaly engineering worksheet

Start from the exact analytic above. The collection-specific lenses below are analyst recommendations; they do not assert that an arbitrary statistical deviation detects this technique.

  • Network and protocol telemetry: Per source and observation point: connection rate, destination-host/port fan-out, response/failure ratio and previously unseen destinations. Compare equivalent time windows; separate authorized scanners, NAT and sampling effects.
  • Endpoint activity: Per host role and user: rare process/object combinations, bursts of object access or modification, and ordered parent/action sequences. Compare maintenance windows and signed software rollout activity.
  • Industrial operations and physical process: Per asset, operating mode and engineering change window: deviations in command/state sequences, measurement residuals and communication freshness. Use a simulator or approved test rig; never generate hazardous physical effects.
  1. Define an entity/peer group and feature; exclude the evaluation period from baseline training.
  2. Use representative normal and maintenance activity. Do not invent a production threshold from a synthetic example.
  3. Evaluate held-out behavior-positive and benign cases; measure false positives, misses and telemetry loss separately.
  4. Keep abnormality separate from maliciousness. Correlate with the behavior-specific source evidence.

Anomaly Detection Atlas · Baseline, validation and blind spots

Attack tools and documented software

No reviewed lab-tool association is selected for this exact technique. This is a curation gap, not a statement that no tool can implement the behavior.

Simulation design and documented procedures

Atomic evidence: no compatible candidate in this snapshot. Live lab status: not run for these imported procedures.

Use a process simulator or isolated test rig with no connection to production controllers or physical actuators. Preserve safety interlocks; destructive effects require synthetic evidence, not real equipment damage.

No compatible Atomic procedure is present in this pinned evidence set. Technical feasibility has not been ruled out. A custom procedure must define the behavior, target, collection point, success observable and rollback before execution.

Technique-specific experiment contract

  1. Choose one procedure implementing T1691 Block Operational Technology Message; identify the observable behavior in the source definition, not just its tactic.
  2. Record exact target, tool/version, inputs, privileges, network limits and approval. Never run an imported default target automatically.
  3. Enable the collection sources above and verify a benign baseline reaches the detector.
  4. Run only the approved isolated scenario; capture native events and an independent behavior observable.
  5. Evaluate the exact rule/model, restore the lab, and preserve configuration, event hashes, alerts, controls and misses.

Synthetic logs and offline contract check

Download synthetic collection fixture (JSON) · Download the complete engineering workbook

This fixture exercises the listed collection fields. It does not reproduce Block Operational Technology Message, label its example events as malicious, or measure detection effectiveness. Use the exact analytic and selected procedure to build an independently labelled behavior-positive dataset.

Not run in this browser. No network scan or attack command is executed by this control.

Validation status and remaining work

Source identity
Joined by exact technique/object IDs against hash-pinned sources.
Collection fixture
Available for offline schema exercises; not attack emulation.
Native telemetry / backend / real attack
Not validated for these imported procedures. Source fidelity and page tests cannot establish sensor or detector effectiveness.

All-page audit and evidence inventory · This page’s machine-readable workbook

Sources and evidence boundaries

Pinned MITRE STIX source · SHA-256 c9ca0ce523a1b5e512060a390415e8aefe8f6d32c5f82d7de81264960c1e1183. Definition and procedure context are reproduced from this snapshot, not independently re-investigated incidents.

Source-linked mitigations
  • M0807 Network Allowlists

    Utilize network allowlists to restrict unnecessary connections to network devices (e.g., comm servers, serial to ethernet converters) and services, especially in cases when devices have limits on the number of simultaneous sessions they support.

  • M0810 Out-of-Band Communications Channel

    Provide an alternative method for sending critical commands message to outstations, this could include using radio/cell communication to send messages to a field technician that physically performs the control function.

  • M0814 Static Network Configuration

    Unauthorized connections can be prevented by statically defining the hosts and ports used for automation protocol connections.

Connected ecosystem references

Linked tags

Detection and collection

T1691 detection workspace

No reviewed association in this snapshot.

Pinned research references. No browser attack runner or production-validated detector is asserted. Imported procedures remain unvalidated; any bounded lab evidence has its own scope. ATT&CK / Atomic provenance · Detection provenance.