T1026 Google Chronicle · YARA-L

Detect Multiband Communication in Google Chronicle

NOTE: This technique has been deprecated by MITRE ATT&CK and should no longer be used in new detections. The behaviors it described are now captured under more specific sub-techniques of T1071 (Application Layer Protocol) and related C2 techniques. Adversaries may split command-and-control (C2) communications between different protocols or network channels. One protocol may carry inbound commands from the operator while a separate protocol carries outbound data from the victim, allowing the adversary to evade firewall rules that inspect a single protocol or threshold-based anomaly detection on any one communication channel. The split may also be randomized across sessions to further avoid detection heuristics. Common patterns include using DNS for data exfiltration while HTTP carries commands, or combining ICMP with HTTPS, or rotating between multiple out-of-band channels based on availability or operator choice.

MITRE ATT&CK

Tactic
Command and Control
Canonical reference
https://attack.mitre.org/techniques/T1026/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule multiband_c2_communication_t1026 {
  meta:
    author = "df00tech"
    description = "Detects T1026 Multiband Communication: non-browser, non-system process making DNS and HTTP/HTTPS connections within 10 minutes, indicating split-channel C2"
    severity = "MEDIUM"
    priority = "MEDIUM"
    mitre_attack_tactic = "Command and Control"
    mitre_attack_technique = "T1026"
    mitre_attack_url = "https://attack.mitre.org/techniques/T1026/"
    platform = "Windows"
    false_positives = "Software update clients, package managers, enterprise applications with custom DNS resolution logic"

  events:
    $dns_conn.metadata.event_type = "NETWORK_CONNECTION"
    $dns_conn.target.port = 53
    $dns_conn.principal.process.file.full_path != /(?i)(chrome|firefox|msedge|iexplore|brave|opera|safari|svchost|lsass|services|wuauclt|MicrosoftEdgeUpdate)\.exe/
    not net.ip_in_range_cidr($dns_conn.target.ip, "10.0.0.0/8")
    not net.ip_in_range_cidr($dns_conn.target.ip, "172.16.0.0/12")
    not net.ip_in_range_cidr($dns_conn.target.ip, "192.168.0.0/16")
    not net.ip_in_range_cidr($dns_conn.target.ip, "127.0.0.0/8")
    $dns_conn.principal.hostname = $hostname
    $dns_conn.principal.process.pid = $pid
    $dns_conn.principal.process.file.full_path = $process_path

    $web_conn.metadata.event_type = "NETWORK_CONNECTION"
    $web_conn.target.port in (80, 443, 8080, 8443)
    $web_conn.principal.hostname = $hostname
    $web_conn.principal.process.pid = $pid
    not net.ip_in_range_cidr($web_conn.target.ip, "10.0.0.0/8")
    not net.ip_in_range_cidr($web_conn.target.ip, "172.16.0.0/12")
    not net.ip_in_range_cidr($web_conn.target.ip, "192.168.0.0/16")
    not net.ip_in_range_cidr($web_conn.target.ip, "127.0.0.0/8")

  match:
    $hostname, $pid, $process_path over 10m

  condition:
    $dns_conn and $web_conn
}
medium severity medium confidence

Chronicle YARA-L 2.0 rule correlating two NETWORK_CONNECTION UDM events within a 10-minute sliding window for the same hostname and process PID: one event targeting port 53 (DNS) and one targeting HTTP/HTTPS ports (80, 443, 8080, 8443). Both events must be from non-browser, non-system processes connecting to non-RFC1918 addresses. The match clause groups by hostname, PID, and process path to confirm a single application uses split-channel communication — the canonical T1026 indicator.

Data Sources

Google Chronicle UDM (Unified Data Model) via Chronicle ForwarderChronicle Ingestion API (endpoint telemetry normalized to UDM)Chronicle third-party log ingestion (Sysmon, EDR telemetry normalized to NETWORK_CONNECTION)

Required Tables

NETWORK_CONNECTION (Chronicle UDM event type)

False Positives & Tuning

  • Endpoint management and MDM agents (Microsoft Intune, Jamf, Tanium) that resolve management server hostnames via DNS and then communicate with them over HTTPS for policy enforcement and check-ins
  • Database connection poolers and ORMs that resolve read-replica or shard endpoints via DNS before establishing HTTPS-tunneled connections within the same connection setup sequence
  • Cloud-native applications and service mesh sidecars (Envoy, Linkerd) that perform explicit DNS-based service discovery before routing HTTP/HTTPS traffic to resolved upstream endpoints
Download portable Sigma rule (.yml)

Other platforms for T1026


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Split Protocol Communication — DNS Query Plus HTTP Fetch from PowerShell

    Expected signal: Sysmon Event ID 3: Two network connection events from powershell.exe — one to 9.9.9.9:53 (DNS) and one to the HTTP destination on port 80. Sysmon Event ID 22: DNS query for 'dns.quad9.net' from powershell.exe. Both events share the same ProcessId, surfacing as a DNS+HTTP multiprotocol combination from a scripting engine.

  2. Test 2Split Protocol Communication — curl with DNS and HTTPS Separation (Linux/macOS)

    Expected signal: Auditd SYSCALL records for connect() syscalls from bash or dig/curl child processes to 8.8.8.8:53 (UDP/TCP) and to the HTTPS destination on port 443. If Sysmon for Linux is deployed: Event ID 3 network connection events showing alternating DNS and HTTPS connections from the parent shell process or its children sharing the same session. Zeek/Suricata network logs will show interleaved DNS and HTTPS flows from the same source IP.

  3. Test 3Three-Protocol Multiband Simulation — DNS, HTTP, and Custom High Port

    Expected signal: Sysmon Event ID 3: Three network connection attempts from powershell.exe — port 53 (DNS resolution of time.windows.com), port 80 (HTTP to checkip.amazonaws.com), and port 8888 (TCP attempt to 1.1.1.1 — connection may be refused or filtered but process creation and connection attempt are still logged). Sysmon Event ID 22: DNS query for time.windows.com. All events share the same ProcessId.

  4. Test 4Sustained Beaconing Simulation Across Two Protocols (Windows)

    Expected signal: Sysmon Event ID 3: Twelve network connection events from powershell.exe over approximately 60 seconds — six to port 53 (DNS) and six to port 80 (HTTP), interleaved at 5-second intervals. Sysmon Event ID 22: Six DNS query events for google.com. The pattern of alternating DNS and HTTP connections within the time bucket will be visible in NetFlow and EDR telemetry as a clear two-band beaconing rhythm.

Unlock Pro Content

Get the full detection package for T1026 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections