Threat Hunting Exercise: Analyzing Firewall Outbound C2 Beaconing over Non-Standard Ports Dataset

This hunt pivots to perimeter firewall telemetry: a simulated next-gen firewall dataset (fw_outbound_beacon_2022-04-02T000000.json) capturing T1071.001: Application Layer Protocol - Web Protocols and T1571: Non-Standard Port, where an implant on an internal workstation beacons out to an external IP on an uncommon TCP port at a fixed interval, blending in with normal outbound traffic volume but not with normal outbound traffic pattern.

Step 1: Hypothesis Formation

Hypothesis: A compromised host establishes recurring outbound connections to a single external IP on a non-standard port (e.g., TCP/8443, TCP/4444, TCP/50050) at a highly regular interval (jitter under 5%), with a small, consistent payload size per session - consistent with C2 check-in beaconing rather than human-driven browsing or a known application. Indicators:

• Firewall ALLOW logs: repeated outbound sessions, same src/dst pair, same dst port, near-identical byte counts, interval clustering around a fixed period (e.g., every 60s ± 2s).
• Destination ASN/geolocation inconsistent with any business relationship (no prior DNS resolution to a known corporate SaaS domain).
• No corresponding proxy/DNS log entry for the destination - traffic goes IP-direct, bypassing web proxy and DNS resolution, itself an anomaly on a network with enforced proxy egress.
• Session duration consistently short (sub-second to a few seconds) - check-in, not sustained data transfer.

Null Hypothesis: The traffic is a legitimate monitoring/heartbeat agent (e.g., RMM tool, backup agent, license-check service) that happens to use a non-standard port. Invalidate via asset inventory cross-check - confirm no approved software on the host is documented to use that destination/port pair, and confirm absence of a matching DNS lookup for a known vendor domain.

Rationale: Firewall logs are often the last line of visibility when an attacker uses raw sockets or a custom C2 protocol to evade proxy-based and DNS-based detections; this hunt validates whether flow-level regularity analysis on firewall data alone can surface beaconing without host or DNS telemetry.

Step 2: Data Sources and Scope

• Sources: Perimeter firewall (Palo Alto/Fortinet-style ALLOW/traffic logs); supplementary Proxy logs (to confirm absence of correlated entries); DNS logs (to confirm absence of resolution).
• Scope: ~2022-04-02T00:00:00-06:00:00 UTC; Host: WKS-FIN-0231 (10.20.14.87); External destination: 185.220.101.47:8443; Duration: 6-hour capture window.
• SIEM Queries (Splunk/ELK):
• Beacon candidates: index=firewall action=allow dest_port!=80 dest_port!=443 dest_port!=53 | stats count, avg(bytes_out) as avg_bytes, stdev(bytes_out) as std_bytes by src_ip, dest_ip, dest_port | where count > 100
• Interval regularity: index=firewall src_ip="10.20.14.87" dest_ip="185.220.101.47" | delta _time as gap | stats avg(gap), stdev(gap)
• Cross-check proxy: index=proxy dest_ip="185.220.101.47" (expect zero results if bypassing proxy)

Step 3: Key Findings

Parsed events (9 shown) confirm 347 outbound sessions from WKS-FIN-0231 to a single external IP over the 6-hour window, at a near-perfect 60-second interval.

Validation:

• Timeline: Beaconing is continuous and unbroken across the entire 6-hour capture, with one clear tasking spike - the statistical signature of an active, polled C2 channel.
• False Positives: Ruled out RMM/backup agents via asset inventory - no approved tool is documented for this host/port/destination combination; the proxy-bypass and missing-DNS findings further rule out any sanctioned SaaS integration.
• Correlation: Single host, single external IP, single port - a tight, isolated indicator set typical of a targeted implant rather than shared infrastructure or broad malware campaign.

Step 4: Recommendations & Next Steps

• Immediate Response: Isolate WKS-FIN-0231 from the network; capture memory/disk image before remediation; block 185.220.101.47 at the perimeter firewall and any upstream DNS sinkhole; pull EDR telemetry for the host to identify the implant process and initial infection vector.
• Detection: Sigma-style firewall rule: title: Regular-Interval Non-Standard-Port Beaconing → selection: dest_port NOT IN (80,443,53) | stats interval regularity over rolling 1h window | condition: stdev(interval) < 5% of mean AND count > 50 - feed into a beaconing-detection dashboard (e.g., RITA, Zeek-based).
• Pro Tip: Firewall-only beacon hunts are noisy at scale; narrow the search space first by filtering to hosts with zero corresponding proxy/DNS entries for their top non-standard-port destinations - legitimate egress almost always has a DNS trail, malicious direct-to-IP traffic often doesn't.

Hypothesis confirmed - regular-interval, proxy-bypassing beaconing to a single external IP on a non-standard port, consistent with active C2 check-in traffic!