Detecting T1090 Proxy

How T1090 Proxy hides adversary command and control traffic

A SOC lead rarely sees T1090 Proxy as a single alarm. Under the Command and Control tactic (TA0011), MITRE describes the adversary's goal as trying to communicate with compromised systems to control them. T1090 Proxy is one way that control traffic is relayed through an intermediary so the session no longer runs directly between the compromised host and the attacker's infrastructure. In intrusions, this usually means an implant on an internal host passes its traffic through another internal system or an outside node, so what reaches your monitoring looks like ordinary internal or outbound sessions. The technique has four sub-techniques, covering internal proxies, external proxies, multi-hop proxies and domain fronting. This page targets Enterprise ATT&CK version 20.0.

The practical problem is that each hop can look legitimate on its own. A relay between two servers that already talk to each other may pass a flow review unnoticed, and a proxy that uses a common web destination may blend into normal browsing. The decisions that matter come before any alert fires. Confirm which hosts are permitted to act as relays, which internal flows form your baseline, and whether your sensors record the telemetry that detection strategies for this technique typically rely on, such as network connection creation, process creation and network traffic flow. If one of those sources is missing for your servers or network devices, the gap should be known and accepted in writing before the detection is relied on.

Treat the ATT&CK version as part of the detection record. MITRE releases updates that can rename, deprecate or revoke techniques, so each detection mapping should name the version it targets. Check the ATT&CK updates page against your rule set before each review cycle, and record which sub-techniques your detections cover and which they do not. A SOC lead who can say which of the four sub-techniques are monitored, on which platforms and with which sources, can answer an incident question about relayed control traffic without reconstructing the coverage under pressure.

Which telemetry reveals proxy activity and which tool collects it

This table maps each data component relevant to T1090 Proxy to the signal it can reveal, the platforms where it applies, and the open-source collector that gathers it. Read it as a coverage plan: a data component only helps on platforms where your sources actually emit it. Confirm each mapping against the ATT&CK 20.0 detection strategies before you rely on it.

Telemetry	Signal to look for	Platforms and collector
Network Connection Creation (DC0082)	Hosts or devices opening outbound sessions to relay-like destinations, unusual listening ports, or new peer connections from systems that do not normally proxy traffic	ESXi, Linux, macOS and network devices where host or device logs record connections. Collect with Wazuh agents or Zeek connection logs
Process Creation (DC0032)	Proxy or tunneling utilities launched by users or services that have no business case for them, including unexpected parent-child relationships	Linux and macOS endpoints. Collect with Wazuh, using auditd or endpoint log sources, and forward to Security Onion for hunting
Network Traffic Flow (DC0078)	Long-lived sessions, unusual volume or timing, and flows between internal segments that bypass expected gateways	ESXi, Linux, macOS and network devices seen at the network boundary. Collect with Zeek conn logs, Suricata flow records or Security Onion sensors
Network Traffic Content (DC0085)	Protocol content that reveals proxy behavior, such as inner protocol headers or handshake patterns	Only where traffic is decrypted or inspectable, for example at a TLS inspection point. Collect with Zeek and Suricata rules at that point
Relay and proxy configuration changes	Changes to proxy settings, forwarding rules or SOCKS-style listeners on network devices and hypervisors	Network devices and ESXi. Collect with syslog into Wazuh, and confirm which configuration events each vendor emits
Normalized fields across sources	Common source host, destination, port, protocol, process name, user and time zone so events from different tools correlate	All platforms. Normalize in Wazuh decoders or Security Onion pipelines before writing Sigma rules
Coverage confirmation	Whether each platform in your estate emits each data component, and at what fidelity	Confirm against the ATT&CK 20.0 detection strategies for T1090 and its sub-techniques, and record gaps in your coverage map

Detection ideas for proxy behavior in words

The ideas below describe what a defender should look for in network and host telemetry when T1090 Proxy activity is present, without publishing queries. Each card pairs a detection logic with lab tuning guidance and the legitimate sources that will trigger it, so the cyber range exercise can separate attacker relays from approved infrastructure.

Long-lived relay-like server connections

Servers rarely initiate long, steady outbound sessions to unfamiliar external hosts, and a relay often looks like one session that stays open for hours while carrying a similar volume of traffic in both directions. Build the logic around server source hosts, session duration and the ratio of bytes sent to bytes received, then compare each hit against an approved destination list. In the lab, start with a long-duration threshold set well above your normal backup and monitoring windows, then lower it until the cyber range attack is caught. Review every destination that is not on the approved list.

Proxy process creation on unexpected hosts

