1200kmSECURITY RESEARCH
Loading interactive filters…

1200KM / simulation

T0848 Rogue Master — Attack Simulation

Adversaries may setup a rogue master to leverage control server functions to communicate with outstations. A rogue master can be used to send legitimate control messages to other control system devices, affecting processes in unintended ways. It may also be used to disrupt network communications by capturing and receiving the network traffic meant for the actual master. Impersonating a master may also allow an adversary to avoid detection. In…

Complete technique description

Adversaries may setup a rogue master to leverage control server functions to communicate with outstations. A rogue master can be used to send legitimate control messages to other control system devices, affecting processes in unintended ways. It may also be used to disrupt network communications by capturing and receiving the network traffic meant for the actual master. Impersonating a master may also allow an adversary to avoid detection.

In the case of the 2017 Dallas Siren incident, adversaries used a rogue master to send command messages to the 156 distributed sirens across the city, either through a single rogue transmitter with a strong signal, or using many distributed repeaters. [Bastille April 2017] [Zack Whittaker April 2017]

Official technique definition · Open in the interactive matrix

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.

Asset Inventory · source-mapped

DC0110 collection page — Prefer approved inventory exports and passive discovery; retain model, firmware, owner and observation source. Do not scan a production control network as a default collection step.

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: asset_id, role, firmware, source.

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": "DC0110",
  "collector": "illustrative-lab-collector",
  "observation": {
    "asset_id": "lab-controller-1",
    "role": "PLC_fixture",
    "firmware": "lab-1.0",
    "source": "approved_inventory"
  }
}

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.

Device Alarm · source-mapped

DC0108 collection page — Subscribe to supported device alarm/audit channels; retain code, severity, source asset and acknowledgement/clear times.

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: asset_id, alarm_code, severity, active.

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": "DC0108",
  "collector": "illustrative-lab-collector",
  "observation": {
    "asset_id": "lab-controller-1",
    "alarm_code": "LAB_COMM_LOSS",
    "severity": "warning",
    "active": true
  }
}

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.

Network Connection Creation · source-mapped

DC0082 collection page — Enable scoped Sysmon NetworkConnect (3), disabled by default, or a platform-equivalent process-aware network sensor.

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, destination_ip, destination_port, protocol, initiated.

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": "DC0082",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "destination_ip": "198.51.100.20",
    "destination_port": 443,
    "protocol": "tcp",
    "initiated": true
  }
}

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.

Network Traffic Content · source-mapped

DC0085 collection page — Scope approved packet capture/protocol content collection to the lab flow; retain capture provenance and truncation indicators.

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.
  • 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: flow_id, protocol, method, path, payload_excerpt.

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": "DC0085",
  "collector": "illustrative-lab-collector",
  "observation": {
    "flow_id": "lab-flow-1",
    "protocol": "http",
    "method": "GET",
    "path": "/lab-check",
    "payload_excerpt": "LAB_TELEMETRY_CHECK"
  }
}

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.

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.

Detection rules and analytic guidance

Open the dedicated detection workspace · Existing query engineering

DET0792 Detection of Rogue Master

MITRE detection strategy

AN1924 Analytic 1924

Real-time monitoring identifies Industrial Control System (ICS) master-role command traffic originating from a source not in the approved control server inventory, directed at multiple field devices in a pattern consistent with control-server behavior. Documented in Maroochy Water Services (falsified PDS/station addresses to impersonate the master) and the 2017 Dallas Siren incident (rogue radio transmitter to 156 sirens). OT operational-fidelity gate: Alert only when the master/station identity or source is not authorized for the target device and command function, or when a normally authorized master violates its configured role/sequence and produces a corroborating device/process-state change. Suppress legitimate redundancy/failover, hot-standby promotion, commissioning, and approved engineering master activity.

Platforms: Embedded.

  • Asset Inventory — assetinventory:MasterAddress; channel command traffic uses master/station address not in registered master addresses.
  • Device Alarm — operationaldb:AlarmEvent; channel device receives commands from two distinct master identities within a short window.
  • Network Traffic Content — NSM:Content; channel write/control command traffic from source not in approved Supervisory Control and Data Acquisition (SCADA) servers directed at multiple distinct device IPs within rogue master time window.

AN2151 Analytic 2151

Real-time monitoring identifies a Linux process opening Industrial Control System (ICS) protocol master connections to multiple field device Internet Protocol (IP) addresses, from a host that is not the authorized Supervisory Control and Data Acquisition (SCADA) server. OT operational-fidelity gate: Alert only when the master/station identity or source is not authorized for the target device and command function, or when a normally authorized master violates its configured role/sequence and produces a corroborating device/process-state change. Suppress legitimate redundancy/failover, hot-standby promotion, commissioning, and approved engineering master activity.

Platforms: Linux.

  • Network Connection Creation — auditd:SYSCALL; channel Linux Audit SYSCALL/EXECVE/SOCKADDR records (configured audit rule): connect syscalls show a host outside the approved SCADA/master set opening ICS-protocol connections to multiple field devices.

AN2178 Analytic 2178

Real-time monitoring identifies a new device appearing on the Industrial Control System (ICS) network with network behavior consistent with an ICS master station, with a Media Access Control (MAC) address not in the approved device inventory. OT operational-fidelity gate: Alert only when the master/station identity or source is not authorized for the target device and command function, or when a normally authorized master violates its configured role/sequence and produces a corroborating device/process-state change. Suppress legitimate redundancy/failover, hot-standby promotion, commissioning, and approved engineering master activity.

Platforms: Network Devices.

  • Network Traffic Flow — netflow:ipfix; channel IPFIX/NetFlow flow record (src/dst IP, src/dst port, protocol, packets/bytes/time): new device Media Access Control (MAC) address on Industrial Control Systems (ICS) network generating ICS master-pattern traffic such as polling multiple device Internet Protocol (IP) addresses on ICS protocol ports.

AN2278 Analytic 2278

Real-time monitoring identifies Industrial Control System (ICS) protocol master-role traffic originating from a Windows host that is not the authorized Supervisory Control and Data Acquisition (SCADA) or Distributed Control System (DCS) server. OT operational-fidelity gate: Alert only when the master/station identity or source is not authorized for the target device and command function, or when a normally authorized master violates its configured role/sequence and produces a corroborating device/process-state change. Suppress legitimate redundancy/failover, hot-standby promotion, commissioning, and approved engineering master activity.

Platforms: Windows.

  • Network Connection Creation — WinEventLog:Sysmon; channel EventCode=3 unexpected Windows host opening Industrial Control Systems (ICS) protocol connections to multiple field device Internet Protocol (IP) addresses in polling pattern characteristic of master station.
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 T0848 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.

  • 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.
  • 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.
  • 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.
  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 T0848 Rogue Master; 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 Rogue Master, 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

Connected ecosystem references

Linked tags

Detection and collection

T0848 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.