1200kmSECURITY RESEARCH
Loading interactive filters…

1200KM / simulation

T0860 Wireless Compromise — Attack Simulation

Adversaries may perform wireless compromise as a method of gaining communications and unauthorized access to a wireless network. Access to a wireless network may be gained through the compromise of a wireless device. Adversaries may also utilize radios and other wireless communication devices on the same frequency as the wireless network. Wireless compromise can be done as an initial access vector from a remote distance. A Polish student used a…

Complete technique description

Adversaries may perform wireless compromise as a method of gaining communications and unauthorized access to a wireless network. Access to a wireless network may be gained through the compromise of a wireless device. [Alexander Bolshev, Gleb Cherbov July 2014] [Alexander Bolshev March 2014] Adversaries may also utilize radios and other wireless communication devices on the same frequency as the wireless network. Wireless compromise can be done as an initial access vector from a remote distance.

A Polish student used a modified TV remote controller to gain access to and control over the Lodz city tram system in Poland. [John Bill May 2017] [Shelley Smith February 2008] The remote controller device allowed the student to interface with the trams network to modify track settings and override operator control. The adversary may have accomplished this by aligning the controller to the frequency and amplitude of IR control protocol signals. [Bruce Schneier January 2008] The controller then enabled initial access to the network, allowing the capture and replay of tram signals. [John Bill May 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.

Logon Session Creation · source-mapped

DC0067 collection page — Enable Audit Logon and collect successful session creation on the receiving host; join session/logon IDs rather than only account names.

Providers and collection configuration

  • Use a lab-only GPO under Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration. Enable the specific subcategory named below.
  • For object-level auditing, configure a narrow system access control list (SACL) on the test object in addition to policy. Do not audit an entire production directory by default.
  • Forward Security events from the responsible host or controller; retain subject and target identities, object identifiers, result and original XML. Confirm effective policy with auditpol /get /category:*.

Required normalized fields: account, logon_id, logon_type, source_ip.

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": "DC0067",
  "collector": "illustrative-lab-collector",
  "observation": {
    "account": "LAB\\analyst",
    "logon_id": "0x12345",
    "logon_type": 3,
    "source_ip": "192.0.2.10"
  }
}

Visibility limits: A policy checkbox alone does not guarantee an event. Host role, SACL, success/failure selection and audit policy precedence matter. Directory changes may arrive as multiple records.

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 Metadata · source-mapped

DC0034 collection page — Collect read-only process inventory with PID plus start time/stable identity, command line and collection time; restrict access to potentially sensitive arguments.

Providers and collection configuration

  • osquery: Scheduled host-state queries; supported tables and privileges vary by OS. Select a table that actually exposes the required object.
  • Linux Audit plus inventory snapshots: Events explain changes; snapshots describe state at collection time.
  • Define the inventory query, allowed host set, interval and least-privileged reader. Store a stable asset ID, observation time and collector version.
  • Keep successive snapshots and calculate additions, removals and changed attributes. Pair state changes with audit events when available.
  • Export collector health and missed-poll counts so a missing snapshot is not misclassified as a missing asset.

Required normalized fields: process_id, image, owner_uid, started_at.

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": "DC0034",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_id": 4200,
    "image": "/usr/bin/sleep",
    "owner_uid": 1000,
    "started_at": "2026-09-27T11:59:00Z"
  }
}

Visibility limits: Snapshots miss short-lived objects and do not identify who caused a change. A generic inventory agent is not guaranteed to expose firmware or kernel-level details.

Detection rules and analytic guidance

Open the dedicated detection workspace · Existing query engineering

DET0726 Detection of Wireless Compromise

MITRE detection strategy

AN1859 Analytic 1859

Real-time monitoring identifies a previously unseen wireless device identity joining or authenticating to an ICS wireless segment—such as Wi-Fi/802.1X, WirelessHART, ISA100.11a, or a vendor radio mesh—when its MAC/EUI, certificate, or device identifier is absent from the approved wireless asset inventory. OT operational-fidelity gate: Alert only when the account/device/session violates the approved identity + source host/jump path/zone policy and is corroborated by access to a protected OT asset, execution, configuration change, or another security-relevant follow-on event. Suppress approved shift activity, vendor support, break-glass use, commissioning, and documented remote-access windows.

