T1008

Fallback Channels

Command and Control Last updated:

Adversaries may use fallback or alternate communication channels if the primary channel is compromised or inaccessible in order to maintain reliable command and control and to avoid data transfer thresholds. Malware families such as HOPLIGHT, InvisiMole, TrickBot, and BISCUIT implement hard-coded primary and secondary C2 addresses, while others like OilRig's ISMAgent dynamically fall back from HTTP to DNS tunneling. Detection focuses on processes establishing connections to multiple distinct external destinations in sequence — particularly where port diversity (80→443→8080) or protocol switching (HTTP→DNS) is observed — which is anomalous for non-browser processes.

What is T1008 Fallback Channels?

Fallback Channels (T1008) 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 Fallback Channels, 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 high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Command and Control
Technique
T1008 Fallback Channels
Canonical reference
https://attack.mitre.org/techniques/T1008/
Microsoft Sentinel / Defender
kusto 
// Primary detection: non-browser processes connecting to 3+ distinct external IPs
// or 3+ distinct ports within a 1-hour window, indicating fallback C2 behavior
let ExcludedProcesses = dynamic([
  "chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe", "opera.exe", "brave.exe",
  "MicrosoftEdgeUpdate.exe", "MsMpEng.exe", "OneDrive.exe", "Teams.exe", "Slack.exe",
  "Zoom.exe", "Skype.exe", "outlook.exe", "lync.exe", "SearchApp.exe",
  "msedgewebview2.exe", "WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE"
]);
let C2FallbackPorts = dynamic([53, 80, 443, 4443, 8080, 8443, 8888, 1194, 4444, 9443, 2222, 3128]);
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteIPType == "Public"
| where RemotePort in (C2FallbackPorts)
| where not(InitiatingProcessFileName has_any (ExcludedProcesses))
| summarize
    UniqueDestIPs = dcount(RemoteIP),
    UniqueDestPorts = dcount(RemotePort),
    TotalConnections = count(),
    DestinationIPs = make_set(RemoteIP, 10),
    DestinationPorts = make_set(RemotePort, 10),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine,
       InitiatingProcessId, InitiatingProcessParentFileName, bin(Timestamp, 1h)
| where UniqueDestIPs >= 3 or (UniqueDestPorts >= 3 and TotalConnections >= 5)
| extend ConnectionSpanMinutes = datetime_diff('minute', LastSeen, FirstSeen)
| extend RiskScore = case(
    UniqueDestIPs >= 5 and UniqueDestPorts >= 3, "Critical",
    UniqueDestIPs >= 4 or (UniqueDestPorts >= 3 and TotalConnections >= 8), "High",
    UniqueDestIPs >= 3, "Medium",
    "Low"
  )
| project FirstSeen, LastSeen, ConnectionSpanMinutes, DeviceName, AccountName,
    InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName,
    UniqueDestIPs, UniqueDestPorts, TotalConnections, DestinationIPs, DestinationPorts, RiskScore
| sort by UniqueDestIPs desc, UniqueDestPorts desc

Detects potential C2 fallback channel behavior using Microsoft Defender for Endpoint DeviceNetworkEvents. Identifies non-browser processes that connect to three or more distinct external IP addresses, or use three or more distinct ports within a one-hour window. This pattern is characteristic of malware that hard-codes multiple C2 servers (BISCUIT, HOPLIGHT, SslMM) or dynamically tries alternate ports (S-Type: 80→443→8080) when the primary channel fails. Browser and known-legitimate processes are excluded. A risk score is assigned based on the breadth of destination diversity.

high severity medium confidence

Data Sources

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

Required Tables

DeviceNetworkEvents

False Positives

  • Software update clients and package managers (e.g., Windows Update components, npm, pip) that contact multiple CDN endpoints or mirror servers during downloads
  • IT monitoring and management agents (SCCM, Qualys, Tenable) that beacon to multiple management servers or cloud endpoints
  • Backup agents and cloud sync clients (Veeam, Backblaze, Crashplan) contacting multiple storage endpoints
  • Custom business applications with built-in load-balancing or geographic failover logic connecting to multiple cloud provider IPs
  • Security scanning tools and vulnerability assessment agents that make broad outbound connections as part of their normal operation