Process creation telemetry can show a proxy or tunneling binary starting on a host whose role never required one, such as a database server or an domain controller. Define an allowlist of approved proxy software by host group, then alert when a binary outside that list starts, or when a known-approved binary starts under an unusual parent process. Tune by host class first, not by individual host, so new servers inherit the right baseline. Expect hits from developer workstations and jump hosts, which should be tracked in their own group.

Internal flows that bypass egress

A compromised internal host can forward traffic to another internal host, and that hop may never cross the egress firewall where most monitoring sits. Look for east-west sessions where one internal host accepts inbound connections on an uncommon port and then opens outbound sessions to external addresses within a short window. Set the window and port scope in the lab, then confirm that the sensor placement actually sees the internal segment. If the sensor cannot see east-west traffic, this detection will be silent.

Forwarding role changes on network devices

Routers, switches and firewalls should keep stable forwarding configurations, so a change that adds port forwarding, a new NAT rule or a new tunnel endpoint deserves review. Pull configuration change events from the device management plane, and alert on changes outside an approved change window or without a matching ticket. In the lab, replay an approved change and an unapproved one to confirm the alert separates them. False positives will come from VPN concentrators, load balancers and reverse proxies that change configuration during normal operations, so record their maintenance schedules and owners before tuning.

Legitimate sources to exclude

Most T1090 false positives come from infrastructure that is designed to relay traffic, including reverse proxies, VPN concentrators, load balancers, backup tools and developer tunnels. Keep a registry of each of these with its host, owner, approved destinations and expected hours, and feed it into every detection as an exclusion list rather than a silent suppression. Review the registry after each platform change, because a stale exclusion can hide the exact relay the detection was built to catch. Confirm the detection scope against the ATT&CK version your team targets, since technique definitions can change between releases.

How to validate that proxy detections fire

This sequence proves that the proxy detections built for T1090 Proxy fire on the behavior they target, with a documented record of what was run, what alerted, and where the gaps are. The result is a repeatable test that the detection owner, the asset owner, and an auditor can each review.

Agree scope with the asset owner
Before any test, the detection engineer and the owner of each in-scope system (ESXi hosts, Linux and macOS endpoints, and network devices in the range) agree in writing which assets, accounts, network segments and time windows are covered. The owner also confirms who is on call, how the test is stopped, and which alerts must be suppressed or tagged so they are not mistaken for live activity. The step is done when the signed scope note is filed with the test plan.
Write the test plan from the technique mapping
The detection engineer writes a test plan that lists each T1090 Proxy sub-technique in scope, the ATT&CK version it targets, and the detection strategy and analytic that should fire for it. Each row names the data component the detection relies on, such as Network Connection Creation, Process Creation or Network Traffic Flow. The test plan describes the expected behavior in plain language and does not include commands or payloads. It is approved by the detection owner and the asset owner before the range is opened.
Confirm telemetry is flowing before testing
Before the emulation starts, the platform team checks that every data component named in the plan is reaching the SIEM or analytics platform, for example Wazuh, Security Onion, Zeek or Suricata, depending on the range design. They confirm timestamps are synchronized, field names match the rule logic, and the sources are not dropping events under normal load. The step is complete when a baseline check shows each source has recent events for each in-scope asset. Any missing source is logged as a pre-test gap, not as a detection failure.
Run the planned emulation in the range
A trained tester runs the approved emulation in the private cyber range, one test row at a time, following the plan's order and stop conditions. A second person observes and notes the start and end time of each row against the range clock. The tester does not improvise beyond the plan, and any unplanned activity is stopped and recorded. The step closes when every row has a start time, an end time, and a result of run, skipped, or stopped with the reason given.
Record alerts, analyst actions and gaps
For each test row, the analyst records the alert identifier, the rule or detection name, the timestamp it fired, the time to triage, and the action taken, such as escalation, enrichment or closure. If a row produced no alert, the analyst records that as a gap and notes which data component was missing or which logic did not match. Results are kept in a shared log that links each alert to its test row. The step is done when every row has a detected, partially detected, or not detected result with supporting evidence.
Tune and re-run the affected tests
The detection engineer reviews each gap and each noisy alert, then changes detection logic, data collection or thresholds where the evidence shows a cause. Every change is recorded with its reason, the ATT&CK version it targets, and the person who approved it. The affected test rows are re-run under the same conditions, and the new results are compared with the first run. The step is complete when the before and after results for each changed row are filed together.
Package audit evidence for review
The team assembles a single evidence package: the signed scope note, the approved test plan, the baseline telemetry check, the run log with timestamps, the alert and analyst action records, the gap register, and the tuning change history with re-run results. Each item is labeled with the ATT&CK technique, sub-technique, and version it supports. The package is reviewed by the detection owner and filed where the compliance lead can retrieve it. DeployOpen prepares this evidence, but independent auditors and certification bodies decide whether it meets a specific control requirement.