Platforms: Embedded.

  • Network Traffic Flow — netflow:ipfix; channel IPFIX/NetFlow flow record (src/dst IP, src/dst port, protocol, packets/bytes/time): traffic from newly-authenticated device to Industrial Control System (ICS) application server within onboard window of association.
  • Logon Session Creation — wireless:radius; channel Extensible Authentication Protocol (EAP) authentication success for device Media Access Control (MAC)/certificate not in approved wireless device inventory.

AN2124 Analytic 2124

Real-time monitoring identifies a process executing iwconfig or ip link set promisc, or loading mac80211 monitor mode, on an Industrial Control System (ICS) Linux asset outside normal configuration management activity. OT operational-fidelity gate: Alert only when the account/device/session violates the approved identity + source host/jump path/zone policy and is corroborated by access to a protected OT asset, execution, configuration change, or another security-relevant follow-on event. Suppress approved shift activity, vendor support, break-glass use, commissioning, and documented remote-access windows.

Platforms: Linux.

  • Process Metadata — auditd:SYSCALL; channel Linux Audit SYSCALL/EXECVE/SOCKADDR records (configured audit rule): execve of wireless configuration utility setting monitor/promiscuous mode outside change management window.

AN2269 Analytic 2269

Real-time monitoring identifies a Windows process enabling promiscuous or monitor mode on a wireless adapter (netsh wlan, WinPcap/Npcap driver load, etc.) on an Industrial Control System (ICS) workstation that is not a designated wireless management station, indicating preparation for wireless interception consistent with this technique's reconnaissance phase. OT operational-fidelity gate: Alert only when the account/device/session violates the approved identity + source host/jump path/zone policy and is corroborated by access to a protected OT asset, execution, configuration change, or another security-relevant follow-on event. Suppress approved shift activity, vendor support, break-glass use, commissioning, and documented remote-access windows.

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

  • Windows and directory audit: Per principal, host and object: unusual access/request rates, new principal-object relationships, and changes outside approved administration windows. Control for service accounts and scheduled directory maintenance.
  • 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.
  • Host state and inventory: Compare authorized state snapshots: first-seen drivers/services/modules, unexpected configuration drift and integrity changes. Record collection cadence; absence in a sample is not evidence of deletion.
  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 T0860 Wireless Compromise; 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 Wireless Compromise, 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
  • M0802 Communication Authenticity

    Do not inherently rely on the authenticity provided by the network/link layer (e.g., 802.11, LTE, 802.15.4), as link layer equipment may have long lifespans and protocol vulnerabilities may not be easily patched. Provide defense-in-depth by implementing authenticity within the associated application-layer protocol, or through a network-layer VPN. [CISA March 2010] Furthermore, ensure communication schemes provide strong replay protection, employing techniques such as timestamps or cryptographic nonces.

  • M0806 Minimize Wireless Signal Propagation

    Techniques can include (i) reducing transmission power on wireless signals, (ii) adjusting antenna gain to prevent extensions beyond organizational boundaries, and (iii) employing RF shielding techniques to block excessive signal propagation. [DHS National Urban Security Technology Laboratory April 2019]

  • M0808 Encrypt Network Traffic

    Utilize strong cryptographic techniques and protocols to prevent eavesdropping on network communications.

  • M0813 Software Process and Device Authentication

    Ensure wireless networks require the authentication of all devices, and that all wireless devices also authenticate network infrastructure devices (i.e., mutual authentication). For defense-in-depth purposes, utilize VPNs or ensure that application-layer protocols also authenticate the system or device. Use protocols that provide strong authentication (e.g., IEEE 802.1X), and enforce basic protections, such as MAC filtering, when stronger cryptographic techniques are not available.

Connected ecosystem references

Linked tags

Detection and collection

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