AN1180: Analytic 1180
Monitor unified DNS logs for abnormal domain queries with low lexical similarity to known domains, repeated failed lookups, and random string structures. Cross-check with process logs to confirm unusual origins (non-browser apps).
Analyst context for executives and security teams
This analytic is about using macOS DNS evidence to find domain lookups that look algorithmic, random, repeatedly unsuccessful, or unlike normal known domains, then checking which process generated them. For leaders, the value is not the DNS pattern alone; it is the ability to connect suspicious network intent to an endpoint process quickly enough to support containment, investigation, and business-risk decisions.
Executive priority
Prioritize this where macOS endpoints are material to business operations or privileged user workflows. The executive question is whether the organization can prove it collects enough DNS and process telemetry to distinguish normal application behavior from unusual non-browser domain activity. This supports SOC readiness, incident response triage, and audit evidence around endpoint and network monitoring coverage.
Technical view
For SOC and detection teams, validate that macOS unified DNS logs are available, searchable, and retain query names, lookup outcomes, timing, and host context. Correlate abnormal domains showing low lexical similarity to known domains, repeated failed lookups, or random-looking string structures with process logs to identify unusual origins, especially non-browser applications. Because no ATT&CK tactics or relationship context were supplied, this should be treated as a detection analytic pattern rather than evidence of a specific technique or intrusion by itself.
Likely telemetry
- macOS unified DNS logs
- DNS query names and response or failure status
- Endpoint process execution logs
- Process-to-network or process-to-DNS correlation data
- Host identity, user context, timestamps, and application/process metadata
Detection direction
- Confirm DNS telemetry includes failed lookups and enough domain detail to assess random-looking or low-similarity query patterns.
- Tune baselines around expected browser, updater, security tool, developer, and enterprise application DNS behavior to reduce false positives.
- Prioritize alerts where repeated failed DNS lookups or random-string domains originate from non-browser or unexpected processes.
- Validate time correlation between DNS events and process logs so analysts can identify the responsible application during investigation.
- Document blind spots where macOS DNS logs are not collected, process visibility is missing, or retention is too short for incident response.
Mitigation priorities
- First, close telemetry gaps for macOS DNS and process logging before relying on this analytic for coverage claims.
- Next, define normal domain-query behavior for common enterprise applications and browser activity to support practical tuning.
- Then, integrate DNS-process correlation into SOC triage playbooks so unusual lookups can be tied to a host, user, and process owner.
- Finally, use findings to inform endpoint hardening, application control review, and incident response procedures where unexpected processes generate suspicious DNS patterns.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for macOS and provides a monitoring description, but no separate official detection logic, tactics, or relationships. Treat it as guidance for validating DNS and process telemetry rather than a complete rule. Local baselines are essential because some legitimate software may generate unusual or failed DNS queries.
This take is limited to the supplied STIX fields and external reference. No active exploitation, attribution, specific ATT&CK technique mapping, impact scenario, or guaranteed detection coverage is supported by the provided object.
Analytic 1180
Monitor unified DNS logs for abnormal domain queries with low lexical similarity to known domains, repeated failed lookups, and random string structures. Cross-check with process logs to confirm unusual origins (non-browser apps).
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 | f4d8fe024d92… |
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 AN1180Open 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.