Which SIEM platforms have a T1071 detection rule?

df00tech provides T1071 (Application Layer Protocol) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What severity and confidence is the T1071 detection?

The T1071 detection is rated medium severity with medium confidence.

What are common false positives for T1071?

Common false positives for T1071 include: Legitimate software performing periodic update checks (Windows Update, antivirus definitions, NTP); Monitoring and heartbeat agents that maintain persistent connections to cloud management platforms; Chat and collaboration applications (Slack, Teams, Zoom) with long-lived WebSocket or polling connections.

T1071

Application Layer Protocol

Q: What data sources are required to detect Application Layer Protocol (T1071)?

Detecting Application Layer Protocol requires the following data sources: Network Traffic: Network Connection Creation, Network Traffic: Network Traffic Flow, Microsoft Defender for Endpoint.

Command and Control Last updated: April 13, 2026

Adversaries may communicate using OSI application layer protocols to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server. Adversaries may utilize many different protocols, including those used for web browsing, transferring files, electronic mail, DNS, or publishing/subscribing. For connections that occur internally within an enclave (such as those between a proxy or pivot node and other nodes), commonly used protocols are SMB, SSH, or RDP.

What is T1071 Application Layer Protocol?

Application Layer Protocol (T1071) 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 Application Layer Protocol, 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 medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic: Command and Control
Technique: T1071 Application Layer Protocol
Canonical reference: https://attack.mitre.org/techniques/T1071/

Microsoft Sentinel / Defender

kusto

let TimeWindow = 24h;
let BeaconThreshold = 10;
let EntropyThreshold = 4.5;
// Detect anomalous outbound connections with beaconing patterns
DeviceNetworkEvents
| where Timestamp > ago(TimeWindow)
| where RemoteIPType == "Public"
| where ActionType == "ConnectionSuccess"
| where RemotePort in (80, 443, 53, 21, 25, 110, 143, 8080, 8443, 1883, 5222)
| summarize
    ConnectionCount = count(),
    UniqueRemoteIPs = dcount(RemoteIP),
    UniquePorts = dcount(RemotePort),
    Ports = make_set(RemotePort),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    AvgTimeBetween = datetime_diff('second', max(Timestamp), min(Timestamp)) / count()
    by DeviceName, InitiatingProcessFileName, InitiatingProcessId
| where ConnectionCount > BeaconThreshold
| where AvgTimeBetween between (1 .. 3600)
| extend BeaconScore = iff(AvgTimeBetween between (55 .. 65) or AvgTimeBetween between (295 .. 305) or AvgTimeBetween between (895 .. 905), "high", "medium")
| project Timestamp=LastSeen, DeviceName, InitiatingProcessFileName, ConnectionCount, UniqueRemoteIPs, Ports, AvgTimeBetween, BeaconScore, FirstSeen, LastSeen
| sort by ConnectionCount desc

Detects anomalous outbound network connections across common application layer protocol ports that exhibit beaconing behavior. Identifies processes making repeated connections at regular intervals to public IPs — a hallmark of C2 communication using application layer protocols (HTTP, DNS, FTP, SMTP, MQTT). Calculates average time between connections to detect periodic beaconing patterns typical of malware callbacks.

medium severity medium confidence

Data Sources

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

Required Tables

DeviceNetworkEvents

False Positives

Legitimate software performing periodic update checks (Windows Update, antivirus definitions, NTP)
Monitoring and heartbeat agents that maintain persistent connections to cloud management platforms
Chat and collaboration applications (Slack, Teams, Zoom) with long-lived WebSocket or polling connections
IoT devices communicating via MQTT to cloud brokers on regular intervals

Splunk

spl

index=proxy OR index=firewall OR index=network sourcetype IN ("stream:tcp", "pan:traffic", "cisco:asa", "squid")
  dest_port IN (80, 443, 53, 21, 25, 110, 143, 8080, 8443, 1883, 5222)
  action=allowed
  NOT (dest_ip="10.*" OR dest_ip="172.16.*" OR dest_ip="192.168.*" OR dest_ip="127.*")
