T1026

Multiband Communication

Command and Control Last updated:

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.

What is T1026 Multiband Communication?

Multiband Communication (T1026) maps to the Command and Control tactic — the adversary is trying to communicate with compromised systems to control them in MITRE ATT&CK.

This page provides production-ready detection logic for Multiband Communication, covering the data sources and telemetry it touches: Network Traffic: Network Connection Creation, Network Traffic: Network Traffic Flow, Microsoft Defender for Endpoint. The queries below are rated medium severity at low confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Command and Control
Canonical reference
https://attack.mitre.org/techniques/T1026/
Microsoft Sentinel / Defender
kusto 
// Detect processes making outbound connections using multiple distinct protocol categories
// within a 10-minute window, which may indicate split-channel C2 communication
let ExcludedBrowsers = dynamic(["chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe", "brave.exe", "opera.exe", "safari.exe"]);
let ExcludedSystemProcs = dynamic(["svchost.exe", "lsass.exe", "services.exe", "wuauclt.exe", "MicrosoftEdgeUpdate.exe"]);
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where ActionType in ("ConnectionSuccess", "InboundConnectionAccepted")
| where RemoteIPType == "Public"
| where not(InitiatingProcessFileName has_any (ExcludedBrowsers))
| where not(InitiatingProcessFileName has_any (ExcludedSystemProcs))
| extend ProtocolCategory = case(
    RemotePort == 53, "DNS",
    RemotePort == 80 or RemotePort == 8080, "HTTP",
    RemotePort == 443 or RemotePort == 8443, "HTTPS",
    RemotePort == 25 or RemotePort == 587 or RemotePort == 465, "SMTP",
    RemotePort == 21 or RemotePort == 20, "FTP",
    RemotePort == 22, "SSH",
    RemotePort == 123, "NTP",
    RemotePort == 161 or RemotePort == 162, "SNMP",
    true, strcat("Other:", tostring(RemotePort))
)
| summarize
    ProtocolSet = make_set(ProtocolCategory),
    DistinctPortCount = dcount(RemotePort),
    ConnectionCount = count(),
    UniqueRemoteIPs = dcount(RemoteIP),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    SampleCmdLine = take_any(InitiatingProcessCommandLine)
    by DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessId, bin(Timestamp, 10m)
| extend ProtocolCount = array_length(ProtocolSet)
| where ProtocolCount >= 3
    or (ProtocolCount >= 2 and ProtocolSet has "DNS" and ProtocolSet has_any ("HTTP", "HTTPS"))
    or (ProtocolCount >= 2 and ProtocolSet has "DNS" and ProtocolSet has "Other:")
| project
    FirstSeen,
    LastSeen,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    InitiatingProcessId,
    ProtocolSet,
    ProtocolCount,
    DistinctPortCount,
    ConnectionCount,
    UniqueRemoteIPs,
    SampleCmdLine
| sort by FirstSeen desc

Detects processes that make outbound network connections using three or more distinct protocol categories, or that combine DNS with HTTP/HTTPS or other non-standard protocols, within a 10-minute window. This pattern is characteristic of multiband C2 where operators split inbound commands and outbound data across different channels to evade single-protocol monitoring rules. Standard web browsers and known system processes are excluded. Remaining process-level alerts with high protocol diversity or DNS+HTTP combinations warrant analyst review.

medium severity low confidence

Data Sources

Network Traffic: Network Connection Creation Network Traffic: Network Traffic Flow Microsoft Defender for Endpoint

Required Tables

DeviceNetworkEvents

False Positives

  • Network monitoring or diagnostic tools (Wireshark, netstat wrappers, custom scripts) that open connections across multiple protocols as part of legitimate testing
  • Update clients and package managers that contact DNS resolvers and then fetch payloads over HTTPS, then may send telemetry via a separate channel
  • Remote management agents (Ansible, Puppet, Chef client) that may use multiple protocols during configuration application phases
  • Security scanning tools or vulnerability assessment agents that probe multiple services simultaneously across different protocols
  • Backup agents that use separate channels for metadata (DNS/HTTP control plane) and data transfer (custom protocol over high port)

Sigma rule & cross-platform mapping

The detection logic for Multiband Communication (T1026) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1026 Sigma rules on detection.fyi

Platform-specific guides for T1026

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-18 Research depth: deep
References (5)

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.

Response Playbook

