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

DET0759: Detection of Connection Proxy

DET0759 is an ATT&CK for ICS detection strategy for identifying use of a connection proxy, which may let an adversary route communications through intermed...

ICSDET0759Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0759 is an ATT&CK for ICS detection strategy for identifying use of a connection proxy, which may let an adversary route communications through intermediary systems or trusted network relationships. For executives and security leaders, the practical issue is not the proxy concept itself, but whether the organization can see and explain unexpected traffic paths across operational, enterprise, partner, or other trusted network boundaries.

Executive priority

Prioritize this as a visibility and segmentation assurance question for ICS environments. Leaders should ask whether SOC and incident response teams can validate normal trusted communications, detect unusual intermediary behavior, and produce evidence for network access governance. Because the ATT&CK object provides no official detection text, platforms, or tactics, investment decisions should be based on local architecture, known trust relationships, and the business consequence of losing visibility into traffic moving between connected systems or networks.

Technical view

This detection strategy is linked to ATT&CK ICS technique T0884, Connection Proxy. SOC and detection teams should validate whether they can identify systems acting as intermediaries for communications between other systems, especially where peer-to-peer, mesh, or trusted network relationships exist. Start by mapping expected communication paths and comparing them against observed network flows, authentication context, and system roles. Since MITRE does not specify platforms or detection logic for DET0759, teams should avoid assuming coverage from a generic proxy alert and instead test against their actual ICS network topology and approved trust paths.

Likely telemetry

  • Network flow records showing source, destination, ports, protocols, and timing
  • Firewall, router, switch, and segmentation-control logs
  • Proxy, gateway, remote access, or jump-host logs where present
  • Asset inventory and network topology records for expected ICS communication paths
  • Authentication or session records that help associate users, systems, and intermediary access

Detection direction

  • Baseline approved communications between ICS systems, enterprise systems, and trusted external or partner networks before alerting on deviations.
  • Look for systems that unexpectedly relay, broker, or concentrate traffic between networks or hosts that do not normally communicate through them.
  • Tune detections against known engineering workstations, gateways, remote access paths, jump hosts, and other legitimate intermediaries to reduce false positives.
  • Validate whether monitoring exists at trust boundaries; blind spots commonly occur where networks are considered trusted and therefore less inspected.
  • Correlate network observations with asset role and change records so maintenance activity is not confused with suspicious intermediary behavior.

Mitigation priorities

  • Maintain an authoritative map of trusted network relationships and permitted communication paths in the ICS environment.
  • Limit and document systems allowed to act as gateways, proxies, jump points, or intermediaries between networks.
  • Enforce segmentation and access controls at boundaries where peer, mesh, or trusted network communications occur.
  • Collect and retain boundary and intermediary-device telemetry sufficient for incident response reconstruction.
  • Review exceptions and temporary connectivity introduced for operations, maintenance, or vendor access.
Analyst notes and limits

The supplied ATT&CK object is a detection strategy, not a technique. It has no official description, detection text, tactics, platforms, or aliases. Its decision value comes from its relationship to ICS technique T0884, Connection Proxy, and the need to validate visibility into intermediary communications and trusted network relationships.

This take is constrained to the provided STIX fields, external reference, and relationship context. It does not assert active exploitation, specific adversaries, affected platforms, or guaranteed detection coverage. Local network architecture, logging, segmentation design, and asset roles are required to turn this into deployable analytics.

Official MITRE ATT&CK definition

Detection of Connection Proxy

No official description is available in the imported ATT&CK source object.

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

Techniques used

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.

1 rows
Domain ID Name Relationship / procedure
ICS T0884 Connection Proxy This object detects Connection Proxy.
Relationship explorer

All related ATT&CK context

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
778d9821b6a70694...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 778d9821b6a7…
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 DET0759
    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.