Sigma rule & cross-platform mapping

The detection logic for Fallback Channels (T1008) 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 T1008 Sigma rules on detection.fyi

Platform-specific guides for T1008

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-13 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 1Sequential HTTP Fallback Simulation (Windows)

    Expected signal: Sysmon Event ID 3: Three sequential network connection events from powershell.exe to 192.0.2.10:80, 192.0.2.11:443, and 192.0.2.12:8080 within seconds of each other. Sysmon Event ID 1: Process creation for powershell.exe with Net.WebClient in the command line. All three connections will fail (no listener), but Sysmon logs all outbound connection attempts.

  2. Test 2DNS Fallback Simulation After HTTP Failure (Linux/macOS)

    Expected signal: Syslog/auditd: curl process creation with failed connections to 192.0.2.50 and 192.0.2.51. dig process creation events for 20 sequential DNS queries to 8.8.8.8 (external resolver). If Sysmon for Linux is deployed: Event ID 3 for curl network connections and dig DNS queries. Network capture shows failed TCP SYN to RFC 5737 IPs followed by UDP/53 query burst to 8.8.8.8.

  3. Test 3Multi-Port C2 Fallback via Netcat (Windows)

    Expected signal: Sysmon Event ID 3: Three network connection events from powershell.exe to 192.0.2.100 on ports 80, 443, and 8080. Connections will time out (no listener). Sysmon Event ID 1: Process creation with TcpClient and multiple ports visible in command line.

  4. Test 4Proxy-Aware Fallback (JHUHUGIT Pattern, Windows)

    Expected signal: Sysmon Event ID 1: powershell.exe with registry access command in arguments. Sysmon Event ID 3: Two outbound network connections — first to 192.0.2.200:443, then to 192.0.2.201:8080. Sysmon Event ID 12/13: Registry read from HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings (proxy settings access). Security Event ID 4663 if object access auditing is enabled.

Response Playbook

Triage

  1. Identify the process making connections to multiple external destinations: note the full image path, command line, parent process, PID, and user context. Is this an expected binary, or does it have an unusual path (e.g., running from %TEMP%, %APPDATA%, or a user-writable directory)?
  2. Enumerate all destination IPs/ports and submit them to threat intelligence (VirusTotal, Shodan, internal TI feed). Do any match known C2 infrastructure, bulletproof hosting ASNs, or recently registered domains?
  3. Establish the timeline: did connections to earlier IPs/ports fail before the process moved to the next destination? Failure-then-fallback sequences are strongly indicative of automated C2 retry logic versus benign load-balanced applications.
  4. Examine port progression: sequential attempts across 80→443→8080→8443 within minutes from a non-browser process is a high-fidelity indicator. Similarly, switching from HTTP ports to port 53 indicates DNS tunneling fallback (observed with OilRig/ISMAgent).
  5. Check for protocol switching: did the same process make both HTTP/HTTPS connections AND DNS queries to external resolvers? Use DeviceNetworkEvents filtering on RemotePort==53 for the same InitiatingProcessId within the same timeframe.
  6. Correlate with process creation events: check DeviceProcessEvents for the same InitiatingProcessId to see the full command line, parent process, and any loaded DLLs. Is the process a known legitimate binary or does it appear masqueraded (e.g., svchost.exe running outside System32)?

Containment

  1. If confirmed malicious: immediately network-isolate the endpoint via EDR isolation or emergency VLAN quarantine to prevent ongoing C2 communication and lateral movement.
  2. Block all identified C2 destination IPs and domains at the perimeter firewall, proxy, and DNS resolver. Use the full list of fallback IPs observed, not just the one actively in use — the malware may rotate back.
  3. If the process is identified as an injected process or LOLBin abuse (e.g., svchost, rundll32): terminate the process and capture a memory dump before termination for forensic analysis.
  4. If credential access is suspected (common post-C2 activity): immediately reset the user account password, revoke Kerberos tickets (run `klist purge` on the host, disable/re-enable account in AD), and invalidate any OAuth tokens for cloud resources.
  5. Review other hosts for similar network patterns in the same time window — fallback channel malware often spreads laterally before C2 is fully established. Search DeviceNetworkEvents for the same destination IPs across all devices.
  6. Preserve the endpoint state: take a forensic snapshot (disk image or memory dump) before any remediation to ensure evidence is preserved for incident investigation.

