AN1124: Analytic 1124
Detects clients issuing DNS queries with high volume, long subdomain lengths, encoded payload patterns, or to known malicious infrastructure; indicative of DNS-based C2 channels.
Analyst context for executives and security teams
This analytic matters because DNS is often allowed through enterprise networks and can become a quiet command-and-control path. For leaders, the practical question is whether network monitoring can distinguish normal DNS activity from clients producing unusually high query volume, long or encoded-looking subdomains, or requests to known malicious infrastructure.
Executive priority
Prioritize this as a resilience and SOC-readiness validation item for environments where DNS visibility is central to detecting outbound control channels. Executives should ask whether DNS telemetry from network devices is retained, searchable, and used in incident response, and whether teams can provide evidence of monitoring for suspicious DNS patterns without relying only on endpoint alerts.
Technical view
For SOC and detection engineering teams, validate DNS-focused detections on network-device telemetry for: unusually high query volume by client, abnormal subdomain length, encoded payload-like strings in queried names, and queries to known malicious infrastructure. Because the ATT&CK object does not specify a tactic or provide detailed detection logic, teams should tune thresholds against local DNS baselines and document assumptions about normal high-volume services, content delivery, security tools, and automated infrastructure.
Likely telemetry
- DNS query logs from network devices
- Client source IP or host identifiers associated with DNS requests
- Queried domain and subdomain strings
- DNS query volume over time by client
- Threat intelligence matches for known malicious DNS infrastructure
Detection direction
- Confirm that DNS query logging is enabled on relevant network devices and retained long enough to support investigation.
- Baseline normal DNS query volume per client before alerting on high-volume behavior.
- Inspect long subdomain lengths and encoded-looking labels, while tuning for legitimate applications that generate long or random-looking domains.
- Correlate suspicious DNS patterns with known malicious infrastructure indicators where available.
- Review false positives from automated services, cloud applications, update mechanisms, and security tooling that may produce high DNS volume or unusual names.
Mitigation priorities
- Ensure authoritative DNS monitoring responsibilities are assigned across network, SOC, and incident response teams.
- Centralize and retain DNS telemetry from network devices for investigation and compliance evidence.
- Use vetted threat intelligence to enrich DNS infrastructure matches without treating indicator matches as the only detection path.
- Create incident response playbooks for triaging clients with suspicious DNS behavior, including containment decision points.
- Periodically test whether DNS-based suspicious patterns are visible in current telemetry and alerting workflows.
Analyst notes and limits
The supplied object is a detection analytic for Network Devices and describes DNS-query characteristics associated with possible DNS-based command-and-control. No ATT&CK relationships, tactic mapping, detailed detection pseudocode, or mitigation object links were supplied, so this take focuses on defensive validation rather than asserting coverage or threat actor behavior.
This summary is limited to the official STIX fields and external reference provided. It does not establish active exploitation, attribution, guaranteed detection, or applicability beyond Network Devices. Local DNS architecture, resolver placement, logging configuration, baselines, and threat intelligence quality determine operational value.
Analytic 1124
Detects clients issuing DNS queries with high volume, long subdomain lengths, encoded payload patterns, or to known malicious infrastructure; indicative of DNS-based C2 channels.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 9eb1fa32faf7… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1124Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.