Blocked Connections to Malicious Domains Are Symptoms, Not Resolutions

CISA published advisory AA26-237A on August 25, 2026, titled "A Tale of Two SOCs" [1][9]. The agency ran two simultaneous red team assessments against critical infrastructure organizations using similar tradecraft. The results clearly demonstrated how alert disposition determines whether an intrusion stays contained or becomes a full domain compromise.

Organization A, a Government Services and Facilities entity, failed to effectively detect and respond to the intrusion. Despite having multiple SOCs and EDR platforms, inadequate cross-team communication and poor alert triage allowed the red team to gain initial access, escalate privileges, move laterally to sensitive business systems and cloud resources, and exfiltrate data across the entire kill chain without triggering a meaningful defensive response [9]. Organization B, a Water and Wastewater Systems entity, detected each phishing payload as it executed. Its SOC isolated the three affected workstations within 2, 10, and 20 minutes respectively, cutting off C2 communications before the intrusion could expand [1][9]. Same tradecraft. Opposite outcomes. The difference was what happened after the alert fired.

The 'Blocked, No Action Needed' Problem

Every enterprise SOC runs a version of the same workflow hundreds of times per shift. A DNS security tool blocks a query to a known malicious domain. The alert fires. An analyst sees "blocked" in the disposition field and closes the ticket. According to industry estimates, SOC analysts may face hundreds of alerts per shift, with a significant proportion being false positives [14]. Under that kind of volume pressure, closing a blocked alert feels rational. It isn't.

A blocked DNS query confirms one thing: something on that endpoint attempted to reach a known-bad destination. The block worked. The question the analyst skipped is: what initiated that query, and is it still running?

Organization B's SOC in the CISA assessment answered that question. Each phishing payload execution generated a medium-severity alert: "An executable file loaded an unexpected DLL file" [1]. Staff triaged and manually isolated the affected workstations. Before one workstation was isolated, the red team had already enumerated Organization B's Active Directory structure via LDAP queries through the active C2 callback [1]. A brief, unblocked C2 window was enough for the adversary to map the domain. The SOC's speed prevented escalation. Organization A's team never even started the clock.

Why a Single Blocked Query Means Almost Nothing

Modern malware is specifically engineered to survive DNS-layer blocking. Three techniques make a single block operationally meaningless as a resolution.

Multi-Domain C2 Fallback

LummaC2 (also known as Lumma Stealer) is an infostealer that decrypts its C2 domains at runtime and attempts POST requests to each until one succeeds [3]. If primary C2 servers are unreachable, LummaC2 can fall back to using public services to retrieve alternative C2 infrastructure [3]. Block one domain, and LummaC2 moves to the next. The FBI and CISA issued a joint advisory on LummaC2 in May 2025, noting significant volumes of log listings on criminal marketplaces [3].

DNS-over-HTTPS Bypass

BRICKSTORM, a backdoor attributed to the PRC-linked UNC5221 threat cluster, uses DNS-over-HTTPS (DoH) to resolve C2 infrastructure [2][10][11]. This design choice is deliberate: DoH encapsulates DNS queries inside encrypted HTTPS traffic, bypassing traditional DNS inspection tools entirely [10][11]. Your protective DNS resolver never sees the query because the malware doesn't use it. BRICKSTORM layers additional encryption on top: HTTPS, WebSockets, and nested TLS, all designed to mimic legitimate web server traffic [2][10]. CISA, NSA, and the Canadian Centre for Cyber Security published analysis of BRICKSTORM samples, originally released December 4, 2025, with subsequent updates [2][19]. BRICKSTORM infections have been associated with extended dwell times, with some cases lasting months before detection [11]. At one victim organization, PRC actors gained persistent access in April 2024 and uploaded BRICKSTORM to an internal VMware vCenter server, remaining undetected for an extended period before CISA's incident response engagement [2].

Fast Flux DNS

CISA, the FBI, the NSA, and cybersecurity agencies from Australia, Canada, and New Zealand issued a joint advisory warning that "many networks have a gap in their defenses for detecting and blocking" fast flux [4][12]. Fast flux rapidly rotates the IP addresses associated with a malicious domain. In single flux, the domain's A records change frequently. In double flux, both the IP addresses and the authoritative name servers rotate [4][12]. Gamaredon, Hive ransomware, Nefilim ransomware, CryptoChameleon, and Raspberry Robin have all been observed using fast flux [4][12]. Gamaredon registers large numbers of .ru TLD domains through REGRU-RU, with associated IPs changing after approximately one day of use [4]. Blocking the IP you observed yesterday does nothing when the domain resolves to a different IP today.

DNS as a Universal Egress Path

Malware frequently leverages DNS for C2 communications; industry research suggests DNS is involved in the vast majority of malware callbacks, not because DNS is particularly well-suited to covert communication, but because it is universally allowed [7]. Network firewalls that block direct outbound connections on non-standard ports still allow port 53 outbound to any destination, because blocking it breaks internet resolution for end users [7]. Microsoft has noted that the vast majority of cyberattacks involve DNS queries at some stage [16].

This makes DNS both the strongest intervention point and the most exploited one. Adversaries abuse DNS not just for initial domain resolution but for tunneling entire C2 channels. MITRE ATT&CK technique T1071.004 describes adversaries embedding commands and exfiltrated data within DNS protocol traffic, often in TXT or A records [5]. DNS beacons can be infrequent enough to blend with normal traffic [5]. The Heyoka Backdoor uses spoofed DNS requests to create C2 tunnels [6]. Protocol tunneling (T1572) wraps C2 traffic inside protocols like HTTP, HTTPS, or DNS that firewalls and proxies typically allow through without inspection [6].