Evidence Collection

  1. Network flow logs — Sysmon Event ID 3 or DeviceNetworkEvents — for all outbound connections from the suspicious process, including failed attempts and successful connections to fallback destinations
  2. DNS query logs — Sysmon Event ID 22 (DNS Query) or DeviceDnsEvents — to identify any domain-based C2 resolution, DGA-generated domains, or DNS-over-HTTPS attempts
  3. Process memory dump of the suspicious process — use procdump.exe or Task Manager (create dump file) to capture the in-memory configuration including hard-coded C2 addresses and encryption keys
  4. Sysmon Event ID 1 (Process Create) for the process and all children — reveals full command line, parent process, and any spawned tools indicating post-exploitation activity
  5. Sysmon Event ID 7 (Image Load) for the suspicious process — identifies any DLLs loaded that may indicate injection, reflective loading, or use of network libraries
  6. Prefetch files for the suspicious executable — C:\Windows\Prefetch\<PROCESS>-*.pf — reveals execution timestamps and referenced files
  7. Network capture (PCAP) from the endpoint or network tap if available — allows protocol-level analysis to identify C2 protocol, encryption method, and beacon timing
  8. Windows Security Event ID 4688 (Process Creation with command line auditing) or Sysmon Event ID 1 across adjacent hosts to establish lateral movement timeline

Escalation Criteria

  • ! Any destination IP matches known APT infrastructure or is flagged as malicious in threat intelligence — escalate immediately regardless of other indicators
  • ! Protocol switching detected: same process attempts HTTP/HTTPS connections AND then begins making high-volume DNS queries to external resolvers — strongly indicates DNS tunneling fallback (OilRig/ISMAgent pattern)
  • ! Process is running from a non-standard path (outside System32, Program Files) or is masquerading as a legitimate Windows binary based on name but mismatched hash/publisher
  • ! Memory dump analysis reveals hard-coded IP list with 2+ external addresses or contains packed/encrypted payloads indicating sophisticated malware with built-in C2 redundancy
  • ! More than one endpoint exhibits the same multi-destination connection pattern within the same time window — indicates active campaign rather than isolated compromise
  • ! Concurrent signs of post-exploitation: process created credential access tools, modified registry for persistence, or accessed LSASS memory in addition to the C2 fallback behavior

Investigation Guide

Forensic Artifacts

  • > Process memory: strings/YARA scan for multiple IP addresses or domain names in the same memory region — indicative of a hard-coded fallback list (BISCUIT, HOPLIGHT, SslMM all embed primary+backup C2 strings)
  • > Network: Wireshark/PCAP analysis — look for failed TCP SYN packets to one destination immediately followed by successful SYN-ACK to a different IP, confirming automatic failover logic
  • > Registry: HKCU\Software\<malware_key> or HKLM\SYSTEM\CurrentControlSet\Services\<service_name> — malware may persist updated C2 config including fallback addresses (Linfo, Shark store updated C2 in registry/config)
  • > File System: malware configuration files often stored in %APPDATA%, %TEMP%, or alongside the executable — may contain plaintext or encrypted C2 address lists
  • > Windows Event Log: Security Event ID 4656/4663 (object access) if malware reads config files from disk to obtain fallback C2 addresses
  • > DNS cache: `ipconfig /displaydns` output — shows recently resolved domains including fallback C2 domain lookups, revealing domains that may not appear in logs if resolution was cached
  • > Browser proxy settings (if malware uses system proxy): HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings — JHUHUGIT reads proxy settings to route fallback traffic
  • > Scheduled tasks and services: `schtasks /query /fo LIST /v` and `sc query type= all` — malware may create persistence that re-initiates C2 channel if primary connection drops

Tuning Guidance