Triage

  1. Identify the triggering process: examine the full image path, parent process, and command line. Is this a known administrative tool, scripting engine, or an unusual binary from a non-standard path (e.g., AppData, Temp, user-writable directories)?
  2. Review the specific protocol combination flagged: DNS+HTTP is a known C2 split pattern — check whether DNS queries precede HTTP connections to the same external IP ranges, suggesting the DNS channel is being used for data exfiltration or command receipt while HTTP handles the opposite direction.
  3. Inspect the destination IPs for each protocol category. Cross-reference against threat intelligence (VirusTotal, Shodan, AbuseIPDB). Are the DNS and HTTP destinations the same host, different hosts operated by the same actor, or part of a CDN or infrastructure provider?
  4. Check the volume and timing of connections: multiband C2 often shows beaconing patterns (regular intervals) across protocols. Look for DNS queries at fixed intervals (e.g., every 30s or 60s) combined with sporadic HTTP POST activity that could represent data exfiltration bursts.
  5. Correlate with Sysmon Event ID 22 (DNS Query) to identify the domain names being resolved. Legitimate traffic will resolve recognizable domains; malicious actors may use algorithmically generated domains (DGAs) or newly registered domains.
  6. Examine the process's network history over the past 24-48 hours: has it only recently started using multiple protocols, or is this a baseline pattern? A sudden shift to multi-protocol behavior in a long-running process may indicate in-memory injection or process hollowing.

Containment

  1. If active C2 communication is confirmed: isolate the endpoint immediately using EDR network isolation to prevent further command execution and data exfiltration while preserving the running process state for forensic capture.
  2. Block all destination IPs and domains identified across the multiband channels at the perimeter firewall, DNS sinkhole, and web proxy simultaneously — failing to block all channels allows the adversary to fall back to the remaining active protocol.
  3. If the process is injected or suspicious: suspend (do not terminate) the process and capture a full process memory dump before containment, as C2 configuration, keys, and collected data may exist only in memory.
  4. Revoke and rotate credentials for any accounts active on the compromised host during the multiband communication window, particularly service accounts or privileged accounts that may have been harvested.
  5. Review and quarantine any files written by the triggering process during the multiband communication period — exfiltrated staging files may have been deposited to disk before transmission.

Evidence Collection

  1. Full Sysmon Event ID 3 (Network Connection) log for the triggering process across the entire suspected compromise window — export all destination IPs, ports, and timestamps for timeline reconstruction.
  2. Sysmon Event ID 22 (DNS Query) records correlating with the network connection events — domain names resolved in proximity to the multi-protocol connections are high-value IOCs.
  3. Process memory dump of the triggering process using procdump.exe or via EDR: `procdump.exe -ma <PID> C:\Evidence\<processname>_<PID>.dmp`
  4. NetFlow or firewall session logs for the host covering the detection window — these provide byte counts and packet counts per session that help differentiate data exfiltration volumes across each protocol channel.
  5. Sysmon Event ID 1 (Process Create) for the triggering process and all child processes spawned during the multiband communication period.
  6. Sysmon Event ID 11 (File Create) and Event ID 23 (File Delete) events from the triggering process — any files staged for exfiltration or written as implant components.
  7. Windows Event ID 4624/4625 logon events from the host during the window — lateral movement using harvested credentials may follow C2 communication.
  8. Packet capture (PCAP) if available from network TAP or EDR: `netsh trace start capture=yes tracefile=C:\Evidence\trace.etl` (requires admin; stop with `netsh trace stop`)

Escalation Criteria

  • ! DNS query volume from the process exceeds baseline by 5x or more and resolves algorithmically diverse or newly registered domains (< 30 days old), combined with HTTP POST activity — strongly indicates DNS tunneling for data exfiltration with HTTP C2.
  • ! Identified destination IPs appear in threat intelligence feeds as known C2 infrastructure, regardless of protocol — escalate immediately as confirmed active C2.
  • ! Process image path is non-standard (running from %TEMP%, %APPDATA%, user profile directories) combined with multi-protocol network activity — high confidence of malicious implant.
  • ! Multi-protocol behavior observed simultaneously across multiple endpoints pointing to the same external infrastructure — possible lateral movement or worm-like propagation with centralized C2.
  • ! Network connections include protocols not expected for the process type (e.g., a document viewer making DNS queries to external resolvers followed by outbound SMTP) — indicates process hollowing or injected implant.

Investigation Guide