| bin _time span=5m
| stats count as ConnectionCount, dc(dest_ip) as UniqueDestIPs, dc(dest_port) as UniquePorts, values(dest_port) as Ports, earliest(_time) as FirstSeen, latest(_time) as LastSeen by src_ip, process_name
| where ConnectionCount > 10
| eval Duration=LastSeen-FirstSeen
| eval AvgInterval=if(ConnectionCount>1, Duration/(ConnectionCount-1), 0)
| where AvgInterval > 1 AND AvgInterval < 3600
| eval BeaconScore=case(
    (AvgInterval >= 55 AND AvgInterval <= 65) OR (AvgInterval >= 295 AND AvgInterval <= 305), "high",
    1=1, "medium")
| table FirstSeen, LastSeen, src_ip, process_name, ConnectionCount, UniqueDestIPs, Ports, AvgInterval, BeaconScore
| sort - ConnectionCount

Detects potential C2 beaconing across application layer protocols by analyzing outbound connection patterns from proxy, firewall, or network stream logs. Groups connections into 5-minute windows and calculates the average interval between connections to identify periodic callback patterns. Common C2 frameworks like Cobalt Strike, Sliver, and Mythic beacon at regular intervals over HTTP, DNS, FTP, or pub/sub protocols.

medium severity medium confidence

Data Sources

Network Traffic: Network Connection Creation Network Traffic: Network Traffic Flow Proxy Logs Firewall Logs

Required Sourcetypes

stream:tcp pan:traffic cisco:asa squid

False Positives

Legitimate software performing periodic update checks (Windows Update, antivirus definitions, NTP)
Monitoring and heartbeat agents that maintain persistent connections to cloud management platforms
Chat and collaboration applications (Slack, Teams, Zoom) with long-lived WebSocket or polling connections
IoT devices communicating via MQTT to cloud brokers on regular intervals

IBM QRadar (AQL)

sql

SELECT sourceip,
       destinationip,
       destinationport,
       "userName",
       COUNT(*) AS ConnectionCount,
       MIN(starttime) AS FirstSeenEpochMs,
       MAX(starttime) AS LastSeenEpochMs,
       CASE
         WHEN COUNT(*) > 1
         THEN (MAX(LONG(starttime)) - MIN(LONG(starttime))) / (COUNT(*) - 1)
         ELSE 0
       END AS AvgIntervalMs
FROM events
WHERE starttime > (NOW() - 86400000)
  AND destinationport IN (80, 443, 53, 21, 25, 110, 143, 8080, 8443, 1883, 5222)
  AND eventdirection = 'L2R'
  AND NOT (destinationip ILIKE '10.%'
        OR destinationip ILIKE '172.16.%'
        OR destinationip ILIKE '172.17.%'
        OR destinationip ILIKE '172.18.%'
        OR destinationip ILIKE '172.19.%'
        OR destinationip ILIKE '172.20.%'
        OR destinationip ILIKE '172.21.%'
        OR destinationip ILIKE '172.22.%'
        OR destinationip ILIKE '172.23.%'
        OR destinationip ILIKE '172.24.%'
        OR destinationip ILIKE '172.25.%'
        OR destinationip ILIKE '172.26.%'
        OR destinationip ILIKE '172.27.%'
        OR destinationip ILIKE '172.28.%'
        OR destinationip ILIKE '172.29.%'
        OR destinationip ILIKE '172.30.%'
        OR destinationip ILIKE '172.31.%'
        OR destinationip ILIKE '192.168.%'
        OR destinationip ILIKE '127.%')
GROUP BY sourceip, destinationip, destinationport, "userName"
HAVING COUNT(*) > 10
   AND AvgIntervalMs BETWEEN 1000 AND 3600000
ORDER BY ConnectionCount DESC

