AN1896: Analytic 1896
Monitor HKLM\Software\Policies\Microsoft\Windows NT\DNSClient for changes to the "EnableMulticast" DWORD value. A value of "0" indicates LLMNR is disabled. Host-based implementations of this technique may utilize networking-based system calls or network utility commands (e.g., iptables) to locally intercept traffic. Monitor for relevant process creation events. Monitor for network traffic originating from unknown/unexpected hosts. Local network traffic metadata (such as source MAC addressing) as well as usage of network management protocols such as DHCP may be helpful in identifying hardware. For added context on adversary procedures and background see Adversary-in-the-Middle and applicable sub-techniques. Monitor for newly constructed services/daemons through Windows event logs for event IDs 4697 and 7045. Monitor network traffic for anomalies associated with known AiTM behavior. For Collection activity where transmitted data is not manipulated, anomalies may be present in network management protocols (e.g., ARP, DHCP). Monitor application logs for changes to settings and other events associated with network protocols and other services commonly abused for AiTM.
Analyst context for executives and security teams
This analytic is useful because it points defenders toward evidence that may reveal adversary-in-the-middle conditions or local traffic interception in environments where network trust and operational continuity matter. The practical value is not a single alert; it is validating whether teams can see changes to name-resolution behavior, unexpected local-network participants, new services, and anomalous ARP/DHCP or related protocol activity before they affect response decisions.
Executive priority
Treat this as a coverage-validation item for environments where local network manipulation could disrupt operations, weaken identity assurance, or complicate incident response. Leaders should ask whether the SOC can prove collection of the registry, process, service-installation, application-log, and network metadata needed to investigate suspected adversary-in-the-middle behavior, especially in cyber-physical or ICS-adjacent networks where asset identity and network baselines are often incomplete.
Technical view
The supplied analytic focuses on monitoring HKLM\Software\Policies\Microsoft\Windows NT\DNSClient for changes to the EnableMulticast DWORD value, where 0 indicates LLMNR is disabled. It also calls for monitoring relevant process creation when host-based implementations use networking-related system calls or utilities, traffic from unknown or unexpected hosts, local network metadata such as source MAC addressing, DHCP and ARP behavior, new services or daemons through event IDs 4697 and 7045, and application logs for changes to network protocol or service settings. SOC and IR teams should validate that these data sources can be correlated around the same host, MAC address, time window, and network segment rather than treated as unrelated low-severity events.
Likely telemetry
- Registry change monitoring for HKLM\Software\Policies\Microsoft\Windows NT\DNSClient and the EnableMulticast DWORD value
- Process creation events involving network utilities or networking-related local interception behavior
- Network traffic metadata from local segments, including source MAC addressing where available
- DHCP and ARP activity and other network management protocol logs or metadata
- Windows service creation or installation events, including event IDs 4697 and 7045 as cited by the analytic
Detection direction
- Validate that registry changes to the cited DNSClient policy path are collected and alertable, while accounting for legitimate administrative policy changes.
- Baseline known hosts, MAC addresses, DHCP behavior, and expected local-network participants so unknown or unexpected traffic can be triaged with context.
- Correlate new service creation events with nearby process creation, registry changes, and anomalous ARP/DHCP or local traffic metadata.
- Tune for false positives from approved infrastructure changes, endpoint hardening, group policy updates, network maintenance, and legitimate service deployments.
- Use the ATT&CK context referenced by the analytic, including Adversary-in-the-Middle and applicable sub-techniques, to structure investigations without assuming malicious intent from any single signal.
Mitigation priorities
- Prioritize visibility first: confirm collection of registry, service creation, process creation, application log, DHCP/ARP, and local network metadata relevant to this analytic.
- Maintain authoritative asset and network-segment inventories so unknown hosts and unexpected MAC/DHCP behavior can be assessed quickly.
- Define change-control evidence for DNS, name-resolution, network service, and local network configuration changes to separate approved administration from suspicious activity.
- Ensure SOC and incident response playbooks include triage steps for suspected adversary-in-the-middle conditions, including correlation across endpoint and network evidence.
- Where operational technology or ICS networks are in scope, review monitoring placement and logging gaps on local segments because network metadata may be decisive for investigation.
Analyst notes and limits
This object is an ATT&CK detection analytic in the ICS domain, but no ATT&CK platforms, tactics, relationships, or separate official detection field were supplied. The guidance above is therefore centered on the official description and its cited evidence types rather than on technique relationships or asserted platform coverage.
The supplied object provides no relationship context, no explicit platforms, no tactics, and no official detection logic beyond descriptive monitoring guidance. Local baselines, asset inventory, logging architecture, and change-management records are required to determine whether any observed event is suspicious or expected.
Analytic 1896
Monitor HKLM\Software\Policies\Microsoft\Windows NT\DNSClient for changes to the "EnableMulticast" DWORD value. A value of "0" indicates LLMNR is disabled. Host-based implementations of this technique may utilize networking-based system calls or network utility commands (e.g., iptables) to locally intercept traffic. Monitor for relevant process creation events. Monitor for network traffic originating from unknown/unexpected hosts. Local network traffic metadata (such as source MAC addressing) as well as usage of network management protocols such as DHCP may be helpful in identifying hardware. For added context on adversary procedures and background see Adversary-in-the-Middle and applicable sub-techniques. Monitor for newly constructed services/daemons through Windows event logs for event IDs 4697 and 7045. Monitor network traffic for anomalies associated with known AiTM behavior. For Collection activity where transmitted data is not manipulated, anomalies may be present in network management protocols (e.g., ARP, DHCP). Monitor application logs for changes to settings and other events associated with network protocols and other services commonly abused for AiTM.
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 | f534942e3a6b… |
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 AN1896Open 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.