An enterprise that controls and monitors DNS has visibility into all of these communications at a single choke point [7]. An enterprise that only blocks without monitoring has a false sense of security.

What the Block Should Trigger

A blocked DNS query to a known-malicious domain should initiate a triage workflow, not close a ticket. The WUST SOC Lab's first-response checklist for C2, DGA traffic, and DNS tunneling threat types directs analysts to check DNS logs for high-frequency queries, long or random domain names, rare TLDs, beaconing behavior, and failed resolution patterns [13].

Three questions determine the severity of a blocked connection:

1. What process initiated the query? A browser during an active user session suggests a malvertising near-miss. A background process, scheduled task, or service running outside user hours suggests malware. EDR telemetry and process trees answer this question.

2. What category of threat is the domain associated with? Malvertising and adware domains warrant a different response than known C2 infrastructure. Threat intelligence enrichment at triage time is essential.

3. Is the endpoint retrying? Regular, periodic retries to a blocked domain are a strong behavioral indicator of active malware. A device hitting the same blocked domain every 60 seconds has an active infection that your DNS layer is containing. In one reported case, an analyst conducting weekly DNS threat hunting discovered a compromised server that had reportedly been beaconing to C2 for 47 days: EDR hadn't flagged it (fileless malware), the firewall hadn't blocked it (HTTPS C2 on port 443), but the DNS pattern made the compromise obvious: same domain, every 5 minutes, around the clock [8].

The Structural Problem Behind Premature Closure

The root cause isn't analyst laziness. It's math. SOC teams face high volumes of alerts per shift with significant false positive rates [14]. Industry reporting suggests attackers are increasingly leveraging AI-assisted tools for reconnaissance and credential attacks [14]. A human-only Tier 1 team, no matter how experienced, can't maintain investigative rigor across that volume. The CISA red team assessment proves the consequences: Organization A had security tools. It had alerts. It had staff. None of that mattered because the disposition decisions were wrong.

Blocking direct outbound connections on ports 80 and 443 alone "breaks the majority of default C2 implant configurations" [15]. But that only works for unsophisticated implants. A compromised host with no C2 is a dormant implant. A compromised host with active C2 is "a fully operational weapon" [15]. The analyst's job at the blocked-connection alert is to determine which one they're looking at.

MITRE ATT&CK Relevance

DNS Log Analysis

The highest-value hunt starts in DNS logs. Look for:

• Beaconing patterns: Consistent intervals (every 30, 60, or 300 seconds) of queries to the same domain, especially outside business hours.
• High entropy subdomain labels: DNS tunneling encodes data in subdomain strings, producing long, random-looking query names [5][7].
• Rare TLDs and newly registered domains: Fast flux actors favor specific registrars and TLDs. Gamaredon's use of .ru domains via REGRU-RU is one documented pattern [4].
• Failed resolution spikes: DGA malware generates thousands of domains, most of which don't resolve. A host producing hundreds of NXDOMAIN responses in a short window is a strong DGA indicator [8][13].

Sigma Rule: Repeated Blocked DNS Queries from Single Host

title: Repeated Blocked DNS Queries to Same Malicious Domain
id: c8e3f2a1-4b7d-4e9a-b3c1-6d8f9e2a4b7c
status: experimental
author: RedSheepSec
date: 2026/08/26
description: Detects a single host generating multiple blocked DNS queries to the same domain within a short window, indicating possible malware C2 retry behavior
logsource:
    category: dns
    product: any
detection:
    selection:
        response_code: 'NXDOMAIN'
    filter_blocked:
        action: 'blocked'
    condition: selection or filter_blocked | count(query) by src_ip > 10
    timeframe: 15m
falsepositives:
    - Legitimate software with aggressive DNS retry logic
    - Misconfigured applications querying deprecated domains
level: high
tags:
    - attack.command_and_control
    - attack.t1071.004
    - attack.t1568.002

DoH Detection

BRICKSTORM's use of DoH means its DNS queries never touch your corporate resolver [2][10][11]. Monitor for:

• Outbound HTTPS connections to known public DoH providers (dns.google, cloudflare-dns.com, dns.quad9.net) from endpoints that should use the corporate resolver.
• TLS SNI values matching DoH providers in proxy or firewall logs.
• Unexpected outbound connections on port 443 from server infrastructure (vCenter, ESXi) to external IPs not in your approved baseline. Cross-reference any suspicious destination IPs against the BRICKSTORM IOCs listed in the CISA MAR [2][19].

Process-Level Correlation

When a blocked DNS alert fires, pull the process tree from EDR. Organization B's SOC caught the CISA red team because each payload execution generated an alert: "An executable file loaded an unexpected DLL file" [1]. Correlating DNS blocks with process execution telemetry turns a low-value alert into actionable intelligence.

Analysis

The CISA red team assessment published on August 25, 2026, is the clearest empirical demonstration to date that alert disposition quality determines breach outcomes [1][9]. The red team demonstrated the capability to fully compromise both organizations at the domain level, but Organization B's SOC contained the damage by treating alerts as starting points for investigation rather than as resolved events [9].

