Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1695.001: Serial COM

Adversaries may block access to serial COM to prevent instructions or configurations from reaching target devices. Serial Communication ports (COM) allow communication with control system devices. Devices can receive command and configuration messages over such serial COM. Devices also use serial COM to send command and reporting messages. Blocking device serial COM may also block command messages and block reporting messages.

A serial to Ethernet converter is often connected to a serial COM to facilitate communication between serial and Ethernet devices. One approach to blocking a serial COM would be to create and hold open a TCP session with the Ethernet side of the converter. A serial to Ethernet converter may have a few ports open to facilitate multiple communications. For example, if there are three serial COM available -- 1, 2 and 3 --, the converter might be listening on the corresponding ports 20001, 20002, and 20003. If a TCP/IP connection is opened with one of these ports and held open, then the port will be unavailable for use by another party. One way the adversary could achieve this would be to initiate a TCP session with the serial to Ethernet converter at 10.0.0.1 via Telnet on serial port 1 with the following command: telnet 10.0.0.1 20001.

ICST1695.001Sub-techniqueObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Serial COM blocking matters because it can interrupt the command and reporting paths that industrial devices depend on. In practical terms, a device may stop receiving operator instructions, configuration changes, or telemetry because access to a serial communication path or serial-to-Ethernet converter is being held unavailable. For executives and operations leaders, the business issue is not the serial port itself; it is loss of visibility and control over equipment that may support physical processes.

Executive priority

Prioritize this where serial communications or serial-to-Ethernet converters connect HMIs, control servers, gateways, PLCs, RTUs, IEDs, safety controllers, field I/O, DCS controllers, PACs, jump hosts, or VPN-enabled access paths. Leaders should ask whether critical process communications have documented dependencies, whether alternate communications are available during failure, and whether segmentation and allowlists prevent unauthorized systems from monopolizing converter ports. This technique is especially relevant to resilience planning, compliance evidence for OT network access control, and incident decisions when operators report missing telemetry or failed commands.

Technical view

ATT&CK provides no official detection text for T1695.001, but it relates to DET0797, Detection of Block Serial COM. SOC and OT teams should validate whether they can observe long-lived or unexpected TCP sessions to serial-to-Ethernet converters, especially connections that make a mapped serial port unavailable to legitimate systems. Detection should be tied to known asset inventory and expected communication pairs, because many serial converter connections may be normal in ICS environments. IR playbooks should include checks for loss of command delivery, loss of reporting messages, and whether converter ports are occupied by unexpected hosts.

Likely telemetry

  • Asset inventory for serial-to-Ethernet converters, serial COM dependencies, and mapped TCP ports
  • Network flow/session logs showing source, destination, port, protocol, and connection duration for converter communications
  • Firewall, router, or allowlist enforcement logs for permitted and denied connections to ICS communication devices
  • HMI, control server, engineering workstation, gateway, RTU, PLC, IED, and controller logs showing communication failures or missing telemetry
  • Operational alarms or historian events indicating command failures, stale data, or reporting interruption

Detection direction

  • Baseline which hosts are allowed to communicate with each serial-to-Ethernet converter and on which ports; alert on unexpected sources or unusually long-held sessions.
  • Correlate network sessions with operational symptoms such as failed commands, stale telemetry, or unavailable serial channels rather than relying on port activity alone.
  • Tune carefully for scheduled maintenance, engineering work, diagnostics, and legitimate persistent ICS sessions to reduce false positives.
  • Validate DET0797-aligned coverage locally, because the supplied ATT&CK object does not include detailed detection analytics.
  • Pay special attention to remote access paths such as jump hosts and VPN servers when they can reach converter or control network segments.

Mitigation priorities

  • Use network segmentation to isolate critical process control systems and restrict access to required systems and services only.
  • Implement network allowlists for permitted IP addresses, MAC addresses, ports, and protocols that can communicate with serial communication infrastructure.
  • Maintain out-of-band communication options for operationally critical paths so teams have alternatives during communication failures or data integrity events.
  • Document serial COM dependencies in resilience and incident response plans, including who can authorize changes during an outage.
  • Periodically test whether monitoring, segmentation, and allowlist controls would reveal or prevent an unauthorized host from occupying a converter communication path.
Analyst notes and limits

This is an ICS sub-technique under Block Communications and supersedes the revoked Block Serial COM technique T0805. ATT&CK relationships indicate broad target relevance across workstations, HMIs, PLCs, RTUs, IEDs, control servers, data gateways, safety controllers, VPN servers, jump hosts, field I/O, DCS controllers, and PACs. ATT&CK also links the behavior to the 2015 Ukraine Electric Power Attack campaign and Industroyer software, which supports its relevance to OT impact scenarios without implying current activity.

Platforms and tactics are not specified for this technique, and the official detection field is not provided. The related detection strategy is named but not detailed in the supplied data. Practical coverage depends on local asset inventory, network architecture, converter configuration, logging availability, and knowledge of normal ICS communication patterns.

Official MITRE ATT&CK definition

Serial COM

Adversaries may block access to serial COM to prevent instructions or configurations from reaching target devices. Serial Communication ports (COM) allow communication with control system devices. Devices can receive command and configuration messages over such serial COM. Devices also use serial COM to send command and reporting messages. Blocking device serial COM may also block command messages and block reporting messages.

A serial to Ethernet converter is often connected to a serial COM to facilitate communication between serial and Ethernet devices. One approach to blocking a serial COM would be to create and hold open a TCP session with the Ethernet side of the converter. A serial to Ethernet converter may have a few ports open to facilitate multiple communications. For example, if there are three serial COM available -- 1, 2 and 3 --, the converter might be listening on the corresponding ports 20001, 20002, and 20003. If a TCP/IP connection is opened with one of these ports and held open, then the port will be unavailable for use by another party. One way the adversary could achieve this would be to initiate a TCP session with the serial to Ethernet converter at 10.0.0.1 via Telnet on serial port 1 with the following command: telnet 10.0.0.1 20001.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

2 rows
Domain ID Name Relationship / procedure
ICS T1695 Block Communications This object subtechnique of Block Communications.
ICS T0805 Block Serial COM Block Serial COM revoked by this object.
Associated objects

Groups, software, and campaigns

Malware ICS

S0604: Industroyer

Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]

Windows
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
29cff50a746ddfeb...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 29cff50a746d…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack T1695.001
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.