In this second super short post, I want to explore an unusual Group Policy Object (GPO) configuration I recently encountered.

The GPO in question used a File Preference policy to copy a custom HOSTS file from a remote share to the local machine’s HOSTS file:

This caught my attention because it introduced an unexpected element to the hostname resolution process.

Understanding the Hostname Resolution Order

As many of you know, hostname resolution in Windows follows a predefined order. Typically, it prioritizes the HOSTS file over DNS. This means that any entry in the HOSTS file will take precedence over DNS lookups, effectively overriding network-level name resolution.

The Incredible Twist

So far, so good, this setup might make sense (??) in certain environments for hostname standardization. However, the incredible discovery was that the source HOSTS file on the remote share granted “Users” full control!

This was a significant red flag. It meant any authenticated user on the domain could potentially modify the file, introducing malicious entries that would propagate to all machines affected by the GPO.

Why Is This a Problem?

With this level of access, an attacker could:

• Redirect Traffic: Point legitimate hostnames (e.g., server.company.local) to malicious IP addresses.
• Create MitM Opportunities: Use spoofed entries to route traffic through an attacker-controlled machine.
• Disrupt Services: Break connections to critical resources by pointing them to non-existent or incorrect IP addresses.

This configuration essentially opened the door for widespread abuse, leveraging the HOSTS file’s precedence over DNS.

Thinking Bigger: What Other Configurations Enable Hostname Spoofing?

This discovery led me to consider other scenarios where hostname spoofing might be possible. Here are a few additional configurations:

1. DnsAdmins Group Privileges: Members of the privileged DnsAdmins group can modify DNS records, giving them the ability to redirect traffic at will.
2. Zones with Insecure Updates: DNS zones configured with insecure updates allow even anonymous users to perform DNS record changes. Shockingly, this is not an uncommon misconfiguration:

In this example below, we can see that an anonymous user with network level access can modify DNS records:

With these scenarios in mind, I began exploring how these configurations could be abused, particularly in Man-in-the-Middle (MitM) attacks. This experimentation ultimately led me to develop and release my own tool, KrbRelayEx, which demonstrates how Kerberos relaying and forwarding can exploit these vulnerabilities and lead to a complete Domain takeover!

If you’re interested in diving deeper into this topic, feel free to check out my GitHub repository: https://github.com/decoder-it/KrbRelayEx

That’s all 😉