The enabling weaknesses at Organization A tell a familiar story: default Machine Account Quota, misconfigured AD CS certificate templates (ESC1), cleartext credentials on reachable systems, static AWS access keys that never expire, and over-permissioned Entra ID applications [9]. None of these weaknesses would have been exploitable without sustained, undetected C2 access. The red team needed that communication channel to operate. Had Organization A's SOC treated a single blocked or detected connection the way Organization B's team did, the entire attack chain would likely have stalled.

Malware authors have internalized this reality. LummaC2's multi-domain fallback logic, BRICKSTORM's DoH bypass, and fast flux rotation all target the same defensive assumption: that a blocked DNS query equals a neutralized threat. The malware doesn't share that assumption.

References

1. CISA Advisory AA26-237A: A Tale of Two SOCs
2. CISA Malware Analysis Report: BRICKSTORM Backdoor (AR25-338A)
3. CISA/FBI Advisory AA25-141B: LummaC2 Malware
4. CISA Advisory AA25-093A: Fast Flux: A National Security Threat
5. MITRE ATT&CK T1071.004: Application Layer Protocol: DNS
6. MITRE ATT&CK T1572: Protocol Tunneling
7. Enterprise DNS Security Guide: Filtering, Monitoring, and Hardening
8. Why DNS Traffic Is Still an Underrated Detection Source
9. The Hacker News: CISA Red Team Compromised Two Critical Infrastructure Orgs
10. Industrial Cyber: CISA Updates BRICKSTORM Malware Report
11. Picus Security: BRICKSTORM Malware and UNC5221
12. BleepingComputer: CISA Warns of Fast Flux DNS Evasion
13. WUST SOC Lab: Must-Know Logs for SOC Analysts
14. UnderDefense: AI SOC Analyst Complete Guide
15. StartupDefense: Command and Control TA0011
16. Microsoft Tech Community: Azure DNS Security Policy GA
17. UptimeRobot: DNS Security Best Practices
18. TrustMyIP: Best DNS Security Solutions
19. CISA/NSA/Cyber Centre: BRICKSTORM Malware Analysis Report PDF

Event Timeline

Entity Relationships

Diamond Model

Hunt Guide: DNS Block Evasion — C2 Persistence via Multi-Domain Fallback, DoH Bypass, and Fast Flux

Attribution: Rules adapted, ported, or quoted from a public source retain that source's author (e.g. SigmaHQ / Florian Roth, Elastic, Emerging Threats, Abuse.ch, or the cited vendor/researcher) and carry an attribution credit. Rules without a credit were authored in-house by RedSheepSec. If you reuse a rule, preserve its stated attribution.

Hypothesis: If adversaries employing BRICKSTORM DoH bypass, LummaC2 multi-domain fallback, or fast flux DNS techniques are active in our environment, we expect to observe repeated blocked DNS queries with retry patterns from single hosts, outbound HTTPS connections to known DoH providers from non-browser processes, high-entropy subdomain queries indicative of DNS tunneling, NXDOMAIN response spikes from DGA activity, and domains resolving to rapidly rotating IP addresses — detectable in DNS logs (index=dns, index=corelight), firewall/proxy logs (index=firewall-pan), EDR telemetry (index=crowdstrike, index=sysmon), and PowerShell/process execution logs.

Intelligence Summary: CISA advisory AA26-237A ('A Tale of Two SOCs') demonstrated that alert disposition quality — not tool coverage — determines whether an intrusion is contained or escalates to full domain compromise. Modern malware families including BRICKSTORM (PRC-linked UNC5221), LummaC2, and fast flux operators (Gamaredon, Hive, Raspberry Robin) are specifically engineered to survive DNS-layer blocking through DoH bypass, multi-domain C2 fallback, and rapid IP rotation. The report assesses with high confidence that the 'blocked, no action needed' disposition has likely become a systemic vulnerability that adversaries exploit by design, building fallback mechanisms specifically because they expect DNS blocking.

Confidence: High | Priority: High

Scope

• Networks: All enterprise network segments including user workstations, server infrastructure (especially VMware vCenter/ESXi), domain controllers, and DMZ/perimeter segments. Prioritize segments with outbound internet access and segments hosting critical infrastructure services.
• Timeframe: 30-day retrospective hunt covering the most recent 30 days of DNS, firewall, and EDR telemetry. The source report documents adversary dwell times of months (BRICKSTORM) and 47+ days (fileless C2 beaconing case), making extended lookback essential. Additionally, audit DNS alert closure workflows for the last 30 days to identify prematurely closed 'blocked' alerts.
• Priority Systems: VMware vCenter and ESXi servers (BRICKSTORM targeting), Active Directory domain controllers (LDAP enumeration target), user workstations with email access (phishing initial access vector), DNS resolvers and recursive servers, any systems previously generating blocked DNS alerts that were closed without investigation.

MITRE ATT&CK Techniques

T1071.004 — Application Layer Protocol: DNS (Command and Control) [P2]

Adversaries embed C2 commands and exfiltrated data within DNS protocol traffic, often using TXT or A records. DNS tunneling tools encode data in subdomain strings, producing long, high-entropy query names. The Heyoka Backdoor uses spoofed DNS requests to create C2 tunnels. DNS beacons can be infrequent enough to blend with normal traffic.

Splunk SPL:

index=corelight sourcetype=corelight_dns
| eval subdomain_length=len(mvindex(split(query, "."), 0))
| where subdomain_length > 40
| stats count AS query_count dc(query) AS unique_queries values(query) AS sample_queries BY id.orig_h
| where query_count > 20 AND unique_queries > 15
| sort - query_count
| table id.orig_h query_count unique_queries sample_queries
| rename id.orig_h AS src_ip

Elastic KQL:

event.dataset:"corelight.dns" AND dns.question.name:/.{50,}/ AND NOT dns.question.name:(*.microsoft.com OR *.windows.com OR *.windowsupdate.com OR *.azure.com)

Sigma Rule:

title: DNS Tunneling - High Entropy Subdomain Queries
id: d4a7e1b3-5c9f-4a2e-8b6d-3f1c7e9a5d2b
status: experimental
author: RedSheepSec
date: 2026/08/27
description: Detects hosts generating DNS queries with unusually long subdomain labels, indicative of DNS tunneling for C2 or data exfiltration per MITRE ATT&CK T1071.004
logsource:
    category: dns
    product: any
detection:
    selection:
        query|re: '^[a-zA-Z0-9]{40,}\..+'
    filter_legit:
        query|endswith:
            - '.microsoft.com'
            - '.windows.com'
            - '.windowsupdate.com'
            - '.azure.com'
            - '.amazonaws.com'
    condition: selection and not filter_legit
falsepositives:
    - CDN providers with long hashed subdomain labels
    - Anti-virus cloud lookups
    - DKIM/SPF validation queries
level: high
tags:
    - attack.command_and_control
    - attack.t1071.004

Tune the subdomain length threshold based on your environment baseline. CDN providers (Akamai, Cloudflare) may generate long subdomains legitimately. Whitelist known CDN and AV cloud-lookup domains. Focus on hosts generating many unique long-subdomain queries to the same base domain.

T1572 — Protocol Tunneling (Command and Control) [P2]

BRICKSTORM layers HTTPS, WebSockets, and nested TLS to tunnel C2 traffic inside protocols that firewalls typically allow. It uses DNS-over-HTTPS (DoH) to resolve C2 infrastructure, bypassing traditional DNS inspection entirely. The Heyoka Backdoor also uses spoofed DNS requests for C2 tunneling. This technique wraps C2 traffic inside HTTP, HTTPS, or DNS to evade inspection.

Splunk SPL:

index=corelight sourcetype=corelight_ssl
| search server_name IN ("dns.google", "dns.google.com", "cloudflare-dns.com", "mozilla.cloudflare-dns.com", "dns.quad9.net", "doh.opendns.com", "dns.nextdns.io", "doh.dns.sb")
| stats count AS conn_count dc(id.orig_h) AS unique_hosts values(id.orig_h) AS src_hosts BY server_name
| sort - conn_count
| table server_name conn_count unique_hosts src_hosts

Elastic KQL:

event.dataset:"corelight.ssl" AND tls.client.server_name:("dns.google" OR "cloudflare-dns.com" OR "mozilla.cloudflare-dns.com" OR "dns.quad9.net" OR "doh.opendns.com" OR "dns.nextdns.io")

Sigma Rule:

title: DNS-over-HTTPS Connection to Known DoH Provider
id: a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
author: RedSheepSec
date: 2026/08/27
description: Detects outbound TLS connections to known DNS-over-HTTPS providers, which may indicate malware (e.g., BRICKSTORM) bypassing corporate DNS inspection per MITRE ATT&CK T1572
logsource:
    category: proxy
    product: any
detection:
    selection_sni:
        c-uri|contains:
            - 'dns.google'
            - 'cloudflare-dns.com'
            - 'dns.quad9.net'
            - 'doh.opendns.com'
            - 'dns.nextdns.io'
    selection_ip:
        dst_ip:
            - '8.8.8.8'
            - '8.8.4.4'
            - '1.1.1.1'
            - '1.0.0.1'
            - '9.9.9.9'
    selection_port:
        dst_port: 443
    condition: (selection_sni or (selection_ip and selection_port))
falsepositives:
    - Browsers with DoH enabled by default (Firefox, Chrome)
    - Legitimate applications using DoH for privacy
level: high
tags:
    - attack.command_and_control
    - attack.t1572

High false positive potential from browsers with DoH enabled by default (Firefox enables DoH natively). Correlate with process name — browser processes are expected; svchost.exe, powershell.exe, or unsigned binaries connecting to DoH providers are highly suspicious. Focus especially on server infrastructure (vCenter, ESXi, domain controllers) making DoH connections, as this is a BRICKSTORM indicator.

T1071.001 — Application Layer Protocol: Web Protocols (Command and Control) [P2]

LummaC2 decrypts C2 domains at runtime and attempts POST requests to each until one succeeds. If primary C2 servers are unreachable, LummaC2 falls back to public services for alternative C2 infrastructure. This multi-domain fallback approach ensures that blocking a single domain does not neutralize the implant.

Splunk SPL:

index=corelight sourcetype=corelight_http
| where method="POST"
| stats count AS post_count dc(host) AS unique_domains values(host) AS domains BY id.orig_h
| where post_count > 50 AND unique_domains > 5
| eval ratio=round(post_count/unique_domains, 2)
| where ratio > 3
| sort - post_count
| table id.orig_h post_count unique_domains ratio domains
| rename id.orig_h AS src_ip

Elastic KQL:

event.dataset:"corelight.http" AND http.request.method:"POST" AND NOT url.domain:(*.microsoft.com OR *.windows.com OR *.office.com OR *.azure.com)

Sigma Rule:

title: Rapid Sequential HTTP POST Requests to Multiple Domains - Possible C2 Fallback
id: e5f6a7b8-c9d0-1e2f-3a4b-5c6d7e8f9a0b
status: experimental
author: RedSheepSec
date: 2026/08/27
description: Detects a single host making HTTP POST requests to multiple distinct domains in rapid succession, consistent with LummaC2 multi-domain C2 fallback behavior
logsource:
    category: proxy
    product: any
detection:
    selection:
        cs-method: 'POST'
    condition: selection | count(c-uri) by src_ip > 20
    timeframe: 5m
falsepositives:
    - Legitimate software update mechanisms
    - Load-balanced API calls from applications
level: medium
tags:
    - attack.command_and_control
    - attack.t1071.001

LummaC2 iterates through decrypted domain lists making POST requests until one succeeds. Look for failed POST attempts (HTTP 4xx/5xx or connection reset) followed by POST to a different domain from the same host within seconds. Correlate with process tree from EDR to identify the originating executable.

T1140 — Deobfuscate/Decode Files or Information (Defense Evasion) [P2]

LummaC2 decrypts its C2 domain list at runtime, meaning static analysis of the binary will not reveal the C2 infrastructure. This runtime decryption is a deliberate evasion technique to prevent signature-based detection of C2 domains in the malware binary.

Splunk SPL:

index=sysmon sourcetype=XmlWinEventLog EventCode=1
| search (CommandLine="*certutil*-decode*" OR CommandLine="*certutil*/decode*" OR CommandLine="*powershell*FromBase64*" OR CommandLine="*powershell*Decompress*" OR CommandLine="*rundll32*" OR CommandLine="*regsvr32*")
| stats count BY Computer, User, ParentImage, Image, CommandLine
| sort - count
| table Computer User ParentImage Image CommandLine count

Elastic KQL:

event.code:"1" AND (process.command_line:(*certutil* AND *decode*) OR process.command_line:(*FromBase64* OR *Decompress*) OR process.name:("rundll32.exe" OR "regsvr32.exe"))

Runtime decryption of C2 domains is difficult to detect at the endpoint level without memory analysis. Focus on detecting the execution of the malware itself through unexpected DLL loads and process anomalies, as Organization B's SOC did with the alert 'An executable file loaded an unexpected DLL file'.

T1568.001 — Dynamic Resolution: Fast Flux DNS (Command and Control) [P2]

Fast flux rapidly rotates IP addresses associated with a malicious domain. In single flux, A records change frequently. In double flux, both IPs and authoritative name servers rotate. Gamaredon, Hive ransomware, Nefilim ransomware, CryptoChameleon, and Raspberry Robin have been observed using fast flux. Gamaredon registers large numbers of .ru TLD domains through REGRU-RU, with IPs changing after approximately one day of use.

Splunk SPL:

index=corelight sourcetype=corelight_dns
| where qtype="A" OR qtype="AAAA"
| where isnotnull(answers)
| stats dc(answers) AS unique_ips values(answers) AS resolved_ips count AS query_count BY query
| where unique_ips > 5
| sort - unique_ips
| head 50
| table query unique_ips query_count resolved_ips

Elastic KQL:

event.dataset:"corelight.dns" AND dns.type:"answer" AND dns.question.type:("A" OR "AAAA") | unique_count dns.resolved_ip by dns.question.name

Sigma Rule:

title: Fast Flux DNS - Domain Resolving to Many Distinct IPs
id: f7a8b9c0-d1e2-3f4a-5b6c-7d8e9f0a1b2c
status: experimental
author: RedSheepSec
date: 2026/08/27
description: Detects domains resolving to an unusually high number of distinct IP addresses within 24 hours, consistent with fast flux DNS techniques used by Gamaredon, Hive, and other threat actors
logsource:
    category: dns
    product: any
detection:
    selection:
        record_type:
            - 'A'
            - 'AAAA'
    condition: selection | count(answer) by query > 5
    timeframe: 24h
falsepositives:
    - CDN-hosted domains (Akamai, CloudFront, Cloudflare)
    - Large-scale load-balanced services
level: medium
tags:
    - attack.command_and_control
    - attack.t1568.001

CDN domains will generate high false positive rates. Maintain a whitelist of known CDN and cloud provider domains. Focus on domains with TTL values under 300 seconds combined with high IP rotation. Cross-reference flagged domains with threat intelligence feeds. Gamaredon specifically uses .ru TLD domains registered through REGRU-RU.

T1568.002 — Dynamic Resolution: Domain Generation Algorithms (Command and Control) [P2]

DGA malware generates thousands of random domains, most of which do not resolve. An attacker registers only a few, making blocking infeasible. A host producing hundreds of NXDOMAIN responses in a short window is a strong DGA indicator. The WUST SOC Lab checklist directs analysts to look for failed resolution patterns as a key indicator.

Splunk SPL:

index=corelight sourcetype=corelight_dns
| where rcode_name="NXDOMAIN"
| bucket _time span=15m
| stats count AS nxdomain_count dc(query) AS unique_queries BY id.orig_h, _time
| where nxdomain_count > 50 AND unique_queries > 40
| sort - nxdomain_count
| table _time id.orig_h nxdomain_count unique_queries
| rename id.orig_h AS src_ip