Detects hosts making more than 10 outbound connections to the same external destination IP and port within 24 hours, with an average inter-connection interval between 1 second and 1 hour — consistent with automated C2 beaconing over application layer protocols. AvgIntervalMs is derived from QRadar's millisecond-resolution starttime field. eventdirection='L2R' limits scope to local-to-remote traffic only.

high severity medium confidence

Data Sources

QRadar Network Activity (firewall, proxy, IDS log sources) Palo Alto PAN-OS Cisco ASA Check Point

Required Tables

events

False Positives

CDN health-check probes and load balancer keep-alives from internal application servers to external monitoring endpoints generate repetitive outbound connections with sub-minute fixed intervals
VoIP and SIP clients making regular registration refresh messages to external SIP providers, often tunnelled over TCP 443 or 5060, may exhibit sub-60-second average intervals
IoT and OT devices with telemetry callbacks to cloud platforms (AWS IoT Core over MQTT 8883, generic MQTT 1883) at fixed polling cadences match the connection count and interval thresholds

Sumo Logic CSE

sql

(_sourceCategory=network* OR _sourceCategory=firewall* OR _sourceCategory=proxy*)
| where !(isNull(dst_port))
| where dst_port in ("80","443","53","21","25","110","143","8080","8443","1883","5222")
| where !(dst_ip matches "10.*" or dst_ip matches "172.16.*" or dst_ip matches "172.17.*" or dst_ip matches "172.18.*" or dst_ip matches "172.19.*" or dst_ip matches "172.2*" or dst_ip matches "172.30.*" or dst_ip matches "172.31.*" or dst_ip matches "192.168.*" or dst_ip matches "127.*")
| where isNull(action) or action in ("allowed","accept","permit","Allow")
| timeslice 24h
| count as ConnectionCount, count_distinct(dst_ip) as UniqueDestIPs, first(_messageTime) as FirstSeenMs, last(_messageTime) as LastSeenMs by src_ip, process_name, _timeslice
| where ConnectionCount > 10
| fields - _timeslice
| eval Duration = LastSeenMs - FirstSeenMs
| eval AvgIntervalMs = if(ConnectionCount > 1, Duration / (ConnectionCount - 1), 0)
| where AvgIntervalMs > 1000 and AvgIntervalMs < 3600000
| eval BeaconScore = if((AvgIntervalMs >= 55000 and AvgIntervalMs <= 65000) or (AvgIntervalMs >= 295000 and AvgIntervalMs <= 305000) or (AvgIntervalMs >= 895000 and AvgIntervalMs <= 905000), "high", "medium")
| sort by ConnectionCount

Identifies source IPs and processes making repeated outbound connections to external destinations on known application layer protocol ports. Groups network/firewall log data by source IP and process name over a 24-hour timeslice, computing average inter-connection interval in milliseconds. Beacon score is elevated for intervals clustering around 60s, 300s, or 900s — common C2 sleep timers. _messageTime is used for interval calculation as it is Sumo Logic's millisecond-precision ingest timestamp.

high severity medium confidence

Data Sources

Palo Alto PAN-OS (palo-alto-networks) Cisco ASA (cisco_asa) Zscaler NSS Squid Proxy Bluecoat ProxySG

Required Tables

_sourceCategory=network* _sourceCategory=firewall* _sourceCategory=proxy*

False Positives

Automated backup agents (Veeam, Acronis, Carbonite) making periodic outbound connections to cloud storage endpoints over port 443 at fixed backup window intervals will match connection count thresholds
Corporate endpoint management agents (SCCM, Tanium, Qualys Cloud Agent) regularly checking in to management infrastructure produce repetitive outbound connections with predictable intervals
SaaS desktop clients with background auto-sync (Dropbox, Box, OneDrive) polling for delta changes at sub-minute intervals accumulate connection counts well above the threshold of 10 per 24 hours

Google Chronicle / SecOps

yaral