Forensic Artifacts

  • > Windows DNS client cache: `ipconfig /displaydns` — reveals recently resolved domain names including those used in the DNS C2 channel, even if the process has terminated
  • > Sysmon Event ID 22 (DNS Query) logs in Microsoft-Windows-Sysmon/Operational — per-process DNS resolution events with timestamps, process image, and resolved domain
  • > Windows Firewall logs at `C:\Windows\System32\LogFiles\Firewall\pfirewall.log` — records all allowed and blocked connections with protocol, direction, and port
  • > Browser and system proxy logs — multiband implants may route one channel through a configured proxy while bypassing it on another, leaving asymmetric proxy log entries
  • > NetFlow data from network infrastructure — byte and packet counts per flow help identify which protocol band is carrying bulk data (exfil) vs. low-volume commands
  • > Process memory forensics — C2 configuration structures in memory often contain lists of protocols and fallback channels; look for arrays of IP/domain+port tuples at consistent offsets
  • > Prefetch files (`C:\Windows\Prefetch\`) — for the triggering process, loaded DLLs may indicate which networking libraries (WinHTTP, WinSock, DNS API, ICMP.dll) were in use
  • > ETW (Event Tracing for Windows) captures from Microsoft-Windows-TCPIP and Microsoft-Windows-Winsock providers — low-level socket activity per process

Tuning Guidance

T1026 is a deprecated technique, so this detection should be considered a behavioral heuristic for identifying split-channel C2 rather than a high-fidelity alert. Start with a 7-day baseline period to identify which processes in your environment legitimately use multiple protocol categories simultaneously — update agents, monitoring tools, and IT automation platforms are frequent legitimate sources. Build an exclusion list of specific process+port combinations rather than blanket process exclusions. Focus analyst attention on detections where: (1) the triggering process is a scripting engine or resides in a user-writable path, (2) the protocol combination includes DNS with non-standard high ports, and (3) the destination IPs are in threat intelligence feeds. Consider layering this detection with DNS query volume anomalies (Sysmon Event ID 22) — if the DNS connection count is disproportionately high relative to the HTTP sessions, DNS tunneling is the more likely explanation. For high-volume environments, raise the threshold to require ProtocolCount >= 4 or add a minimum connection count per protocol (e.g., at least 5 DNS connections AND at least 5 HTTP connections) to reduce noise from transient multi-protocol activity.

Hunting Queries

Hunt for non-browser processes where more than 30% of external connections are to port 53 (DNS) while also making significant non-DNS connections. Legitimate processes rarely generate sustained high-volume DNS traffic alongside other protocol activity. A process combining high DNS connection counts with HTTP or other protocol connections may be using DNS as one band of a split C2 channel.

Hunting — KQL
kql 
// Hunt for non-browser processes with unusually high ratio of DNS connections
// relative to their total connection count — may indicate DNS tunneling as one C2 band
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where not(InitiatingProcessFileName has_any (dynamic(["chrome.exe","firefox.exe","msedge.exe","iexplore.exe","brave.exe"])))
| extend IsDNS = iff(RemotePort == 53, 1, 0)
| summarize
    TotalConnections = count(),
    DNSConnections = sumif(1, RemotePort == 53),
    NonDNSConnections = sumif(1, RemotePort != 53),
    UniqueDestIPs = dcount(RemoteIP),
    ProtocolPorts = make_set(RemotePort)
    by DeviceName, AccountName, InitiatingProcessFileName
| where DNSConnections > 10 and NonDNSConnections > 5
| extend DNSRatio = todouble(DNSConnections) / todouble(TotalConnections)
| where DNSRatio > 0.3
| sort by DNSConnections desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 earliest=-7d
  NOT (Image="*\\chrome.exe" OR Image="*\\firefox.exe" OR Image="*\\msedge.exe" OR Image="*\\iexplore.exe")
  NOT (DestinationIp="10.*" OR DestinationIp="192.168.*" OR DestinationIp="172.16.*" OR DestinationIp="127.*")
| eval IsDNS=if(DestinationPort==53, 1, 0)
| stats
    count as TotalConnections,
    sum(IsDNS) as DNSConnections,
    dc(DestinationIp) as UniqueIPs,
    values(DestinationPort) as Ports
    by host, Image, User
| eval NonDNSConnections=TotalConnections-DNSConnections
| eval DNSRatio=round(DNSConnections/TotalConnections, 2)
| where DNSConnections > 10 AND NonDNSConnections > 5 AND DNSRatio > 0.3
| sort - DNSConnections

Hunt for persistent processes that use multiple protocol categories across multiple hourly windows over a 7-day lookback. Legitimate processes tend to use consistent protocol patterns; a process that alternates between DNS, HTTP, and other protocol connections across many hours is exhibiting the time-sliced protocol rotation characteristic of multiband C2 frameworks designed to avoid per-protocol traffic volume thresholds.

Hunting — KQL
kql 
// Hunt for processes that alternate connection patterns across multiple protocols
// over an extended period — characteristic of time-sliced multiband C2
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where not(InitiatingProcessFileName has_any (dynamic(["chrome.exe","firefox.exe","msedge.exe","iexplore.exe","svchost.exe","lsass.exe"])))
| extend PortBucket = case(
    RemotePort == 53, "DNS(53)",
    RemotePort == 80, "HTTP(80)",
    RemotePort == 443, "HTTPS(443)",
    RemotePort between (1024 .. 49151), strcat("Registered(", tostring(RemotePort), ")"),
    strcat("Ephemeral(", tostring(RemotePort), ")")
)
| summarize
    HourlyProtocols = make_set(PortBucket),
    HourCount = count()
    by DeviceName, InitiatingProcessFileName, InitiatingProcessId, bin(Timestamp, 1h)
| where array_length(HourlyProtocols) >= 2
| summarize
    DistinctProtocolHours = count(),
    AllProtocols = make_set(HourlyProtocols),
    TotalConnections = sum(HourCount)
    by DeviceName, InitiatingProcessFileName
| where DistinctProtocolHours >= 3
| sort by DistinctProtocolHours desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 earliest=-7d
  NOT (Image="*\\chrome.exe" OR Image="*\\firefox.exe" OR Image="*\\msedge.exe" OR Image="*\\svchost.exe" OR Image="*\\lsass.exe")
  NOT (DestinationIp="10.*" OR DestinationIp="192.168.*" OR DestinationIp="172.16.*" OR DestinationIp="127.*")
| eval PortBucket=case(
    DestinationPort==53, "DNS",
    DestinationPort==80, "HTTP",
    DestinationPort==443, "HTTPS",
    1==1, "Other:".DestinationPort
)
| bucket span=1h _time
| stats values(PortBucket) as HourProtocols, count as HourConns by _time, host, Image, ProcessId
| eval HourProtocolCount=mvcount(HourProtocols)
| where HourProtocolCount >= 2
| stats count as DistinctProtocolHours, values(HourProtocols) as AllProtocols, sum(HourConns) as TotalConnections by host, Image
| where DistinctProtocolHours >= 3
| sort - DistinctProtocolHours

Hunt for scripting engines and system utilities (PowerShell, cmd.exe, wscript.exe, Python, Node.js, bash) making both DNS connections and high-port connections to external IPs. Legitimate uses of these tools rarely require them to directly resolve DNS while also connecting to non-standard high ports. This combination is characteristic of C2 implants that use scripting engines as hosting processes for multiband communication, where DNS carries encoded data and high-port TCP/UDP carries commands or secondary C2 traffic.

Hunting — KQL
kql 
// Hunt for scripting engines or system utilities making both DNS and
// non-standard high-port connections — unusual for legitimate use and
// commonly seen in LOLBin-based multiband C2 implementations
let ScriptingEngines = dynamic(["powershell.exe","pwsh.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","python.exe","python3.exe","perl.exe","ruby.exe","node.exe","bash.exe"]);
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where InitiatingProcessFileName has_any (ScriptingEngines)
| summarize
    DNSConnections = countif(RemotePort == 53),
    HTTPConnections = countif(RemotePort in (80, 443, 8080, 8443)),
    HighPortConnections = countif(RemotePort > 1024 and RemotePort !in (8080, 8443)),
    TotalConnections = count(),
    UniqueIPs = dcount(RemoteIP),
    PortSet = make_set(RemotePort),
    SampleCmdLine = take_any(InitiatingProcessCommandLine)
    by DeviceName, AccountName, InitiatingProcessFileName
| where DNSConnections > 0 and HighPortConnections > 0
| sort by TotalConnections desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 earliest=-7d
  (Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\cmd.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\mshta.exe" OR Image="*\\python.exe" OR Image="*\\node.exe" OR Image="*\\bash.exe")
  NOT (DestinationIp="10.*" OR DestinationIp="192.168.*" OR DestinationIp="172.16.*" OR DestinationIp="127.*")
| eval IsDNS=if(DestinationPort==53,1,0)
| eval IsHTTP=if(DestinationPort==80 OR DestinationPort==443 OR DestinationPort==8080 OR DestinationPort==8443,1,0)
| eval IsHighPort=if(DestinationPort>1024 AND DestinationPort!=8080 AND DestinationPort!=8443,1,0)
| stats
    sum(IsDNS) as DNSConnections,
    sum(IsHTTP) as HTTPConnections,
    sum(IsHighPort) as HighPortConnections,
    count as TotalConnections,
    dc(DestinationIp) as UniqueIPs,
    values(DestinationPort) as Ports,
    values(CommandLine) as Commands
    by host, Image, User
| where DNSConnections > 0 AND HighPortConnections > 0
| sort - TotalConnections

Atomic Red Team Tests

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

Simulates a basic multiband communication pattern by using a single PowerShell process to perform both DNS resolution (querying an external resolver directly on port 53) and an HTTP fetch to a separate destination. This models the split-channel pattern where DNS carries one data direction and HTTP carries the other. Both connections originate from the same process, triggering the multi-protocol detection rule.

Command

powershell 
powershell.exe -NoProfile -Command "$dns = [System.Net.Dns]::GetHostAddresses('dns.quad9.net'); Write-Output $dns; try { (New-Object Net.WebClient).DownloadString('http://ifconfig.me') } catch {}"

Expected Telemetry

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.

Expected Detection

KQL alert: InitiatingProcessFileName=powershell.exe with ProtocolSet containing both DNS and HTTP categories. SPL alert: HasDNS=1 AND HasHTTP=1 for Image=*\powershell.exe. Scripting engine hunting query will also fire on DNSConnections > 0 AND HTTPConnections > 0.

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

On Linux or macOS, uses a shell script to simulate a multiband agent that alternates between DNS lookups using dig (simulating a DNS C2 channel polling for commands) and HTTPS GET requests (simulating a data exfiltration channel). The commands execute from the same shell process within a short time window.

Command

bash 
bash -c 'for i in $(seq 1 3); do dig +short TXT @8.8.8.8 google.com; curl -sk https://ifconfig.me -o /dev/null; sleep 2; done'

Expected Telemetry

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.

Expected Detection

SPL query for linux_secure or syslog sourcetypes with process making both DNS (port 53) and HTTPS (port 443) external connections within the 10-minute bucket. If Sysmon for Linux deployed, the XmlWinEventLog SPL query adapted to Linux EventCode=3 events will fire on HasDNS=1 AND HasHTTP=1.

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

Simulates the three-protocol multiband pattern that triggers the highest-confidence detection rule variant. A PowerShell process performs DNS resolution, an HTTP fetch, and then a TCP connection attempt to a non-standard high port. This mimics C2 frameworks that use HTTP for beaconing, DNS for command encoding, and a third channel (custom port) for bulk data transfer or fallback.

Command

powershell 
powershell.exe -NoProfile -Command "[System.Net.Dns]::GetHostAddresses('time.windows.com'); try { (New-Object Net.WebClient).DownloadString('http://checkip.amazonaws.com') } catch {}; try { $t = New-Object System.Net.Sockets.TcpClient; $t.ConnectAsync('1.1.1.1', 8888).Wait(2000); $t.Close() } catch {}"

Expected Telemetry

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.

Expected Detection

KQL alert fires with ProtocolCount >= 3, ProtocolSet containing DNS, HTTP, and Other:8888. SPL alert fires with ProtocolCount >= 3. Both primary detection queries trigger on this three-protocol pattern. The scripting engine hunting query also fires.

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

Simulates the sustained multi-protocol beaconing pattern that triggers the time-sliced hunting query. A script runs for several minutes, alternating between DNS lookups and HTTP connections at regular intervals. This models the behavior of C2 implants designed to spread traffic across protocols to avoid per-protocol volume threshold alerts.

Command

powershell 
powershell.exe -NoProfile -Command "1..6 | ForEach-Object { [System.Net.Dns]::GetHostAddresses('google.com') | Out-Null; Start-Sleep -Seconds 5; try { (New-Object Net.WebClient).DownloadString('http://www.google.com') | Out-Null } catch {}; Start-Sleep -Seconds 5 }"

Expected Telemetry

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.

Expected Detection

KQL primary query fires on ProtocolCount=2 with DNS and HTTP within the 10-minute bucket. SPL primary query fires with HasDNS=1 AND HasHTTP=1. The sustained beaconing hunting query (hourly protocol diversity) fires after the second execution window. DNSRatio hunting query will show approximately 50% DNS ratio triggering the > 0.3 threshold.

Related Detections

Tactic Hub

TA0011Command and Control

Related Techniques

T1071Application Layer ProtocolT1071.001Web ProtocolsT1071.004DNST1048Exfiltration Over Alternative ProtocolT1048.001Exfiltration Over Symmetric Encrypted Non-C2 ProtocolT1132Data EncodingT1573Encrypted ChannelT1568Dynamic ResolutionT1095Non-Application Layer ProtocolT1041Exfiltration Over C2 Channel

Same Tactic: Command and Control

Popular Detections