Elastic KQL:

event.dataset:"corelight.dns" AND dns.response_code:"NXDOMAIN" | terms source.ip | threshold_alert count > 50 per 15m

Sigma Rule:

title: Repeated Blocked DNS Queries to Same Malicious Domain
id: c8e3f2a1-4b7d-4e9a-b3c1-6d8f9e2a4b7c
status: experimental
author: RedSheepSec
date: 2026/08/26
description: Detects a single host generating multiple blocked DNS queries to the same domain within a short window, indicating possible malware C2 retry behavior
logsource:
    category: dns
    product: any
detection:
    selection:
        response_code: 'NXDOMAIN'
    filter_blocked:
        action: 'blocked'
    condition: selection or filter_blocked | count(query) by src_ip > 10
    timeframe: 15m
falsepositives:
    - Legitimate software with aggressive DNS retry logic
    - Misconfigured applications querying deprecated domains
level: high
tags:
    - attack.command_and_control
    - attack.t1071.004
    - attack.t1568.002

DGA detection is high-value but requires tuning. Legitimate software updaters and broken applications can generate NXDOMAIN spikes. Establish a baseline of normal NXDOMAIN rates per host. Focus on hosts generating high NXDOMAIN counts with high-entropy domain names (random-looking strings). A host with 200+ NXDOMAIN responses in 15 minutes with unique domain names is almost certainly running DGA malware.

T1082 — System Information Discovery (Discovery) [P2]

LummaC2 performs system enumeration after establishing C2. In the CISA red team assessment, before one Organization B workstation was isolated, the red team had already enumerated Active Directory structure via LDAP queries through the active C2 callback. This demonstrates that even brief C2 windows enable adversary reconnaissance.

Splunk SPL:

index=corelight sourcetype=corelight_ldap
| stats count AS ldap_query_count dc(base_object) AS unique_bases values(base_object) AS bases BY id.orig_h
| where ldap_query_count > 20
| sort - ldap_query_count
| table id.orig_h ldap_query_count unique_bases bases
| rename id.orig_h AS src_ip

Elastic KQL:

event.dataset:"corelight.ldap" AND NOT source.ip:("10.0.0.0/8" AND destination.ip:"10.0.0.0/8") | terms source.ip

LDAP enumeration from workstations (as opposed to domain controllers or admin jump servers) is suspicious. Correlate LDAP query bursts with preceding DNS blocks or C2 alerts to identify adversary reconnaissance during brief C2 windows.

T1204 — User Execution (Execution) [P2]

Initial access in the CISA red team assessment was via phishing payload execution. Each payload generated a medium-severity alert: 'An executable file loaded an unexpected DLL file.' Organization B's SOC triaged these alerts and isolated affected workstations within 2-20 minutes. Organization A failed to act on equivalent alerts.

Splunk SPL:

index=sysmon sourcetype=XmlWinEventLog EventCode=7
| where Signed="false" OR SignatureStatus!="Valid"
| where NOT match(ImageLoaded, "(?i)(Microsoft|Windows|Program Files)")
| stats count BY Computer, Image, ImageLoaded, Signed, SignatureStatus
| where count > 0
| sort - count
| table Computer Image ImageLoaded Signed SignatureStatus count

Elastic KQL:

event.code:"7" AND NOT dll.code_signature.valid:true AND NOT dll.path:(*Microsoft* OR *Windows* OR *Program\ Files*)

Sigma Rule:

title: Executable Loading Unexpected Unsigned DLL
id: b2c3d4e5-f6a7-8b9c-0d1e-2f3a4b5c6d7e
status: experimental
author: RedSheepSec
date: 2026/08/27
description: Detects an executable loading an unsigned or unexpectedly signed DLL, mimicking the alert pattern that Organization B used to detect CISA red team phishing payloads
logsource:
    category: image_load
    product: windows
detection:
    selection:
        Signed: 'false'
    filter_system:
        ImageLoaded|contains:
            - '\\Windows\\'
            - '\\Program Files\\'
            - '\\Program Files (x86)\\'
    condition: selection and not filter_system
falsepositives:
    - Custom in-house applications with unsigned DLLs
    - Development environments
level: medium
tags:
    - attack.execution
    - attack.t1204
    - attack.defense_evasion
    - attack.t1574.002

This detection mirrors the alert type that Organization B's SOC used to catch the CISA red team. High false positive rate expected in development environments. Focus on user workstations, not developer machines. Correlate with email delivery timestamps and user-initiated process execution to identify phishing payload execution.

Indicators of Compromise

IOC Sweep Queries (Splunk):

index=firewall-pan sourcetype="pan:traffic:aggregated" dest_ip="8.8.8.8" dest_port=443
| stats count AS conn_count values(src_ip) AS source_hosts BY dest_ip, dest_port, app
| sort - conn_count
| table dest_ip dest_port app conn_count source_hosts

index=firewall-pan sourcetype="pan:traffic:aggregated" dest_ip="8.8.4.4" dest_port=443
| stats count AS conn_count values(src_ip) AS source_hosts BY dest_ip, dest_port, app
| sort - conn_count
| table dest_ip dest_port app conn_count source_hosts

index=firewall-pan sourcetype="pan:traffic:aggregated" dest_ip="1.1.1.1" dest_port=443
| stats count AS conn_count values(src_ip) AS source_hosts BY dest_ip, dest_port, app
| sort - conn_count
| table dest_ip dest_port app conn_count source_hosts