rule t1071_application_layer_protocol_beaconing {
  meta:
    author = "Argus Detection Engineering"
    description = "Detects C2 beaconing over application layer protocols (T1071). Identifies processes making more than 10 outbound network connections to non-RFC1918 IPs on common protocol ports within a 1-hour match window."
    mitre_attack_tactic = "Command and Control"
    mitre_attack_technique = "T1071"
    reference = "https://attack.mitre.org/techniques/T1071/"
    severity = "HIGH"
    confidence = "MEDIUM"
    version = "1.0"

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.network.direction = "OUTBOUND"
    $e.target.port in (80, 443, 53, 21, 25, 110, 143, 8080, 8443, 1883, 5222)
    not re.regex($e.target.ip, `^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)`)
    $e.principal.process.file.full_path != ""
    $hostname = $e.principal.hostname
    $process_path = $e.principal.process.file.full_path

  match:
    $hostname, $process_path over 1h

  outcome:
    $connection_count = count($e.metadata.id)
    $unique_dest_ips = count_distinct($e.target.ip)
    $dest_ports = array_distinct($e.target.port)
    $first_seen = min($e.metadata.event_timestamp.seconds)
    $last_seen = max($e.metadata.event_timestamp.seconds)
    $risk_score = max(if($e.target.port = 1883 or $e.target.port = 5222, 85, 60))

  condition:
    #e > 10
}

YARA-L 2.0 rule for Google Chronicle UDM that detects processes on a host making more than 10 outbound network connections to non-RFC1918 IP addresses on application layer protocol ports within a 1-hour match window. Groups events by hostname and process file path. Risk score is elevated for MQTT (1883) and XMPP (5222) which are uncommon in standard enterprise egress. The #e > 10 condition counts distinct event matches against the $e variable within the match window.

high severity medium confidence

Data Sources

Chronicle UDM via Endpoint telemetry forwarders Palo Alto Cortex XDR ingested to Chronicle Windows Defender ATP events via Chronicle ingestion Firewall/proxy syslog normalised to UDM NETWORK_CONNECTION

Required Tables

NETWORK_CONNECTION UDM events

False Positives

Legitimate recursive DNS resolvers or DNS forwarder appliances on the network making high volumes of outbound port 53 connections will match if not excluded by principal.hostname or IP allowlist
Email security gateways making repeated outbound connections on SMTP (25), IMAP (143), or POP3 (110) to external mail exchange servers for relay and delivery
Industrial IoT sensors using MQTT (1883) or XMPP (5222) for cloud telemetry publishing at fixed intervals — these are expected in OT network segments and should be excluded by network zone

CrowdStrike LogScale (CQL)

cql

