Still Poisoned: Authenticated Users and Microsoft DNS Hijacks
This article is part of a series unpacking the NSA/CISA Top 10 Cybersecurity Misconfigurations through the lens of real-world breaches and assessment findings.
This entry continues Misconfiguration 1: Default Configurations of Software and Applications, with a focus on Microsoft DNS and overlooked ACLs that allow unauthorised internal record modification, or in other words, DNS Poisoning or redirection.
DNS is often treated as infrastructure, not as an attack surface. But when integrated with Active Directory and left misconfigured, as it often is, it becomes a quiet tool for internal hijacking. In many environments, Authenticated Users have write access to internal DNS zones by default. That means any domain user can overwrite legitimate records or register rogue entries without elevated privileges.
These changes do not trigger endpoint alerts. They do not require malware. And they bypass the usual layers of detection and control because the attacker is not breaking in. They are using what the system already allows.
I have seen this repeatedly in enterprise environments. A client assumes their EDR platform or network filter would catch suspicious activity. But when DNS is poisoned from inside, it is the resolver that lies. The tools never get a chance to intervene.
DNS is not just a lookup service. It is a trust anchor. If an attacker controls DNS, they can control where users and systems connect. Even inside a segmented network.
TL;DR:
If Authenticated Users can write to your DNS zones, you are one rogue record away from a redirect. Microsoft DNS defaults still allow this in many environments. Attackers do not need exploits. They just need permission you forgot to remove.
What This Looks Like in Practice
In many environments that use Microsoft DNS integrated with Active Directory, internal zones are quietly exposed. By default, Authenticated Users often have write access to DNS records. That includes any standard domain user. This is not a vulnerability. It is an ACL that was never updated.
Attackers do not need to compromise privileged accounts. They can authenticate as any user, browse the zone, and overwrite records. Common targets include Microsoft DNS, which is typically enabled on each domain controller as part of the standard feature set.
I have seen this used in real-world breaches. The attacker identifies a commonly utilised website, overwrites the A record with their own controlled IP, and waits. Clients connect automatically. Endpoint tools do not block it because the DNS response came from a trusted resolver. The connection looks valid. No alarms fire. This tactic is especially effective against organisations using Cisco Umbrella, Zscaler, or similar tools that rely on DNS or HTTP layer inspection. If internal DNS sends the request straight to the compromised resolver, the protective overlay never sees it.
I have also seen attackers plant fake records for phishing, credential capture, and lateral movement. In one case, a record for citrix.internal was redirected to a rogue page. It used the organisation’s internal cert and login banner. Users authenticated, thinking they were logging in to the real system. This kind of abuse does not require exploits. It just requires access to a record that someone forgot to lock down.
How to Lock It Down
1. Review your zone permissions directly
Open dnsmgmt.msc, right-click each forward lookup zone, especially corp.local, internal.lan, or any AD-integrated zone, and open the Security tab. Look for groups like “Authenticated Users,” “Domain Users,” or anything overly broad with permissions such as Create All Child Objects, Delete All Child Objects, or Write. If those are present, you have an internal poisoning risk.
I have seen this ACL left in place even in security-conscious organisations. It is often assumed to be necessary for dynamic updates or inherited from older forest setups. It usually survives migrations and upgrades without anyone reviewing it.
2. Limit write access to a known group, and treat it as privileged
Write permissions should be limited to a controlled group such as DNSAdmins or an explicitly defined infrastructure team. But access is only part of the story. Membership in these groups should trigger alerts. These users should be treated as privileged.
They should not use their day-to-day accounts to manage DNS. Use dedicated credentials, preferably vaulted and audited through a privileged access management solution such as CyberArk. Even without full PAM integration, segment these accounts, enforce multi-factor authentication, and monitor their usage.
Where possible, ingest Event ID 5137 from the Security log. It logs directory service object creation, including DNS nodes in AD‑integrated zones. That makes it useful for detecting unauthorised DNS record additions, if auditing is enabled and logs are collected from the correct DC.
3. Monitor changes to critical records
Focus on records tied to authentication, user access, or client routing. Examples include vpn, mail, proxy, citrix, and any entry referenced by internal PAC files. These are high-value DNS records. If one changes unexpectedly, you need to know about it.
Full SIEM integration is ideal, but not required. You can run regular zone exports and alert on changes, or use DNS debug logging if it is enabled. Even low-friction methods like file-based diffs or basic log parsing can catch tampering.
4. Test exposure, including dev and UAT environments
Use a standard domain user to test DNS changes. If they can register a new A or CNAME record, the zone is exposed. This method is fast, direct, and often reveals far more than internal documentation suggests.
Dev, UAT, and lab environments are just as critical to review. These often have weaker controls, looser permissions, or cross-trust links to production. If DNS zones in these environments are exposed, an attacker can plant records that pivot into prod without triggering any alerts.
While testing, always check for wildcard entries such as *. These should be rare. When present, they allow redirection of whole namespaces and can silently hijack traffic across internal services. If a wildcard exists, confirm who added it and whether it is still needed.
Final Thoughts
This is not a zero-day. It is a default that no one reviewed.
When Microsoft DNS is integrated with Active Directory, it often inherits overly broad permissions. If any authenticated user can write to internal zones, then so can an attacker. They do not need malware. Just a domain login. There is no breach required. The system is working as configured.
Fixing it is not a tooling problem. It is an ownership problem. Treat DNS as part of your privileged estate. Lock down who can write to zones. Monitor for critical record changes. And test from a standard user account to see what is really exposed. If DNS is trusted by everything else, it cannot be left unchecked.
Get in touch