The primary tuning challenge for T1008 is differentiating legitimate multi-server applications from malicious C2 fallback behavior. Start by building a baseline of which processes in your environment legitimately connect to 3+ distinct external IPs — common culprits are update clients (Windows Update uses multiple IPs), monitoring agents (Datadog, Dynatrace, SolarWinds), backup clients, and cloud sync tools. Allowlist these by process name AND parent process combination, not process name alone — malware may masquerade using the same filename. For the DNS tunneling fallback query, the threshold of 15+ DNS connections to external resolvers from a non-browser process is deliberately conservative; in environments where custom DNS clients are used, raise this to 50+. Pay special attention to non-standard processes making connections to port 53 to non-corporate resolvers — legitimate applications almost always use the system-configured DNS server, not arbitrary external IPs on port 53. The port-hopping hunt query uses a 2-hour bucket; in high-volume environments, reduce this to 30 minutes to reduce false positives from long-running applications that happen to connect to different services over a day. Enable Sysmon Event ID 22 (DNS Query) logging to correlate DNS lookups with network connection events for the same process ID, enabling detection of DGA-based fallback (Ebury) in addition to static fallback IP lists.

Hunting Queries

Hunt for DNS tunneling fallback behavior — processes that make normal HTTP/HTTPS connections AND high-volume DNS connections to external resolvers. This is the pattern observed with OilRig's ISMAgent, which tries HTTP C2 first and falls back to DNS tunneling when HTTP fails. High DNS connection counts (15+) from the same process that also made HTTP connections is anomalous and warrants investigation.

Hunting — KQL
kql 
// Hunt for DNS tunneling fallback: processes that attempt HTTP/HTTPS then switch to DNS
// Correlates high-volume DNS queries from same process that also made HTTP connections
let HTTPConnectors = DeviceNetworkEvents
    | where Timestamp > ago(7d)
    | where RemoteIPType == "Public"
    | where RemotePort in (80, 443, 8080, 8443)
    | where InitiatingProcessFileName !in~ ("chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe")
    | summarize HTTPConnections = count(), HTTPDests = make_set(RemoteIP, 5)
        by DeviceName, InitiatingProcessFileName, InitiatingProcessId, InitiatingProcessCommandLine;
let DNSBeacons = DeviceNetworkEvents
    | where Timestamp > ago(7d)
    | where RemotePort == 53
    | where RemoteIPType == "Public"
    | summarize DNSConnections = count()
        by DeviceName, InitiatingProcessFileName, InitiatingProcessId;
HTTPConnectors
| join kind=inner DNSBeacons on DeviceName, InitiatingProcessFileName, InitiatingProcessId
| where HTTPConnections >= 2 and DNSConnections >= 15
| extend DNSTunnelingLikelihood = case(
    DNSConnections > 100, "Very High",
    DNSConnections > 50, "High",
    DNSConnections > 15, "Medium",
    "Low"
  )
| project DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
    HTTPConnections, HTTPDests, DNSConnections, DNSTunnelingLikelihood
| sort by DNSConnections desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
  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 ConnectionType=case(
    DestinationPort=53, "DNS",
    DestinationPort=80 OR DestinationPort=8080 OR DestinationPort=3128, "HTTP",
    DestinationPort=443 OR DestinationPort=8443 OR DestinationPort=4443, "HTTPS",
    true(), "Other"
  )
| stats
    dc(ConnectionType) as ProtocolTypes,
    count(eval(ConnectionType="DNS")) as DNSConnections,
    count(eval(ConnectionType="HTTP")) as HTTPConnections,
    count(eval(ConnectionType="HTTPS")) as HTTPSConnections
    by host, Image, ProcessId
| where ProtocolTypes >= 2 AND DNSConnections >= 15 AND (HTTPConnections >= 2 OR HTTPSConnections >= 2)
| eval DNSTunnelingLikelihood=case(
    DNSConnections > 100, "Very High",
    DNSConnections > 50, "High",
    true(), "Medium"
  )
| sort - DNSConnections

Hunt for port-hopping behavior where the same process connects to the same external IP on multiple ports in sequence. This is the exact behavior of S-Type malware (primary: port 80, fallback 1: 443, fallback 2: 8080). Seeing a process contact the same external IP on 2+ distinct ports within a short window is a strong indicator of fallback channel logic, as legitimate applications typically use a single port for a given external service.