#event_simpleName=NetworkConnectIP4
| RemotePort in [80, 443, 53, 21, 25, 110, 143, 8080, 8443, 1883, 5222]
| !cidr(field=RemoteAddressIP4, subnet=["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "169.254.0.0/16"])
| groupBy([ComputerName, ImageFileName, ContextProcessId], function=[
    count(as=ConnectionCount),
    min(field=@timestamp, as=FirstSeen),
    max(field=@timestamp, as=LastSeen),
    collect(field=RemotePort, as=Ports, limit=20),
    count(field=RemoteAddressIP4, distinct=true, as=UniqueRemoteIPs)
  ])
| ConnectionCount > 10
| eval Duration := LastSeen - FirstSeen
| eval AvgIntervalMs := if(ConnectionCount > 1, Duration / (ConnectionCount - 1), 0)
| AvgIntervalMs > 1000 AND AvgIntervalMs < 3600000
| eval BeaconScore := if(
    (AvgIntervalMs >= 55000 AND AvgIntervalMs <= 65000) OR
    (AvgIntervalMs >= 295000 AND AvgIntervalMs <= 305000) OR
    (AvgIntervalMs >= 895000 AND AvgIntervalMs <= 905000),
    "high",
    "medium")
| sort(field=ConnectionCount, order=desc)

Detects C2 beaconing over application layer protocols using CrowdStrike Falcon sensor NetworkConnectIP4 telemetry in LogScale. Groups outbound connections to external IPs by host, executable image path, and process ID. Computes average inter-connection interval from LogScale's millisecond-precision @timestamp field. Flags processes with more than 10 external connections on common protocol ports with intervals between 1 second and 1 hour. Beacon score is HIGH for intervals matching 60s, 300s, or 900s C2 sleep patterns common in Cobalt Strike, Metasploit, and commodity RATs.

high severity medium confidence

Data Sources

CrowdStrike Falcon Sensor (NetworkConnectIP4 events) Falcon LogScale (Humio) SIEM ingestion

Required Tables

NetworkConnectIP4 (Falcon platform event stream)

False Positives

The CrowdStrike Falcon sensor process itself (CSFalconService, falcond) and other EDR agents make regular check-ins to cloud infrastructure — whitelist known EDR process image paths in ImageFileName
Software configuration management tools (Puppet agent, Chef client, Ansible pull mode) that poll controller nodes at configured run intervals over 443 or 8443 match both the connection count and scored interval thresholds
Unified communications clients (Microsoft Teams, Zoom, Cisco Webex) maintaining persistent WebSocket or HTTPS keep-alive connections to CDN endpoints at near-regular heartbeat intervals, particularly on port 443 or 8443

Sigma rule & cross-platform mapping

The detection logic for Application Layer Protocol (T1071) 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 T1071 Sigma rules on detection.fyi

Platform-specific guides for T1071

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 (4)

Testing Methodology

Validate this detection against 3 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.

Test 1Multi-Protocol Beaconing Simulation
Expected signal: Sysmon for Linux Event ID 3 (Network Connection) showing curl processes connecting to 127.0.0.1 on ports 80, 443, 53. Firewall logs showing outbound connection attempts.
Test 2IRC C2 Channel Simulation
Expected signal: Sysmon Event ID 3: Network Connection to port 6667 (IRC). Process creation event for nc/netcat with IRC protocol commands in arguments.
Test 3HTTP Beaconing with Cobalt Strike User-Agent
Expected signal: Sysmon Event ID 3: Network Connection from powershell.exe to 127.0.0.1:80. Proxy logs showing repeated requests to /pixel.gif with suspicious User-Agent. Sysmon Event ID 1: PowerShell process creation for each iteration.

Response Playbook

Triage

Identify the process initiating the connections — is it a known system binary, legitimate application, or suspicious/unknown executable?
Examine the connection pattern — are connections regular (fixed intervals) or jittered? C2 frameworks often add jitter to avoid detection
Check the remote IP reputation using threat intelligence feeds (VirusTotal, AbuseIPDB, OTX) and geolocation data
Review the protocol and port combination — is the traffic on expected ports for that protocol? Look for protocol misuse (e.g., HTTP tunneling over port 53)
Check if the process has a valid digital signature and whether its parent process chain is legitimate
Correlate with DNS logs to identify the domain associated with the remote IP

Containment

If confirmed C2: immediately isolate the endpoint using EDR network isolation or VLAN quarantine
Block the identified C2 IP addresses and domains at the firewall and DNS level
If lateral movement is suspected: isolate all potentially compromised hosts and reset affected credentials
Disable any compromised service accounts and revoke OAuth/API tokens
Create temporary firewall rules to block the specific port/protocol combination used by the C2 channel

Evidence Collection

Full PCAP of the suspicious network connections for protocol-level analysis
Process memory dump of the initiating process for malware analysis
Sysmon Event ID 3 (Network Connection) logs with full process context
DNS query logs correlated with connection timestamps
Proxy/firewall logs showing full URL paths and HTTP headers if applicable
Endpoint process tree showing parent-child relationships of the suspicious process

Escalation Criteria

! Beaconing pattern matches known C2 framework signatures (e.g., 60s Cobalt Strike default sleep)
! Multiple endpoints beaconing to the same external IP or domain
! Process associated with the connections is unsigned, recently dropped, or has been tampered with
! Evidence of data exfiltration (large outbound data volumes during beacon windows)
! The connection uses non-standard protocol/port combinations (e.g., DNS traffic not to port 53, or HTTP to high ports)

Investigation Guide

Forensic Artifacts

> Network flow records (NetFlow/IPFIX) showing connection metadata
> Sysmon Event ID 3 — Network connection events with process context
> Windows Security Event ID 5156 — Windows Filtering Platform (WFP) permitted connections
> Proxy logs with full URL, User-Agent, and response codes
> DNS query logs showing domain resolution preceding network connections
> Firewall logs with action, bytes transferred, and session duration

Tuning Guidance

Start by baselining legitimate application layer protocol usage across your environment. Identify known update services, monitoring agents, and IoT devices that communicate on regular intervals. Create allowlists based on (source process + destination IP/domain + port) tuples rather than broad port exclusions. Adjust the beacon interval thresholds based on your environment's noise floor — environments with many IoT devices may need higher thresholds. Consider deploying JA3/JA3S fingerprinting for TLS connections to identify known C2 framework handshakes even when traffic is encrypted.

Hunting Queries

Hunt for processes making high volumes of outbound connections across multiple ports and IPs. Multi-protocol C2 frameworks often use fallback channels, switching between HTTP, DNS, and other protocols when one is blocked.

Hunting — KQL

kql

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where ActionType == "ConnectionSuccess"
| summarize ConnectionCount=count(), UniqueIPs=dcount(RemoteIP), Ports=make_set(RemotePort) by DeviceName, InitiatingProcessFileName
| where ConnectionCount > 50
| where array_length(Ports) > 2
| sort by ConnectionCount desc

Hunting — SPL

spl

index=proxy OR index=firewall sourcetype IN ("stream:tcp", "pan:traffic") action=allowed NOT (dest_ip="10.*" OR dest_ip="172.16.*" OR dest_ip="192.168.*")
| stats count as ConnectionCount, dc(dest_ip) as UniqueIPs, values(dest_port) as Ports by src_ip, process_name
| where ConnectionCount > 50 AND mvcount(Ports) > 2
| sort - ConnectionCount

Hunt for connections to uncommon application layer protocol ports (MQTT 1883, XMPP 5222, AMQP 5672, STOMP 61613). These pub/sub and messaging protocols are increasingly abused for C2 due to low detection coverage in most environments.

Hunting — KQL

kql

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where RemotePort in (1883, 5222, 5672, 61613)
| summarize ConnectionCount=count(), UniqueIPs=dcount(RemoteIP) by DeviceName, InitiatingProcessFileName, RemotePort
| sort by ConnectionCount desc

Hunting — SPL

spl

index=network sourcetype IN ("stream:tcp", "pan:traffic") dest_port IN (1883, 5222, 5672, 61613) action=allowed NOT (dest_ip="10.*" OR dest_ip="172.16.*" OR dest_ip="192.168.*")
| stats count as ConnectionCount, dc(dest_ip) as UniqueIPs by src_ip, process_name, dest_port
| sort - ConnectionCount

Hunt for extremely consistent connection patterns — processes making a nearly identical number of connections per hour over multiple days. A very low standard deviation in hourly connection counts indicates automated, programmatic communication typical of C2 rather than human-driven activity.

Hunting — KQL

kql

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| where ActionType == "ConnectionSuccess"
| summarize Connections=count() by DeviceName, InitiatingProcessFileName, bin(Timestamp, 1h)
| summarize HourlyAvg=avg(Connections), HourlyStdDev=stdev(Connections), TotalHours=count() by DeviceName, InitiatingProcessFileName
| where HourlyStdDev < 2 and TotalHours > 24
| sort by TotalHours desc

Hunting — SPL

spl

index=proxy OR index=firewall sourcetype IN ("stream:tcp", "pan:traffic") action=allowed NOT (dest_ip="10.*" OR dest_ip="172.16.*" OR dest_ip="192.168.*")
| bin _time span=1h
| stats count as Connections by src_ip, process_name, _time
| stats avg(Connections) as HourlyAvg, stdev(Connections) as HourlyStdDev, count as TotalHours by src_ip, process_name
| where HourlyStdDev < 2 AND TotalHours > 24
| sort - TotalHours

Atomic Red Team Tests

Test 1 Multi-Protocol Beaconing Simulation

linux

Simulates C2 beaconing across multiple application layer protocols by making periodic outbound connections to localhost on common C2 ports (HTTP 80, HTTPS 443, DNS 53). This mimics the multi-protocol fallback behavior of advanced C2 frameworks like Cobalt Strike and Sliver.

Command

bash

for port in 80 443 53; do for i in $(seq 1 5); do curl -s -o /dev/null --connect-timeout 2 http://127.0.0.1:$port/ 2>/dev/null; sleep 2; done; done

Expected Telemetry

Sysmon for Linux Event ID 3 (Network Connection) showing curl processes connecting to 127.0.0.1 on ports 80, 443, 53. Firewall logs showing outbound connection attempts.

Expected Detection

Alert fires on repeated connections at regular intervals across multiple ports from the same source process. BeaconScore should trigger based on consistent 2-second intervals.

Test 2 IRC C2 Channel Simulation

linux

Simulates malware connecting to an IRC server for C2 communications, as used by Hildegard, Magic Hound, Siloscape, and TeamTNT. Uses netcat to attempt a connection to a non-existent IRC server on the standard port.

Command

bash

echo -e 'NICK testbot\nUSER testbot 0 * :test\nJOIN #c2channel\nPRIVMSG #c2channel :beacon' | nc -w 3 127.0.0.1 6667 2>/dev/null || true

Expected Telemetry

Sysmon Event ID 3: Network Connection to port 6667 (IRC). Process creation event for nc/netcat with IRC protocol commands in arguments.

Expected Detection

Network monitoring should flag outbound IRC connections (port 6667/6697) as anomalous. Alert fires on connection to known IRC port from a non-IRC client process.

Test 3 HTTP Beaconing with Cobalt Strike User-Agent

windows

Simulates HTTP-based C2 beaconing using a User-Agent string commonly associated with Cobalt Strike default malleable profiles. Makes 10 periodic HTTP GET requests at 5-second intervals to localhost.

Command

powershell

for /L %i in (1,1,10) do (
  powershell -Command "Invoke-WebRequest -Uri 'http://127.0.0.1/pixel.gif' -UserAgent 'Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; MALC)' -ErrorAction SilentlyContinue" 2>nul
  timeout /t 5 /nobreak >nul
)

Expected Telemetry

Sysmon Event ID 3: Network Connection from powershell.exe to 127.0.0.1:80. Proxy logs showing repeated requests to /pixel.gif with suspicious User-Agent. Sysmon Event ID 1: PowerShell process creation for each iteration.

Expected Detection

Alert fires on regular-interval HTTP connections from PowerShell. Proxy-based detections should flag the anomalous User-Agent string. BeaconScore=high due to consistent 5-second interval.

What is T1071 Application Layer Protocol?

MITRE ATT&CK

Data Sources

Required Tables

False Positives

Data Sources

Required Sourcetypes

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Sigma rule & cross-platform mapping

Platform-specific guides for T1071

Testing Methodology

Response Playbook

Triage

Containment

Evidence Collection

Escalation Criteria

Investigation Guide

Forensic Artifacts

Tuning Guidance

Hunting Queries

Atomic Red Team Tests

Command

Expected Telemetry

Expected Detection

Command

Expected Telemetry

Expected Detection

Command

Expected Telemetry

Expected Detection

Related Detections

Tactic Hub

Sub-techniques (5)

Related Techniques

Same Tactic: Command and Control

Popular Detections

Get new detections in your inbox