index=firewall-pan sourcetype="pan:traffic:aggregated" dest_ip="1.0.0.1" dest_port=443
| stats count AS conn_count values(src_ip) AS source_hosts BY dest_ip, dest_port, app
| sort - conn_count
| table dest_ip dest_port app conn_count source_hosts

index=firewall-pan sourcetype="pan:traffic:aggregated" dest_ip="9.9.9.9" dest_port=443
| stats count AS conn_count values(src_ip) AS source_hosts BY dest_ip, dest_port, app
| sort - conn_count
| table dest_ip dest_port app conn_count source_hosts

index=corelight sourcetype=corelight_ssl server_name="dns.google"
| stats count BY id.orig_h, id.resp_h, id.resp_p
| sort - count
| table id.orig_h id.resp_h id.resp_p count

index=corelight sourcetype=corelight_ssl server_name="cloudflare-dns.com"
| stats count BY id.orig_h, id.resp_h, id.resp_p
| sort - count
| table id.orig_h id.resp_h id.resp_p count

index=corelight sourcetype=corelight_ssl server_name="dns.quad9.net"
| stats count BY id.orig_h, id.resp_h, id.resp_p
| sort - count
| table id.orig_h id.resp_h id.resp_p count

YARA Rules

HUNT_LummaC2_C2_Fallback_Strings — Detects potential LummaC2 infostealer samples based on characteristic string patterns associated with multi-domain C2 fallback behavior and system enumeration capabilities

rule HUNT_LummaC2_C2_Fallback_Strings
{
    meta:
        author = "RedSheepSec"
        description = "Detects potential LummaC2 infostealer based on C2 fallback and stealer behavioral strings"
        reference = "https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-141b"
        date = "2026-08-27"
        threat = "LummaC2"

    strings:
        $s1 = "POST" ascii wide
        $s2 = "Content-Type: application/x-www-form-urlencoded" ascii wide
        $s3 = "Mozilla/5.0" ascii wide
        $wallet1 = "wallet.dat" ascii wide nocase
        $wallet2 = "Ethereum" ascii wide nocase
        $browser1 = "Login Data" ascii wide
        $browser2 = "Cookies" ascii wide
        $browser3 = "Web Data" ascii wide
        $crypto1 = "Exodus" ascii wide nocase
        $crypto2 = "Electrum" ascii wide nocase
        $enum1 = "COMPUTERNAME" ascii wide
        $enum2 = "USERNAME" ascii wide
        $enum3 = "APPDATA" ascii wide

    condition:
        uint16(0) == 0x5A4D and
        filesize < 5MB and
        all of ($s*) and
        2 of ($wallet*, $crypto*) and
        2 of ($browser*) and
        2 of ($enum*)
}

HUNT_BRICKSTORM_DoH_Indicators — Detects potential BRICKSTORM backdoor samples based on DNS-over-HTTPS provider strings and WebSocket/TLS layering indicators associated with UNC5221 operations

rule HUNT_BRICKSTORM_DoH_Indicators
{
    meta:
        author = "RedSheepSec"
        description = "Detects potential BRICKSTORM backdoor based on DoH provider references and protocol tunneling indicators"
        reference = "https://www.cisa.gov/news-events/analysis-reports/ar25-338a"
        date = "2026-08-27"
        threat = "BRICKSTORM"
        actor = "UNC5221"

    strings:
        $doh1 = "dns.google" ascii wide
        $doh2 = "cloudflare-dns.com" ascii wide
        $doh3 = "dns.quad9.net" ascii wide
        $doh4 = "application/dns-message" ascii wide
        $doh5 = "dns-query" ascii wide
        $ws1 = "Upgrade: websocket" ascii wide nocase
        $ws2 = "Sec-WebSocket" ascii wide nocase
        $tls1 = "tls" ascii wide
        $net1 = "/dns-query" ascii wide
        $net2 = "Accept: application/dns-message" ascii wide

    condition:
        uint16(0) == 0x5A4D and
        filesize < 10MB and
        2 of ($doh*) and
        1 of ($ws*) and
        1 of ($net*)
}

Suricata Rules

SID 2026001 — Detects DNS-over-HTTPS requests to Google DoH service (dns.google) on port 443, which may indicate malware like BRICKSTORM bypassing corporate DNS inspection

alert tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"HUNT DoH Connection to dns.google - Possible BRICKSTORM C2 Bypass"; tls.sni; content:"dns.google"; nocase; flow:established,to_server; threshold:type limit, track by_src, count 1, seconds 300; classtype:policy-violation; sid:2026001; rev:1; metadata:mitre_technique T1572, deployment Perimeter, created_at 2026_08_27;)

SID 2026002 — Detects DNS-over-HTTPS requests to Cloudflare DoH service (cloudflare-dns.com) on port 443, potential BRICKSTORM or DoH-abusing malware indicator

alert tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"HUNT DoH Connection to cloudflare-dns.com - Possible C2 DNS Bypass"; tls.sni; content:"cloudflare-dns.com"; nocase; flow:established,to_server; threshold:type limit, track by_src, count 1, seconds 300; classtype:policy-violation; sid:2026002; rev:1; metadata:mitre_technique T1572, deployment Perimeter, created_at 2026_08_27;)

