How T1665 hide infrastructure shows up in intrusions
T1665 Hide Infrastructure is a Command and Control technique, and it is the reason a SOC lead may see command and control traffic that points to servers nobody can attribute. ATT&CK defines the Command and Control tactic (TA0011) as the adversary trying to communicate with compromised systems to control them. T1665 covers the step where the adversary makes that control infrastructure harder to trace, so the destination looks like ordinary, unowned or unrelated hosting rather than a clearly hostile server. Any detection mapping for this technique should name the ATT&CK version it targets, which for these pages is Enterprise ATT&CK version 20.0, since releases can rename, deprecate or revoke techniques.
For an adversary, concealing infrastructure buys time and resilience. A control server that cannot be quickly tied to a known campaign is harder for defenders to block, sinkhole or add to threat intelligence feeds, and it lets the operator keep working after one endpoint or domain is burned. In practice the trace shows up in the places defenders already collect: outbound connections from servers and endpoints, DNS and proxy records that show short-lived or newly registered destinations, and TLS sessions whose certificates and hosting do not match the business the traffic appears to serve. Alerts of this kind often arrive as generic beaconing or unknown-destination hits, which is why the attribution gap is the signal to investigate rather than the technique name alone.
The practical decision for the SOC lead is whether unattributed command and control destinations are triaged as a separate category. Confirm with your threat intelligence provider and your own asset inventory which destinations are known and approved, then ask who owns the process that resolves an unknown destination to an owner, a business purpose and a block or allow decision. Check that the relevant telemetry, such as network connection records and DNS logs from your sensors, is retained long enough to reconstruct a host's history when attribution is delayed. The detection logic is covered later on this page, but the gap this section names is operational: without a defined path for unattributed control traffic, the alert stays open and the infrastructure stays hidden.
Which telemetry reveals hidden command and control infrastructure
This table maps each telemetry source to the signal it gives for T1665 Hide Infrastructure and the open-source collector that captures it. Read it as a starting point: confirm the data component mappings against the enterprise-attack 20.0 bundle before writing detection content, because mappings can change between ATT&CK versions.
| Telemetry source | Signal for T1665 | Open-source collector | Platform coverage |
|---|---|---|---|
| Network Connection Creation (DC0082) | Outbound sessions to hosting, redirect or relay endpoints that were provisioned to replace a burned or blocked destination, seen as new destinations from a host with no prior history | Wazuh, Velociraptor | ESXi, Linux, macOS, network devices where host logs exist |
| Network Traffic Flow (DC0078) | Shifts in destination ASN, domain fronting patterns, or sudden changes in the set of peers a host talks to after a domain or IP change | Zeek, Security Onion | ESXi, Linux, macOS and network devices via mirrored or flow exports |
| Network Traffic Content (DC0085) | Certificate, host header or server name changes within the same campaign pattern, and protocol metadata that stays constant while endpoints rotate | Zeek, Suricata, Security Onion | Network devices and hosts with mirrored or inspected traffic |
| Process Creation (DC0032) | Hosts launching network-capable processes whose destinations change after a reconfiguration, suggesting an operator edited infrastructure settings locally | Wazuh, Velociraptor | Linux and macOS endpoints; ESXi where process telemetry is forwarded |
| Command Execution (DC0064) | Scripted changes to DNS entries, proxy settings or host routes on a host that should not be managing its own network identity | Wazuh, Velociraptor | Linux and macOS; confirm ESXi shell logging coverage in your environment |
| Network device configuration logs | Unexpected changes to DNS, routing or NAT rules, which can indicate that traffic is being redirected through new infrastructure | Wazuh (syslog ingestion), Security Onion | Network devices via syslog; confirm vendor log formats before parsing |
Detection ideas for hidden infrastructure, described in words
T1665 Hide infrastructure is hard to see because each individual change looks ordinary. The cards below describe detection concepts that look for combinations of destination novelty, unexplained change, certificate anomalies and timing regularity, which together are harder for an adversary to blend into normal traffic. Each concept needs thresholds tuned in your own cyber range before it reaches production.
Rare and newly observed destinations
Track destinations that a host or segment has not contacted within a baseline window, then rank them by how many internal assets reach them and how many bytes move. For T1665 Hide infrastructure, the useful question is whether a destination appeared alongside a change in DNS answers, IP ownership or hosting provider. In the lab, set the baseline length and the rarity cut-off by replaying a known week of normal traffic. Expect false positives from CDNs, cloud load balancers and vendor update services, which rotate addresses often. Maintain allowlists by service name rather than by single address.
Infrastructure changes without business events
Correlate changes in resolved addresses, certificate issuers and hosting autonomous systems for a given service name against change records from your ticketing or deployment system. A destination that moves between providers with no matching change request deserves review. In a cyber range, script planned failovers and vendor certificate renewals so you can measure how often legitimate changes fire the rule. Expected noise sources include managed CDNs, elastic cloud load balancers and automatic vendor update services. Set the alert to require both an address change and an unexplained change record, not either alone.
Certificate and naming anomalies in Zeek logs
Review Zeek SSL and X.509 records for certificates with recently issued validity, unusual subject naming, self-signed chains on external hosts, or a single certificate reused across many unrelated names. These patterns often mark a rebuilt or relocated control server. In the lab, measure how many legitimate internal certificates trigger each rule, then set thresholds on certificate age and name reuse. Typical false positives come from internal certificate authorities, short-lived certificates issued by cloud load balancers and vendor appliances that ship self-signed certificates. Document each exception with an owner and an expiry date.
Beaconing-like regularity in flows
Measure the interval and size consistency of repeated connections from a single host to one destination. Very regular timing with small, similar payloads across many hours can indicate a check-in pattern that an operator has tried to disguise through relocation. Calibrate in the cyber range by generating scheduled, benign polling so the detector learns what a healthy scheduled job looks like. Expect false positives from monitoring agents, time synchronization, certificate renewal checks and vendor telemetry, all of which are regular by design. Use jitter tolerance and exclude known scheduled services by asset owner.
Hosting diversity across one service
Flag when a single internal application or host name resolves through several unrelated hosting providers or regions in a short period. Operators who keep moving infrastructure to stay ahead of blocking often produce this pattern. Validate the rule against your real deployment topology, since multi-region SaaS and disaster recovery designs also spread a service widely. In the lab, simulate a regional failover and a provider migration to see how the alert separates them. Ask your network team for the authoritative list of approved hosting providers before tuning, so that the review queue focuses on destinations outside that list.
How to validate that a hide infrastructure detection fires
This sequence proves, in a private cyber range, that a T1665 Hide Infrastructure detection receives the right telemetry, raises the right alert and does so within a measured time, with a versioned record that an auditor or peer team can re-run. It turns a detection rule from an assumption into evidence.
Agree scope and written rules of engagement
The security lead, the detection engineer and the range operator agree in writing which hosts, network segments, log sources and SIEM tenants are in scope, which are excluded, who may stop the exercise and how to reach them. Rules of engagement state that the emulation runs only inside the cyber range, that no production system or third-party service is touched, and that all activity is time-stamped. The step is complete when every participant has signed off the scope document and the stop conditions.
Define the behavior to emulate
The detection engineer maps the intended behavior to the T1665 Hide Infrastructure page in ATT&CK v20.0 and to the detection strategies and data components listed for it, including Network Connection Creation, Process Creation and Network Traffic Content where they apply to the platforms in scope. The output is a short behavior statement that names the platform, the expected telemetry and the expected alert logic in words only, without any commands or payloads. The emulation plan must say which ATT&CK version it targets.
Run the emulation in the range
The red team or range operator carries out the agreed behavior inside the isolated range, following the written plan and recording start and end times for every action. A second person observes and logs each step in a shared timeline so that later analysis can match actions to telemetry. The step is complete when the planned actions have run or been halted under the stop conditions, and the timeline is saved with the range snapshot.
Confirm telemetry arrives in the SIEM
The detection engineer checks that the expected events from the endpoints, network sensors and platform logs reached the SIEM, with correct timestamps, host identifiers and fields. Gaps are recorded against the data source, not hidden, so that a missing sensor is treated as a finding. The step is complete when each expected data component in the plan has either matching events or a documented gap with an owner and a fix.
Confirm the alert fires as designed
The detection engineer verifies that the rule or analytic produced an alert that matches the expected logic and carries the ATT&CK technique and sub-technique tags. The check also confirms that the alert reached the correct queue or case workflow. If no alert fired, or the wrong one fired, the engineer records whether the cause is logic, field mapping or missing telemetry. The step is complete when the alert record is exported with its identifier and rule version.
Record latency, fidelity and analyst notes
The team calculates detection latency as the time between the first emulated action on the timeline and the alert creation time, and notes the same measure for any gaps. Alert fidelity is judged by whether the alert contained enough context for triage, and whether benign activity in the range also matched. The analyst who triaged the alert writes short notes on what was clear, what was missing and what they would need to act. The output is one record per run with these three measures filled in.
Keep a versioned record against ATT&CK v20.0
The team stores the emulation plan, rule version, data source configuration, range snapshot, timeline and results in version control, tagged with the ATT&CK version (v20.0) and the date of the run. When MITRE releases a later version, the team checks whether the technique, its detection strategies or data components changed and re-runs the affected tests. The record is complete when another engineer can locate the plan, repeat the run and compare the results. Confirm with your own change process how long records must be retained.
Preventive controls that narrow where hidden infrastructure can operate
T1665 Hide infrastructure depends on an adversary reaching the outside world through paths the defender has not closed. The mitigations below narrow those paths at the network edge, inside the network, and on the systems that can be abused to carry traffic. Each one has limits that the client should confirm in its own environment before relying on it.
Network intrusion prevention
Network Intrusion Prevention (M1031) inspects traffic against signatures and behavioral rules and can block flows that match known command and control patterns. For T1665, the value lies in catching hidden or relayed infrastructure that matches known protocol abuse, such as unusual use of a legitimate service. Confirm the rule sets cover the protocols your environment actually uses, and test that blocking does not interrupt business traffic before moving from detect to prevent mode.
Filter network traffic
Filter Network Traffic (M1037) restricts outbound connections to destinations and protocols the business has approved, typically through firewall and egress policies. This is the control that most directly limits where hidden infrastructure can be reached from inside the network. The main limit is operational: allow lists need owners, review cycles and a process for new SaaS endpoints. Ask who approves egress exceptions and how quickly they are retired.
SSL/TLS inspection
SSL/TLS Inspection (M1020) lets the organization see inside encrypted outbound sessions, which is often the only way to recognize command and control hidden behind ordinary HTTPS. Its limits are real operational and legal constraints: certificate pinning breaks, some applications refuse inspected traffic, and decrypting employee or patient traffic needs a documented privacy review and clear notice. Confirm the legal basis, the excluded categories and the key-management process with privacy and legal teams before deployment.
Network segmentation
Network Segmentation (M1030) limits which hosts can reach the internet and which can reach each other, so a compromised workstation or server cannot freely reach an external relay. For T1665, the practical goal is to ensure that servers and privileged systems have no general outbound path. Segmentation is only as strong as its enforcement points, so verify that routing, not just documentation, blocks the path from each segment to the internet.
Disable or remove unneeded features
Disable or Remove Feature or Program (M1042) reduces the number of services that could be turned into hidden relays, such as unused proxy, tunneling or remote access components on servers, network devices and hypervisors. The limit is inventory: teams cannot remove what they have not listed. Ask for a current software and service inventory per host class, and confirm who signs off on exceptions for management and vendor tools that need outbound access.
Triage and response when a hidden infrastructure alert fires
When a T1665 Hide infrastructure alert fires, the first decision is whether the destination is genuinely hidden infrastructure or a legitimate service behind a shared or fronted address. Confirm the destination's ownership history, hosting provider, certificate details and first-seen date from your threat intelligence feeds and passive DNS records before acting. Then pivot to the source host: correlate the Network Connection Creation event with Process Creation and File Creation telemetry for the same window, so you can see which process opened the connection, what it launched beforehand and whether a new binary or script appeared on disk. The question to answer within the first hour is whether the connection belongs to a known application or to something that was staged for the purpose. Record the alert's ATT&CK version and detection identifier in the case so later tuning can be traced.
Scope before you contain. Search your Zeek connection logs, Suricata alerts and firewall records for every host that reached the same destination, IP range or certificate fingerprint over the lookback period you have retained, and note the first and last observed contact on each. Containment is usually an egress block at the perimeter or DNS sinkhole for the specific destination, applied after you confirm the block will not cut off a business-critical service. Isolate the source host only when process or file evidence shows an active implant, and coordinate with the system owner so that business impact is agreed in writing. Preserve evidence first: capture volatile memory and the relevant logs, hash the suspect binaries and keep chain-of-custody notes. Escalate to incident response leadership when the destination is shared across multiple hosts, when the source is a server or network device, or when you cannot establish a benign explanation within your agreed triage window.
After the incident, update the detection and the controls. Add confirmed destinations to your block lists with an expiry date and a reason, and record which Network Intrusion Prevention and Filter Network Traffic rules were triggered so you can judge whether they fired early enough. Review false positives with the application owners and document approved exceptions with a named owner and a review date, rather than silently suppressing the alert. Replay the captured traffic against the updated rule in your private cyber range to confirm that the tuned logic still fires on the original pattern. Finally, confirm with your compliance and audit leads which evidence artefacts from the case, such as preserved logs and approval records for exceptions, your assessment process expects to see.
Rehearsing hide infrastructure detection in a private cyber range
The range should be isolated from production networks and from the internet, with every host, sensor and log path under the client's control. A reasonable illustrative layout places a Linux host, an ESXi management host, a macOS endpoint and a network device (a managed switch or firewall that can export logs) behind a monitored segment. Zeek and Suricata sit on a mirror or tap of that segment, and Wazuh agents or syslog forwarders collect host and device logs into one SOC console. Confirm with each vendor which log sources and sensor modes their products support before you commit to a design.
- Isolated address space: Use non-routable ranges and a documented boundary so that no exercise traffic can leave the lab.
- Sensor placement: Position Zeek and Suricata where they see both north-south and east-west flows, and record what each sensor cannot see.
- Log path inventory: List every source (Linux audit or system logs, ESXi logs, macOS unified logs, device syslog) with its owner and retention setting.
- Time synchronization: Keep all hosts and sensors on one time source so event timelines are reliable during the review.
- Baseline capture: Record normal traffic and host activity before any inject so that deviations can be measured.
Before the first run, check that every log source reaches the SOC console in its expected format.
Injects are scheduled events that the facilitator introduces to test a specific detection or response step. For T1665, injects should describe the behavior in general terms, such as a host that begins talking to an endpoint that is later retired or changed, or a device configuration that is altered outside a change window. The facilitator should not share exploit detail with participants, and the scenario should be labeled as illustrative in the exercise plan. The facilitator keeps a private inject log that records when each event was triggered and what evidence should appear.
- Scenario outline: Write a short illustrative storyline in which an unauthorized change to infrastructure appears alongside normal activity.
- Staged timing: Release injects in an order that lets the SOC build a timeline rather than receive every signal at once.
- Expected evidence: For each inject, define which Zeek, Suricata or Wazuh records should fire, so gaps are visible.
- Adjustment rules: Agree in advance when the facilitator may slow, pause or stop an inject if it disrupts the range.
- Debrief notes: Capture which signals were missed, late or ambiguous, and assign each a follow-up owner.
Review the inject log with the client before the exercise so the scenario reflects the client's own environment.
The SOC team should practice turning a weak signal into a documented case. Good detection in this range means that an alert reaches an analyst with enough context to pivot across hosts, sensors and devices without rebuilding the timeline from scratch. Analysts should check whether a finding matches an approved change, whether the affected host or device is in scope, and whether similar activity appears on other assets. Response steps should follow the client's own runbook, and any containment action should be rehearsed at least once in the lab.
- Alert quality: Measure whether Wazuh rules and Suricata or Zeek notices carry the host, interface and time context analysts need.
- Triage path: Test whether analysts can separate a planned change from an unplanned one using change records available to them.
- Escalation timing: Confirm the handoff from tier one to tier two and record how long each step takes in the range.
- Evidence preservation: Practice collecting host and device logs with hashes and retention notes that would hold up in a post-incident review.
- Containment decision: Rehearse who may isolate a host or segment, and under what approval.
After the exercise, check whether each alert led to a documented decision, not just an acknowledgment.
The network team needs its own rehearsal because many T1665 signals appear first in device configuration, routing or flow data rather than in endpoint logs. Engineers should practice confirming whether a device change was authorized, comparing running configuration with approved baselines, and checking whether traffic patterns on the monitored segment match the expected design. The team should also verify that a rollback or isolation step can be executed without disrupting the rest of the range. Any device-specific command or procedure should come from the vendor's own documentation and be tested in the lab first.
- Configuration comparison: Practice reviewing exported device configuration against a known-good baseline kept under version control.
- Flow review: Check whether Zeek connection logs and Suricata flow records show the change in a form the network team can read.
- Change correlation: Match detected changes against the change calendar and the on-call record.
- Segment isolation: Rehearse a documented segmentation step, then confirm that monitoring stays intact.
- Coordination with the SOC: Agree on a shared channel and a single owner for the incident timeline.
At the end of the session, confirm that the network team's findings were written into the same case record the SOC uses.
Questions detection engineers ask about T1665
How do I separate hidden infrastructure from legitimate CDN use?
Start by treating CDN traffic as a known pattern to baseline, not as a blanket exception. Hidden infrastructure often hides behind shared hosting or CDN front ends, so the useful signal is the mismatch: a host that resolves through a CDN but presents a certificate, server header or request path that does not match the business service it claims to be. Build an allowlist from your own asset inventory and approved SaaS and CDN providers, review it on a schedule, and alert on deviations such as new destinations from servers that never browse the web, or destinations that change frequently for a single process. Confirm how your CDN and proxy vendors expose logs before relying on them.
Which logs do I need for certificate analysis?
You need TLS handshake metadata from the network sensor, certificate fields from passive capture, and the outbound connection records from your endpoints or firewalls that tie a certificate to a process or host. Zeek can record certificate subjects, issuers, validity windows, server names and JA3-style fingerprints where your version supports them, and Suricata can log TLS metadata in EVE JSON. Forward these to your SIEM, for example Wazuh or Security Onion, and keep them long enough to investigate a certificate that was reissued weeks after first use. Confirm field names against the Zeek and Suricata versions you run, because they change between releases.
How should I handle ESXi management traffic in detections?
Treat ESXi management traffic as a high-value, low-noise segment and write rules for it separately from general server traffic. Management interfaces should talk to a short list of vCenter, backup and monitoring systems, so any new outbound destination from the hypervisor management network is a meaningful event. Collect connection telemetry from the network layer, because host-level agents on ESXi are limited and may not be supported in your environment. Confirm with your virtualization vendor which logs and syslog forwarding options your hypervisor version supports before you design the pipeline.
How do I version detections across ATT&CK releases?
Pin every detection to the ATT&CK version it was written against, and record that version in the rule metadata. MITRE publishes ATT&CK content as STIX 2.1 bundles per domain and version, and releases can rename, deprecate or revoke techniques. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, so a mapping valid for one version may need review for another. Store your technique-to-rule mapping as data, regenerate it when you adopt a new bundle, and diff the output so changes to detection strategies or data components are reviewed before they reach production.
How can I test hidden infrastructure detections without touching production?
Rehearse the detections in a private cyber range that mirrors your segmentation, logging pipeline and SIEM, using synthetic hosts and simulated destinations that you own. Define the expected telemetry first, then run controlled tests that generate the same network metadata a defender would expect to see, and confirm that the alert fires, enriches correctly and reaches the right queue. Keep a written test plan with pass criteria, record results, and rerun the tests after every rule or sensor change. DeployOpen builds and operates private cyber ranges as part of its security testing and training work, and the scope and environment are agreed in writing before the exercise begins.
Can my team run this detection work without outside help?
Yes, a team with network monitoring, SIEM and endpoint experience can build and maintain these detections in-house, provided it has time to tune them and a safe place to test. The work splits into three parts: sensor and log collection, detection logic that is reviewed against ATT&CK, and validation in a range. The main risks are alert fatigue from broad CDN and SaaS allowlists, and gaps in ESXi or network device telemetry that teams often discover late. Ask any outside partner to define the written scope, the deliverables and the handover, so you can judge what your own staff can sustain after the engagement ends.
How DeployOpen builds hidden infrastructure detections and range scenarios
DeployOpen approaches T1665 Hide infrastructure as a fixed-scope engagement inside the client's own environment, with the scope agreed in writing before any detection work starts. The work covers telemetry review, detection content for the platforms in scope, validation in a private cyber range and documentation the client's team can run after handover.
How we scope
- Confirm which platforms are in scope, such as ESXi hosts, Linux, macOS and network devices, before detection work begins.
- Inventory which logs exist for network connection creation, process creation and network traffic content in each platform.
- Record the ATT&CK version the detections target, so mappings stay correct after future releases.
How we build
- Write detection logic in open-source formats such as Sigma rules and map it to the relevant detection strategies and data components.
- Tune alerts in the client's own Wazuh, Security Onion, Suricata or Zeek stack to reduce noise from legitimate infrastructure changes.
- Test detections against recorded benign and simulated activity in a private cyber range, not in production systems.
How we hand over
- Deliver written detection documentation covering data sources, logic, known gaps and the ATT&CK mitigations each rule supports.
- Provide range exercise runbooks so the client's analysts can rehearse detection and response on their own schedule.
- Walk through validation results with the operations and security teams and record open items with owners.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Review detections when ATT&CK releases rename, deprecate or revoke techniques that the rules depend on.
- Confirm with the client's auditors which evidence they expect for detection coverage before the assessment begins.