How proxy detections fit into existing SIEM and NDR pipelines

A proxy detection is only useful when a host-level process event and a network flow can be tied to the same connection. For T1090 Proxy, the host side usually comes from Wazuh agent telemetry on Linux and macOS endpoints, where process creation and network connection records show which binary opened or relayed a session. The network side comes from Zeek, which writes connection and protocol logs, and from Suricata alerts, which Security Onion collects and presents alongside Zeek data. Your pipeline should be designed so an analyst can pivot from a Zeek connection record with its source address, destination, ports and timestamps to the Wazuh event on the originating host within the same time window. Confirm that host clocks are synchronized to a common time source, because a few seconds of skew is enough to break that pivot on short-lived relays.

Normalization is the step that most often decides whether that pivot works. Logs from ESXi hosts, Linux and macOS endpoints and network devices use different field names for the same facts, such as source address, process image path and connection direction. Map them to one schema before correlation rules are written, and record which fields are populated for each platform. Network device and hypervisor logs may not carry process context at all, so the rule logic must be written to tolerate missing fields rather than fail silently. Ask your SIEM team to document the field mapping in version control so that a change to a parser is visible to detection engineers.

Every rule should name the ATT&CK version it targets in its metadata, because technique IDs, sub-techniques and mappings change between releases. ATT&CK v18, released October 28, 2025, replaced the detections in technique pages with detection strategies and analytics, so a rule written against an older page may no longer match the current mapping. Store the version, the detection strategy identifier and the data components the rule depends on in each rule's metadata, and review those fields when a new ATT&CK release is published. The MITRE ATT&CK updates page is the natural place to check what changed before you re-baseline your proxy rules.

Preventive controls that reduce proxy options

T1090 Proxy relies on an adversary being able to route traffic through intermediate systems. The controls below reduce how many of those routes are open, and each one has limits that the detection work has to cover. Confirm each control against your own network paths before you treat it as a barrier.

Network intrusion prevention (M1031)

ATT&CK maps M1031 to T1090 and its sub-techniques. Inline or passive intrusion prevention can block known relay protocols, malformed tunnel handshakes and traffic to listed proxy infrastructure when signatures or rules match. It cannot block a relay that uses ordinary web traffic to an unlisted host, and it depends on visibility into the traffic it inspects. Confirm which segments it sees inline, whether encrypted sessions are visible to it, and how often its rule set is updated.

Filter network traffic (M1037)

Egress filtering is the control that most directly limits proxy use. Allow lists for outbound destinations, ports and protocols remove many arbitrary relay paths, particularly from servers that have no business reason to browse or connect out. It does not stop relays through destinations you have allowed, such as a cloud storage service or a SaaS API. Confirm the default-deny posture for each server zone and review the exceptions with their owners.

Network segmentation (M1030)

Segmentation limits where a proxy can reach once it is installed. Separating management, server and user zones means a compromised host can only route toward systems its zone is permitted to reach. It does not remove proxy activity inside a zone, so it works best combined with egress filtering. Confirm which flows between zones are actually required and document any broad rules that exist for convenience.

SSL/TLS inspection (M1020)

Inspection makes encrypted relay traffic visible to policy and detection. Where legal and privacy requirements allow, decrypting outbound sessions lets inspection engines see protocol content and the destinations inside tunnels. It cannot inspect traffic that is pinned, that bypasses the inspection point, or that goes to categories you have excluded for privacy reasons. Confirm the approved exemption list, certificate handling on managed hosts, and the legal basis for inspection in each jurisdiction.

Disable unneeded proxy-capable features

Removing unused forwarding features shrinks the set of relays available on a host. On network devices and servers, disabling unused port forwarding, proxy services and tunnel features, as described under M1042, removes options before an adversary can use them. It does not remove proxy functions that the business depends on, so every exception should have a named owner. Confirm the feature inventory for each device class and track changes through your configuration management process.

Rehearsing proxy detection in a private cyber range

A range exercise for the SOC tests whether an analyst can recognize proxy-like behavior, separate it from normal administration, and escalate with enough context to act. The range should contain representative Linux and macOS endpoints, an ESXi host, and a network device that logs flow and session records, all connected to a Wazuh or Security Onion stack. Injects are approved in advance and described only at the level of what the analyst should see, such as an unexpected outbound session from a server that normally makes none.