SID 2026003 — Detects DNS-over-HTTPS requests to Quad9 DoH service (dns.quad9.net) on port 443, potential indicator of malware bypassing corporate DNS controls

alert tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"HUNT DoH Connection to dns.quad9.net - Possible C2 DNS Bypass"; tls.sni; content:"dns.quad9.net"; nocase; flow:established,to_server; threshold:type limit, track by_src, count 1, seconds 300; classtype:policy-violation; sid:2026003; rev:1; metadata:mitre_technique T1572, deployment Perimeter, created_at 2026_08_27;)

SID 2026004 — Detects potential DNS tunneling based on unusually long DNS query names (>60 characters in subdomain), indicative of data exfiltration or C2 via DNS per T1071.004

alert dns $HOME_NET any -> any 53 (msg:"HUNT Potential DNS Tunneling - Long Query Name"; dns.query; content:".."; pcre:"/^[a-zA-Z0-9\-]{50,}\./"; flow:to_server; threshold:type threshold, track by_src, count 10, seconds 60; classtype:trojan-activity; sid:2026004; rev:1; metadata:mitre_technique T1071.004, deployment Internal, created_at 2026_08_27;)

SID 2026005 — Detects high volume NXDOMAIN responses to a single host, indicative of Domain Generation Algorithm (DGA) activity per T1568.002

alert dns any 53 -> $HOME_NET any (msg:"HUNT High NXDOMAIN Rate - Possible DGA Activity"; dns.opcode:0; content:"|83|"; offset:3; depth:1; threshold:type threshold, track by_dst, count 50, seconds 300; classtype:trojan-activity; sid:2026005; rev:1; metadata:mitre_technique T1568.002, deployment Internal, created_at 2026_08_27;)

Data Source Requirements

Recommendations

• Audit and remediate DNS alert closure workflows: Review all 'blocked' DNS alerts closed without investigation over the past 30 days. Flag any showing retry patterns (same domain, same host, >10 queries within 15 minutes) for retroactive triage with full EDR process tree correlation. Implement a mandatory 15-minute triage SLA for any blocked connection to a domain categorized as C2 infrastructure, matching Organization B's demonstrated response timeline.
• Block external DNS-over-HTTPS at the network perimeter: Deploy firewall rules on Palo Alto (index=firewall-pan) denying outbound HTTPS (port 443) to known DoH provider IPs (8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1, 9.9.9.9). Implement TLS SNI-based filtering for DoH domains (dns.google, cloudflare-dns.com, dns.quad9.net). Deploy Group Policy or MDM policies to disable DoH in browsers and OS-level DNS settings. This directly counters BRICKSTORM's DoH bypass technique documented in CISA MAR AR25-338A.
• Deploy all Appendix B detection analytics across Splunk and Elastic instances: Prioritize the DNS beaconing/retry detection (T1568.002), DoH connection detection (T1572), NXDOMAIN DGA spike detection (T1568.002), high-entropy subdomain detection (T1071.004), and unsigned DLL load detection (T1204). Configure SIEM enrichment to automatically append originating process name and parent process from EDR telemetry to every blocked DNS alert.
• Implement weekly fast flux hunting cadence: Query Corelight DNS logs for domains resolving to more than 5 distinct IPs within 24 hours or domains with TTL values under 300 seconds. Cross-reference flagged domains against threat intelligence feeds. Pay special attention to .ru TLD domains registered through REGRU-RU registrar (Gamaredon indicator).
• Conduct targeted hunt on VMware vCenter and ESXi infrastructure: BRICKSTORM was documented targeting VMware vCenter servers with extended dwell times (months before detection). Sweep all vCenter/ESXi hosts for unexpected outbound connections on port 443 to IPs not in the approved baseline, and for any DNS queries (standard or DoH) to domains matching BRICKSTORM IOCs from CISA MAR AR25-338A.
• Deploy Suricata rules SID 2026001-2026005 on network sensors: These rules detect DoH connections to Google/Cloudflare/Quad9, DNS tunneling via long query names, and DGA-indicative NXDOMAIN spikes. Deploy on both perimeter and internal sensor positions to detect lateral movement C2.

Sources

• CISA Advisory AA26-237A: A Tale of Two SOCs
• CISA Malware Analysis Report: BRICKSTORM Backdoor (AR25-338A)
• CISA/FBI Advisory AA25-141B: LummaC2 Malware
• CISA Advisory AA25-093A: Fast Flux: A National Security Threat
• MITRE ATT&CK T1071.004: Application Layer Protocol: DNS
• MITRE ATT&CK T1572: Protocol Tunneling
• Enterprise DNS Security Guide: Filtering, Monitoring, and Hardening
• Why DNS Traffic Is Still an Underrated Detection Source
• The Hacker News: CISA Red Team Compromised Two Critical Infrastructure Orgs
• Industrial Cyber: CISA Updates BRICKSTORM Malware Report
• Picus Security: BRICKSTORM Malware and UNC5221
• BleepingComputer: CISA Warns of Fast Flux DNS Evasion
• WUST SOC Lab: Must-Know Logs for SOC Analysts
• UnderDefense: AI SOC Analyst Complete Guide
• StartupDefense: Command and Control TA0011
• Microsoft Tech Community: Azure DNS Security Policy GA
• UptimeRobot: DNS Security Best Practices
• TrustMyIP: Best DNS Security Solutions
• CISA/NSA/Cyber Centre: BRICKSTORM Malware Analysis Report PDF