1200kmSECURITY RESEARCH
Loading interactive filters…

1200KM / simulation

T1665 Hide Infrastructure — Attack Simulation

Adversaries may manipulate network traffic in order to hide and evade detection of their C2 infrastructure. This can be accomplished by identifying and filtering traffic from defensive tools, masking malicious domains to obfuscate the true destination from both automated scanning tools and security researchers, and otherwise hiding malicious artifacts to delay discovery and prolong the effectiveness of adversary infrastructure that could…

Complete technique description

Adversaries may manipulate network traffic in order to hide and evade detection of their C2 infrastructure. This can be accomplished by identifying and filtering traffic from defensive tools,[TA571] masking malicious domains to obfuscate the true destination from both automated scanning tools and security researchers,[Schema-abuse][Facad1ng][Browser-updates] and otherwise hiding malicious artifacts to delay discovery and prolong the effectiveness of adversary infrastructure that could otherwise be identified, blocked, or taken down entirely.

C2 networks may include the use of Proxy or VPNs to disguise IP addresses, which can allow adversaries to blend in with normal network traffic and bypass conditional access policies or anti-abuse protections. For example, an adversary may use a virtual private cloud to spoof their IP address to closer align with a victim's IP address ranges. This may also bypass security measures relying on geolocation of the source IP address.[sysdig][Orange Residential Proxies]

Adversaries may also attempt to filter network traffic in order to evade defensive tools in numerous ways, including blocking/redirecting common incident responder or security appliance user agents.[mod_rewrite][SocGholish-update] Filtering traffic based on IP and geo-fencing may also avoid automated sandboxing or researcher activity (i.e., Virtualization/Sandbox Evasion).[TA571][mod_rewrite]

Hiding C2 infrastructure may also be supported by Resource Development activities such as Acquire Infrastructure and Compromise Infrastructure. For example, using widely trusted hosting services or domains such as prominent URL shortening providers or marketing services for C2 networks may enable adversaries to present benign content that later redirects victims to malicious web pages or infrastructure once specific conditions are met.[StarBlizzard][QR-cofense]

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.

Domain Registration · source-mapped

DC0101 collection page — Query an approved RDAP service/feed, retaining retrieval time and registration-event dates; preserve redaction and missing-field indicators.

Providers and collection configuration

  • Use an approved feed/API or documented lawful export. Store retrieval time, source URL, original record ID, observation time and confidence separately.
  • Retain the raw response, licensing constraints and analyst assessment. Deduplicate observations without erasing independent provenance.
  • Correlate external context with authorized internal observations; do not label ownership, attribution or compromise from a shared indicator alone.

Required normalized fields: domain, event, registrant, retrieved_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": "DC0101",
  "collector": "illustrative-lab-collector",
  "observation": {
    "domain": "example.test",
    "event": "registration",
    "registrant": "redacted",
    "retrieved_at": "2026-09-27T12:00:00Z"
  }
}

Visibility limits: Coverage, licensing, redaction and reporting delays vary. External context is not proof of access to the target, and cannot substitute for unavailable provider-side audit.

Network Connection Creation · source-mapped

DC0082 collection page — Enable scoped Sysmon NetworkConnect (3), disabled by default, or a platform-equivalent process-aware network sensor.

Providers and collection configuration

  • Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
  • Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
  • Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.
  • On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
  • Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
  • For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_guid, destination_ip, destination_port, protocol, initiated.

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": "DC0082",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "destination_ip": "198.51.100.20",
    "destination_port": 443,
    "protocol": "tcp",
    "initiated": true
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

Network Traffic Content · source-mapped

DC0085 collection page — Scope approved packet capture/protocol content collection to the lab flow; retain capture provenance and truncation indicators.

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.
  • 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: flow_id, protocol, method, path, payload_excerpt.

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": "DC0085",
  "collector": "illustrative-lab-collector",
  "observation": {
    "flow_id": "lab-flow-1",
    "protocol": "http",
    "method": "GET",
    "path": "/lab-check",
    "payload_excerpt": "LAB_TELEMETRY_CHECK"
  }
}

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

DC0032 collection page — Collect Sysmon ProcessCreate (1); preserve ProcessGuid and parent identifiers. Security 4688 is an alternative with separate audit/command-line settings.

Providers and collection configuration

  • Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
  • Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
  • Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.
  • On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
  • Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
  • For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_guid, image, parent_image, command_line, user.

<EventFiltering>
  <ProcessCreate onmatch="include">
    <Image condition="is">C:\Windows\System32\whoami.exe</Image>
  </ProcessCreate>
</EventFiltering>

This fragment only selects the named process. It is not a complete production policy. Inspect the installed schema with sysmon64 -s; preserve existing rules, then apply the reviewed complete configuration with sysmon64 -c <configuration-file>.

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": "DC0032",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "image": "C:\\Windows\\System32\\whoami.exe",
    "parent_image": "C:\\Windows\\System32\\cmd.exe",
    "command_line": "whoami",
    "user": "LAB\\analyst"
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

Response Content · source-mapped

DC0104 collection page — Capture responses only from authorized lab services or approved datasets; retain request context, response hash and a sanitized bounded excerpt.

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.
  • 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: service, response_excerpt, content_type, body_truncated.

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": "DC0104",
  "collector": "illustrative-lab-collector",
  "observation": {
    "service": "https://lab.example.test/health",
    "response_excerpt": "LAB_OK",
    "content_type": "text/plain",
    "body_truncated": false
  }
}

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.

Response Metadata · source-mapped

DC0106 collection page — Preserve target, observation time, scan method and response evidence; distinguish inferred service identity from an authenticated software inventory.