Hunting — KQL
kql 
// Hunt for sequential port hopping: same process connecting to same external IPs on multiple ports
// Identifies S-Type malware pattern: primary port 80, fallback 443, final fallback 8080
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where RemotePort in (80, 443, 8080, 8443, 4443, 8888, 4444)
| where InitiatingProcessFileName !in~ ("chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe",
    "MicrosoftEdgeUpdate.exe", "OneDrive.exe", "Teams.exe", "outlook.exe")
| summarize
    PortsUsed = make_set(RemotePort),
    UniquePortCount = dcount(RemotePort),
    ConnectionsPerIP = count(),
    TimeRange = datetime_diff('minute', max(Timestamp), min(Timestamp))
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, bin(Timestamp, 2h)
| where UniquePortCount >= 2 and ConnectionsPerIP >= 3
| extend PortHoppingPattern = strcat_array(PortsUsed, ",")
| extend IsKnownFallbackSequence = PortHoppingPattern has_any ("80,443", "443,8080", "80,8080", "80,443,8080")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
    RemoteIP, UniquePortCount, PortsUsed, IsKnownFallbackSequence, TimeRange
| sort by UniquePortCount desc, TimeRange asc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
  NOT (Image="*\\chrome.exe" OR Image="*\\firefox.exe" OR Image="*\\msedge.exe"
    OR Image="*\\iexplore.exe" OR Image="*\\OneDrive.exe" OR Image="*\\Teams.exe")
  NOT (DestinationIp="10.*" OR DestinationIp="192.168.*" OR DestinationIp="172.16.*" OR DestinationIp="127.*")
  (DestinationPort=80 OR DestinationPort=443 OR DestinationPort=8080 OR DestinationPort=8443 OR DestinationPort=4443 OR DestinationPort=4444 OR DestinationPort=8888)
| stats
    dc(DestinationPort) as UniquePortCount,
    values(DestinationPort) as PortsUsed,
    count as TotalConnections,
    earliest(_time) as FirstSeen,
    latest(_time) as LastSeen
    by host, Image, ProcessId, DestinationIp
| where UniquePortCount >= 2 AND TotalConnections >= 3
| eval TimeRangeMinutes = round((LastSeen - FirstSeen) / 60, 1)
| eval PortSequence=mvjoin(PortsUsed, ",")
| eval IsKnownFallbackSequence=if(match(PortSequence, "(80.*443|443.*8080|80.*8080|80.*443.*8080)"), "Yes", "No")
| sort - UniquePortCount

Hunt for processes connecting to multiple IPs within the same subnets — a pattern that emerges when malware has a hard-coded list of C2 servers that were provisioned by the same hosting provider or within the same infrastructure block. BISCUIT, HOPLIGHT, and InvisiMole all use multiple pre-configured C2 addresses. A high IP-to-subnet ratio (several IPs from the same /24) from a non-browser process suggests systematically trying a list of fallback addresses.

Hunting — KQL
kql 
// Hunt for processes with hard-coded C2 fallback lists by identifying
// sequential connections to IPs in the same /24 subnet (common in static C2 configurations)
// or to IPs belonging to the same ASN but different addresses
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where InitiatingProcessFileName !in~ ("chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe",
    "MicrosoftEdgeUpdate.exe", "OneDrive.exe", "Teams.exe", "SearchApp.exe")
| extend RemoteSubnet = strcat(split(RemoteIP, ".")[0], ".", split(RemoteIP, ".")[1], ".", split(RemoteIP, ".")[2])
| summarize
    UniqueIPs = dcount(RemoteIP),
    IPsInSameSubnet = dcount(RemoteSubnet),
    AllIPs = make_set(RemoteIP, 10),
    TotalConnections = count(),
    WindowStart = min(Timestamp),
    WindowEnd = max(Timestamp)
    by DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, bin(Timestamp, 4h)