Alert triage: Confirm the analyst can move from a Wazuh or Suricata alert to the originating host, user and time window within the agreed response target.
Baseline comparison: Check whether the analyst can tell an approved jump host or VPN session from an unapproved relay using asset inventory.
Scoping: Measure whether the analyst identifies other hosts that share the same destination or session pattern.
Escalation quality: Review whether the ticket states the evidence, the open questions and the containment options.
Containment decision: Observe whether the analyst can request a network block or host isolation through the agreed change path.

Before the exercise, confirm the range is isolated from production networks and that the written scope names the systems, accounts and time window involved.

What SOC teams should do when a proxy alert fires

The first decision on a T1090 Proxy alert is whether the traffic is a sanctioned relay or an unauthorized one, and that decision starts with the host and its owner. Confirm the hostname, asset owner, and logged-in user against your configuration management database and identity records, then check whether the endpoint is expected to run a VPN client, a jump host service, a reverse proxy, or a tunneling agent. Compare the observed connection against your change records and approved software inventory. If the activity matches a documented relay with an owner who can confirm it, close the alert with a note that names the approved component. If no owner can account for it within your agreed response window, treat it as hostile until proven otherwise. Confirm these checks with your own runbook owners, since the thresholds for escalation are a local policy decision.

Preserve volatile evidence before anyone reboots, reimages or kills a process. For a suspected relay on Linux or macOS, that means capturing running process listings, open network sockets, and the relevant proxy or forwarding configuration, along with the network flow records that Network Connection Creation and Network Traffic Flow telemetry already hold for the period. On network devices and ESXi hosts, export the running configuration and session tables through the vendor's supported method and record the time of capture. Agree containment with the business owner in advance: isolating a host that carries a production workload is a business decision, and the playbook should state who can approve it and how quickly. Where the choice is between blocking an outbound destination at the perimeter and isolating the endpoint, document the trade-off and the expected service impact before acting.

Scoping means asking which other hosts talked to the same endpoints, ports and destination domains during the same window. Pivot on the destination IP addresses, certificate subjects and domain names from the alert across your Zeek connection logs, Suricata alerts and Wazuh endpoint records, and extend the search backward to the start of your retained history. Any host that shares the destination should be triaged with the same checks, because a single relay often serves several compromised systems. Record every finding against the ATT&CK version named in the detection rule that fired, so later reviewers can reproduce the mapping after the framework changes. Close the loop with lessons learned: record which benign relays generated the alert, add those approved components to an allowlist with an owner and an expiry date, and tune the rule where the false positives came from a predictable source. Review each change in the cyber range before it reaches production, so that tuning does not quietly remove the detection for the behavior it was built to catch.

Questions detection engineers ask about T1090 Proxy

How do I tell a legitimate reverse proxy from a relay used for command and control?

Start with an inventory of approved proxies, load balancers and forwarding services, recorded by host, owner and listening port, because most false positives come from infrastructure nobody wrote down. Then compare behavior against that baseline: an approved reverse proxy should forward requests for known application hostnames to expected backends, while a relay often shows long-lived outbound sessions to a single unfamiliar destination, unusual byte ratios, or a process that was never meant to accept inbound connections. Alerts should carry the parent process, the user context and the destination, so an analyst can clear a known service in minutes rather than re-investigating it each time. Confirm the exact behavior of each approved proxy with its vendor or maintainers before writing exceptions, because a broad allowlist by process name is easy to abuse.

Which data components should I prioritize on network devices for T1090?

On network devices and other platforms, prioritize Network Traffic Flow (DC0078) and Network Connection Creation (DC0082), since these show who talked to whom, when, and for how long without requiring payload inspection. Add Network Traffic Content (DC0085) only where you have a clear legal and operational basis to inspect content, because it is the most expensive and most sensitive source. Confirm with each device vendor which flow records, session logs and syslog fields the device can export, since logging depth varies widely between platforms. Start with edge firewalls and VPN concentrators, where a proxy relay is most likely to cross a trust boundary.

How should I handle encrypted traffic when detecting proxy behavior?

Most proxy detection works on metadata, so you can detect unusual relays without decrypting anything: connection timing, session duration, destination reputation, certificate attributes, and byte patterns. Where policy permits, SSL/TLS Inspection (M1020) can add visibility, but it introduces privacy, legal, performance and certificate-pinning consequences that must be approved before deployment. Document which traffic is excluded from inspection, such as health data or banking sessions, so the gap is a recorded decision rather than an accident. Validate any inspection design in the cyber range before it touches production traffic.

