ADIDNS poisoning is the manipulation of Active Directory-integrated DNS records so systems resolve names to attacker-controlled hosts. Attackers use it to intercept traffic, capture credentials, or enable man-in-the-middle attacks. Defenders should restrict who can update DNS records, audit changes, and monitor for unexpected record creation or modification.
What ADIDNS poisoning changes in an Active Directory environment
ADIDNS poisoning turns the DNS layer inside Active Directory into an access path for deception. Because DNS answers are trusted by many internal systems, a poisoned record can redirect users and services without needing to compromise the target host itself.
The danger is that the attacker does not need to break the application to intercept it. They only need a name resolution path that other systems trust, which makes this technique especially effective for internal traffic capture, credential interception, and man-in-the-middle positioning.
How ADIDNS poisoning works
Active Directory-integrated DNS stores records in AD, so directory permissions and DNS update rights matter as much as the DNS server itself. If an attacker can create, alter, or delete records, they can influence where internal clients connect and what infrastructure they trust.
This is often abused through unexpected record creation, record overwrite, or the planting of lookalike hostnames that blend into normal directory activity. The technique is attractive because DNS changes can look administrative rather than overtly malicious, especially in busy environments with many delegated operators.
Why poisoned DNS records are operationally dangerous
A poisoned record can redirect browsers, service clients, APIs, or administrative tools to attacker-controlled systems. Once that happens, the attacker may harvest credentials, proxy authentication flows, or position a relay service between the victim and the intended destination.
In practice, the blast radius depends on what the record name represents. A single altered entry may affect only one host, but poisoned service records, discovery records, or commonly used internal names can influence many users and workflows at once.
How defenders validate and contain exposure
Exposure checks should begin with who can update AD-integrated DNS records, which zones are writable, and whether those permissions are broader than necessary. Defenders should also compare DNS activity against expected administration patterns and review whether internal names are published more widely than they need to be.
Detection should focus on unexpected record creation, modification, or deletion, especially when a new record points to an unusual address, a non-standard host, or a system outside the normal trust boundary. Change auditing is most useful when it is paired with inventory of important internal names and a known-good baseline of authoritative DNS data.
Risk and Threat Considerations
ADIDNS poisoning is risky because it attacks trust in name resolution, which many internal controls assume is already correct. That makes it useful for stealthy interception, phishing inside the network, and credential capture without immediately breaking the victim workflow.
Failure mechanism: If an attacker can write to AD-integrated DNS, they can replace or plant records that cause clients to resolve legitimate names to malicious infrastructure, enabling redirection and traffic interception.
Impact: The result can include credential exposure, session theft, man-in-the-middle access, and downstream compromise of systems that rely on the poisoned resolution path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | ADIDNS poisoning depends on detecting record changes and suspicious directory-linked DNS activity. |
| AC-6 — Least Privilege | Only tightly scoped operators should be able to alter AD-integrated DNS records. | |
| SI-4 — System Monitoring | Poisoned records are often uncovered through anomaly monitoring of name resolution and endpoint behavior. | |
| Recommendation — Log DNS record creation, modification, and deletion events for review and correlation. Restrict DNS update rights to the minimum set of authorized administrators. Monitor DNS changes and resolution anomalies for signs of unauthorized record manipulation. | ||
Practitioner Guidance
Governance implication: Treat DNS write access as a privileged capability, not an administrative convenience. The smallest practical set of operators should be able to modify AD-integrated records, and those rights should be reviewed on the same cadence as other high-impact directory permissions.
What to watch for: Investigate sudden record additions, unexpected edits to existing internal names, and DNS changes that do not align with approved change windows or known service deployments. After a confirmed poisoning event, review affected authentication flows and any accounts, sessions, or systems that may have followed the fraudulent resolution path.
Related resources from NHI Mgmt Group
- Guide: Active Directory and Entra ID Hardening Guide
- What is agent communication poisoning?
- How should security teams reduce the risk of AI tool poisoning?
- What is the difference between prompt injection and tool poisoning?
- What is the difference between prompt injection and tool poisoning in agentic systems?