| where UniqueIPs >= 3 and IPsInSameSubnet >= 2
| extend SpanMinutes = datetime_diff('minute', WindowEnd, WindowStart)
| project WindowStart, DeviceName, AccountName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, UniqueIPs, IPsInSameSubnet, AllIPs, TotalConnections, SpanMinutes
| sort by UniqueIPs desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
  NOT (Image="*\\chrome.exe" OR Image="*\\firefox.exe" OR Image="*\\msedge.exe"
    OR Image="*\\iexplore.exe" OR Image="*\\OneDrive.exe" OR Image="*\\Teams.exe")
  NOT (DestinationIp="10.*" OR DestinationIp="192.168.*" OR DestinationIp="172.16.*" OR DestinationIp="127.*")
| rex field=DestinationIp "(?P<subnet>\d+\.\d+\.\d+)\.\d+"
| bucket _time span=4h
| stats
    dc(DestinationIp) as UniqueIPs,
    dc(subnet) as UniqueSubnets,
    values(DestinationIp) as AllIPs,
    count as TotalConnections
    by _time, host, Image, ProcessId
| where UniqueIPs >= 3 AND UniqueIPs > UniqueSubnets
| eval SameSubnetConcentration = round(UniqueIPs / UniqueSubnets, 2)
| where SameSubnetConcentration >= 1.5
| sort - UniqueIPs

Atomic Red Team Tests

Test 1 Sequential HTTP Fallback Simulation (Windows)
windows

Simulates a malware fallback channel by attempting HTTP connections to a primary C2 address (which fails), then to two fallback addresses, using PowerShell's .NET WebClient. This mimics the exact pattern of BISCUIT (primary then secondary C2) and S-Type (port 80 primary, 443 fallback). The addresses are RFC 5737 documentation IPs that will not route, triggering connection failures.

Command

powershell 
powershell.exe -NoProfile -Command "$c2_list = @('http://192.0.2.10:80/beacon', 'http://192.0.2.11:443/beacon', 'http://192.0.2.12:8080/beacon'); foreach ($c2 in $c2_list) { try { $wc = New-Object Net.WebClient; $wc.DownloadString($c2) } catch { Write-Host "Failed $c2, trying next" } }; Write-Host 'Fallback sequence complete'"

Expected Telemetry

Sysmon Event ID 3: Three sequential network connection events from powershell.exe to 192.0.2.10:80, 192.0.2.11:443, and 192.0.2.12:8080 within seconds of each other. Sysmon Event ID 1: Process creation for powershell.exe with Net.WebClient in the command line. All three connections will fail (no listener), but Sysmon logs all outbound connection attempts.

Expected Detection

Primary detection fires: powershell.exe connects to 3 distinct external IPs (UniqueDestIPs=3) on multiple ports (UniqueDestPorts=3) within the 1-hour window. KQL: RiskScore='Medium' to 'High' depending on port diversity. SPL: UniqueDestIPs=3, UniqueDestPorts=3. Port-hopping hunt query also fires for sequential 80→443→8080 on sequential IPs.

Test 2 DNS Fallback Simulation After HTTP Failure (Linux/macOS)
linux

Simulates the OilRig ISMAgent fallback pattern: first attempts HTTP C2 (fails), then falls back to high-volume DNS queries to an external resolver. The DNS queries simulate DNS tunneling C2 by sending encoded data as subdomains. Uses curl for HTTP and dig for DNS queries.

Command

bash 
# Step 1: Attempt HTTP C2 (will fail)
curl -s --connect-timeout 3 http://192.0.2.50/c2 || true
curl -s --connect-timeout 3 http://192.0.2.51/c2 || true
# Step 2: Fall back to DNS queries (simulating DNS tunneling)
for i in $(seq 1 20); do
  dig @8.8.8.8 "beacon-$(date +%s)-${i}.example.com" A +short > /dev/null 2>&1
  sleep 0.5
done
echo 'DNS fallback simulation complete'

Expected Telemetry

Syslog/auditd: curl process creation with failed connections to 192.0.2.50 and 192.0.2.51. dig process creation events for 20 sequential DNS queries to 8.8.8.8 (external resolver). If Sysmon for Linux is deployed: Event ID 3 for curl network connections and dig DNS queries. Network capture shows failed TCP SYN to RFC 5737 IPs followed by UDP/53 query burst to 8.8.8.8.

Expected Detection