Providers and collection configuration

  • Nmap XML reports: Structured port/service observations from a separately authorized scan or existing report.
  • Zeek protocol observations: Passive corroboration for visible service responses; not equivalent to active scan coverage.
  • Use an existing authorized scan report or an explicitly approved isolated target set. Record tool/version, scan options, time window and scope.
  • Preserve native XML and normalized host/port/protocol/service fields. Disable XML external-entity resolution in downstream parsers.
  • Keep inferred service names/versions and their confidence separate from authenticated inventory; retain response evidence when available.

Required normalized fields: target, port, transport, service, version, observation_source.

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": "DC0106",
  "collector": "illustrative-lab-collector",
  "observation": {
    "target": "192.0.2.20",
    "port": 443,
    "transport": "tcp",
    "service": "https",
    "version": "not_identified",
    "observation_source": "authorized_lab_scan"
  }
}

Visibility limits: A reported open port or banner is not a proven vulnerability. Filtered/no-response states can reflect routing or policy. The website performs no scans.

Detection rules and analytic guidance

Open the dedicated detection workspace · Existing query engineering

DET0411 Detection Strategy for Hide Infrastructure

MITRE detection strategy

AN1148 Analytic 1148

Monitor DNS queries, proxy logs, and user-agent strings for anomalous patterns associated with adversary attempts to hide infrastructure. Defenders may observe DNS resolutions to short-lived domains, abnormal WHOIS registration data, or filtering of known defensive/responder IP addresses.

Platforms: Windows.

AN1149 Analytic 1149

Detect adversaries filtering traffic or modifying server responses to evade scanning. Monitor iptables, nftables, or proxy configurations that deny or redirect requests from known scanning agents or defensive tools.

Platforms: Linux.

  • Process Creation — auditd:SYSCALL; channel execve: Execution of commands modifying iptables/nftables to block selective IPs.
  • Response Metadata — NSM:Flow; channel Altered response metadata or blocked content based on user-agent or geolocation.

AN1150 Analytic 1150

Monitor unified logs for manipulation of proxy configurations, DNS resolution, or filtering rules. Adversaries may redirect responses or use trusted domains that later resolve to malicious C2 infrastructure.

Platforms: macOS.

  • Process Creation — macos:unifiedlog; channel System process modifications altering DNS/proxy settings.
  • Response Content — NSM:Flow; channel Suspicious changes in TLS certificate responses or redirected domains.

AN1151 Analytic 1151

Inspect network telemetry for adversary attempts to blend malicious traffic with legitimate flows using VPNs, proxies, or geolocation spoofing. Defensive teams may observe anomalous tunnels, encrypted sessions to suspicious domains, or geo-mismatched IP activity.

Platforms: Network Devices.

AN1152 Analytic 1152

Monitor VM-level DNS and network traffic logs for adversary-controlled domains or selective response behavior (e.g., dropped requests from security scanners).

Platforms: ESXi.

  • Domain Registration — esxi:vmkernel; channel DNS lookups resolving to domains with rapid changes in registration metadata.
  • Network Traffic Content — esxi:vmkernel; channel Suspicious traffic filtered or redirected by VM networking stack.
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 T1665 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.

  • External context and intelligence: Changes in external infrastructure, registration or published intelligence can supply context. They do not expose private attacker actions or establish a victim-side detector; preserve timestamps and attribution uncertainty.
  • Endpoint activity: Per host role and user: rare process/object combinations, bursts of object access or modification, and ordered parent/action sequences. Compare maintenance windows and signed software rollout activity.
  • 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.
  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.

Software observed in source procedures

These are exact ATT&CK software-use relationships, including malware. They provide behavior context, not recommendations to download or execute malware. No safety or detector claim is inherited.

3 source-documented software associations
  • S1111 DarkGate — malware.

    DarkGate command and control includes hard-coded domains in the malware masquerading as legitimate services such as Akamai CDN or Amazon Web Services.[Trellix Darkgate 2023]

    Exact relationship: relationship--7cde9b70-5de6-4aed-be28-27072987f2e8
  • S1164 UPSTYLE — malware.

    UPSTYLE attempts to retrieve a non-existent webpage from the command and control server resulting in hidden commands sent via resulting error messages.[Volexity UPSTYLE 2024]

    Exact relationship: relationship--f3ab39f8-8b3e-429d-8eea-f264c0668d86
  • S1206 JumbledPath — malware.

    JumbledPath can use a chain of jump hosts to communicate with compromised devices to obscure actor infrastructure.[Cisco Salt Typhoon FEB 2025]

    Exact relationship: relationship--7539909c-0239-4d96-8d9a-cf694fc10ce2

Simulation design and documented procedures

Atomic evidence: no compatible candidate in this snapshot. Live lab status: not run for these imported procedures.

Use disposable lab hosts and test accounts, explicit target allowlists, a clean snapshot, bounded egress and a restore plan. Review every candidate and dependency before any execution.

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 T1665 Hide Infrastructure; 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 Hide Infrastructure, 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 81113ba98afa2928f3dcff62022539f7ce30c315c32e14422f11ff95ce534352. Definition and procedure context are reproduced from this snapshot, not independently re-investigated incidents.

Connected ecosystem references

Linked tags

Detection and collection

T1665 detection workspace

No reviewed association in this snapshot.

Threat actor context

These are explicit actor-to-technique associations in the existing Threat Matrix snapshot, not attribution of an event or proof that a detector identifies the actor. No tool-to-actor relationship is inferred.

Existing research

Threat Matrix: knowledge routes, evidence and actor context

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.