Detecting application layer protocol (T1071) C2 with SIEM

What is application layer protocol (T1071)?

Application Layer Protocol (T1071) describes how adversaries use standard application protocols - HTTP, HTTPS, DNS, SMTP, and others - as the transport layer for C2 communications. Because these protocols are essential for normal business operations, firewalls allow them by default. Attackers exploit this by embedding C2 commands and data within protocol-compliant traffic.

This technique has four sub-techniques:

HTTP/HTTPS C2 detection (T1071.001)

How HTTP/HTTPS C2 works

HTTP-based C2 frameworks like Cobalt Strike use GET and POST requests to communicate with a team server. The implant periodically "checks in" via HTTP GET (receiving tasking) and sends results via HTTP POST. Malleable C2 profiles customize the traffic to mimic legitimate web applications - jQuery CDN calls, Google API requests, or CMS traffic.

Detection signals in proxy logs

• Beaconing regularity - HTTP requests to the same URI at regular intervals (even with jitter, mathematical periodicity is detectable)
• Unusual User-Agent strings - Default C2 agents use static or suspicious User-Agents; mismatches between UA and actual browser fingerprint
• Low content-to-connection ratio - Many requests returning small response bodies or 0-byte GET responses (sleep check-ins)
• Cookie or header-encoded data - C2 data embedded in Cookie headers, custom HTTP headers, or URI parameters with base64-like encoding
• POST without prior browsing - Large POST requests to a domain with no preceding page loads or resource requests
• Uncategorized domains - Connections to domains not categorized by URL filtering services

DNS C2 detection (T1071.004)

How DNS tunneling works

DNS tunneling encodes C2 data in DNS queries. The implant sends data as subdomain labels (e.g., aGVsbG8gd29ybGQ.tunnel.attacker.com) and receives responses in TXT, CNAME, or A records. This works even in air-gapped environments that only allow DNS resolution.

Detection signals in DNS logs

• Long subdomain labels - Normal subdomains are under 20 characters; tunneling produces 40-63 character labels with high entropy
• High query volume to single domain - Hundreds or thousands of unique subdomain queries to one parent domain per hour
• TXT record query spikes - Normal environments generate few TXT queries; tunneling produces excessive TXT lookups
• Non-existent domain responses (NXDOMAIN) - High rates of NXDOMAIN responses from a single source (malformed tunneling attempts)
• Unusual query types - NULL, CNAME, or MX record queries used as data channels
• Direct queries bypassing internal DNS - Endpoints querying external DNS servers directly (8.8.8.8, 1.1.1.1) instead of internal resolvers

Log360's 22 prebuilt T1071 detection rules

Real-world examples

Cobalt Strike HTTP beaconing

Cobalt Strike's default HTTP beacon checks in every 60 seconds with a GET request to a URI like /visit.js or /pixel.gif. The team server responds with tasking encoded in the response body. Results are sent via POST. Default malleable profiles mimic jQuery CDN traffic or Microsoft update patterns.

DNS tunneling with dnscat2

dnscat2 encodes data in CNAME and TXT queries. A compromised host generates hundreds of queries per minute to the attacker's authoritative DNS domain:

Investigation and response

• Identify the process - Correlate the source IP/host with endpoint logs to find which process is generating the suspicious HTTP/DNS traffic. C2 implants often inject into legitimate processes (svchost.exe, browser processes).
• Analyze the full session - Pull complete proxy logs for the identified destination. Look for the full beacon pattern: initial connection, periodic check-ins, command execution bursts.
• Check for lateral movement - Once C2 is confirmed, search for the same destination IP/domain from other hosts. Check for credential access or lateral movement originating from the compromised host.
• Block at multiple layers - Block the C2 domain/IP at DNS, proxy, and firewall simultaneously. Attackers often have fallback C2 channels, so blocking one layer alone may be insufficient.
• Hunt for additional C2 - Use the confirmed C2 indicators (JA3 hash, URI patterns, User-Agent) to search historical logs for earlier connections or other compromised hosts.

Remediation and prevention

• Enforce proxy for all HTTP/HTTPS - Route all web traffic through an inspecting proxy. Block direct internet access from endpoints to prevent C2 that bypasses proxy-based detection.
• Restrict DNS to internal resolvers - Block direct DNS queries to external resolvers (8.8.8.8, 1.1.1.1). Force all DNS through internal servers where query logging and analysis is performed.
• Deploy DNS response policy zones (RPZ) - Block queries to known C2 domains and newly registered domains at the DNS layer.
• URL categorization enforcement - Block or alert on traffic to uncategorized domains. Most legitimate business traffic goes to well-categorized sites.
• Application whitelisting for outbound protocols - Restrict which applications can make outbound HTTP, DNS, and SMTP connections. This limits C2 to only processes with legitimate network access.

Need to explore ManageEngine Log360? Schedule a personalized demo

FAQ