DNS tunneling fallback hunt query fires: same host shows HTTP connection attempts (curl) AND 20+ DNS connections to external resolver (dig to 8.8.8.8) within the same time window. Splunk DNS Tunneling Likelihood evaluates as 'Medium' (20 DNS connections). In environments with auditd, process execution events corroborate the fallback sequence.

Test 3 Multi-Port C2 Fallback via Netcat (Windows)
windows

Simulates a process attempting connections across multiple C2 fallback ports in the exact sequence used by S-Type malware: port 80, then 443, then 8080. Uses PowerShell TCP client to attempt connections to a single external IP (documentation range) on each port sequentially — matching the behavior of malware that tries each port until one responds.

Command

powershell 
powershell.exe -NoProfile -Command "$target = '192.0.2.100'; $ports = @(80, 443, 8080); foreach ($port in $ports) { $tcp = New-Object System.Net.Sockets.TcpClient; try { $result = $tcp.BeginConnect($target, $port, $null, $null); $success = $result.AsyncWaitHandle.WaitOne(2000, $false); if ($success) { Write-Host "Connected on port $port" } else { Write-Host "Timeout on port $port, trying next" } } catch { Write-Host "Failed port $port: $($_.Exception.Message)" } finally { $tcp.Close() } }"

Expected Telemetry

Sysmon Event ID 3: Three network connection events from powershell.exe to 192.0.2.100 on ports 80, 443, and 8080. Connections will time out (no listener). Sysmon Event ID 1: Process creation with TcpClient and multiple ports visible in command line.

Expected Detection

Port-hopping hunt query fires: powershell.exe connects to same IP (192.0.2.100) on 3 distinct ports (80, 443, 8080). KQL: UniquePortCount=3, IsKnownFallbackSequence=true (80,443,8080 pattern). SPL: UniquePortCount >= 2, PortSequence matches fallback pattern regex. Primary detection also fires: UniqueDestPorts=3, TotalConnections >= 3.

Test 4 Proxy-Aware Fallback (JHUHUGIT Pattern, Windows)
windows

Simulates the JHUHUGIT fallback sequence: first attempts direct C2 connection, then reads system proxy settings and retries through the proxy, mimicking how sophisticated malware adapts to network controls. This test reads the system proxy configuration and attempts connections both directly and through the configured proxy.

Command

powershell 
powershell.exe -NoProfile -Command "# Attempt 1: Direct connection
$direct = '192.0.2.200'; $port = 443;
try { $r = [System.Net.WebRequest]::Create(\"http://$direct:$port/\"); $r.Timeout=3000; $r.GetResponse() } catch { Write-Host 'Direct failed, reading proxy config' }
# Attempt 2: Read system proxy settings
$proxy_setting = (Get-ItemProperty 'HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings').ProxyServer;
Write-Host \"System proxy: $proxy_setting\"
# Attempt 3: Try alternate IP (fallback C2)
$fallback = '192.0.2.201';
try { $r2 = [System.Net.WebRequest]::Create(\"http://$fallback:8080/\"); $r2.Timeout=3000; $r2.GetResponse() } catch { Write-Host \"Fallback $fallback also failed\" }"

Expected Telemetry

Sysmon Event ID 1: powershell.exe with registry access command in arguments. Sysmon Event ID 3: Two outbound network connections — first to 192.0.2.200:443, then to 192.0.2.201:8080. Sysmon Event ID 12/13: Registry read from HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings (proxy settings access). Security Event ID 4663 if object access auditing is enabled.

Expected Detection

Primary detection fires: powershell.exe connects to 2 distinct external IPs on 2 distinct ports within the window. Partial hit on the port-hopping hunt query. Additionally, registry access to Internet Settings proxy key combined with subsequent network connections is a behavioral pattern associated with JHUHUGIT and proxy-aware malware families.

Related Detections

Tactic Hub

TA0011Command and Control

Related Techniques

T1071Application Layer ProtocolT1071.004DNST1568Dynamic ResolutionT1568.001Fast Flux DNST1568.002Domain Generation AlgorithmsT1573Encrypted ChannelT1573.001Symmetric CryptographyT1090ProxyT1090.003Multi-hop ProxyT1219Remote Access Tools

Same Tactic: Command and Control

Popular Detections