How often should I revalidate T1090 detections after an ATT&CK version change?

Revalidate whenever your target ATT&CK version changes, and check the release notes for the version you map to before assuming the technique or its sub-techniques are unchanged. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and ATT&CK v18 replaced technique-level detections with detection strategies and analytics. Record the ATT&CK version in every rule's metadata so that a later reviewer knows which mapping the rule was written against. Schedule a review after each release you adopt, and rerun the cyber range scenarios for any affected sub-technique.

How do I measure detection coverage for the four T1090 sub-techniques?

Measure coverage per sub-technique and per platform, not as a single percentage, because a rule that works on Linux hosts says nothing about ESXi or network devices. For each sub-technique, record which data components feed the rule, whether the telemetry is actually collected from the in-scope assets, and whether a replayed test produced an alert within the time your response process expects. Gaps are usually telemetry gaps (a host that never forwards logs) rather than rule gaps, so track collection health alongside rule status. Ask your provider or internal team to show the evidence for each claim, including the test date and the ATT&CK version used.

Can my team validate T1090 detections without an outside partner?

Yes, if you have people who can operate Wazuh, Security Onion, Zeek or Suricata, a segregated lab that mirrors your asset types, and a written test plan for each sub-technique. The harder part is independence and repeatability: a team that builds a rule is often the same team that tests it, so an outside reviewer or a structured red team exercise can catch blind spots. DeployOpen runs security testing and private cyber ranges, and its work is defined in a fixed written scope before it starts, so the first step is to decide which parts you want to own internally and which parts you want reviewed. Ask any provider to name the tools, environments and evidence they would deliver.

What should I confirm before rehearsing T1090 detection in a cyber range?

Confirm the ATT&CK version you are testing against, the list of assets and platforms in scope, and the telemetry each asset actually sends to your analytics platform. Agree on rules of engagement, including who approves test traffic, how to avoid disrupting production, and how to stop an exercise quickly. Define success criteria before the exercise starts, such as which alerts should fire, which analyst actions should follow, and what evidence must be retained. Keep the range isolated from production networks, and record the results so they can support both tuning and compliance evidence.

How DeployOpen builds proxy detections and range exercises

Proxy detections only hold up when they are scoped, tested and maintained against the ATT&CK version they target. The cards below describe how DeployOpen plans the engineering work, runs purple team exercises in a private cyber range, records results and supports continuous tuning under a retainer.

Fixed-scope detection engineering

Before work starts, we agree in writing which T1090 Proxy sub-techniques, platforms and telemetry sources are in scope, such as network connection records, process creation and network traffic flow from ESXi, Linux, macOS and network devices. The written scope names the data components each detection depends on and the log sources the client must provide. Ask the vendor to confirm which fields your SIEM or Wazuh deployment actually captures before any rule is written.

Versioning against the ATT&CK release

Every detection is tagged with the ATT&CK version it targets, currently Enterprise ATT&CK 20.0, so that a later release that renames, deprecates or revokes a technique does not silently break coverage. Detection logic is stored as code in version control with a reference to the technique and detection strategy identifiers. Reviewers should check that each rule names its target version and that the mapping is refreshed when MITRE publishes a new release.

Purple team exercises in the range

Detections are validated in a private cyber range where our red team runs controlled proxy scenarios against a replica of the client's segments, and the blue team records what the SIEM and sensors actually saw. Each exercise compares expected alerts with observed alerts and flags gaps in visibility, not only in rule logic. Ask for the scenario list and the isolation controls before any exercise touches a production-like network.

Documented results and evidence

Each exercise produces a report that lists the scenario, the detection that fired or failed, the telemetry used, the analyst response and the remediation owner. Evidence is kept in a format the client can hand to internal audit or an independent assessor, who makes their own determinations. Ask how long evidence is retained and where it is stored, since those decisions belong to the client.

Mitigation checks for filtering and IPS

Two ATT&CK mitigations map most often to proxy behavior: Network Intrusion Prevention and Filter Network Traffic. We review whether egress filtering and intrusion prevention rules are configured to block or alert on the traffic patterns the detections depend on, and we document any gaps. Confirm with your network vendor which signatures and policy features they support before assuming coverage.

Retainers for continuous tuning

Proxy detections drift as network architecture, approved tooling and ATT&CK content change, so a retainer can cover periodic rule tuning, re-running range scenarios after each ATT&CK release and reviewing alert volume with the client's analysts. Retainers are scoped separately from the initial fixed-scope work, and the written agreement should state the review cadence and what triggers an out-of-cycle review. Ask for the cadence before you sign.

T1090 Proxy