Why Host Order Matters for Remote Access and Pentesting

When accessing remote systems during pentesting, the way you specify host addresses – by IP or hostname, and in what order – can significantly influence the outcome. This affects everything from name resolution to authentication protocols and tool behavior. Two key areas to consider are:

How your hosts file mappings can override DNS and affect which IP a hostname resolves to.
How command-line tools (e.g., SSH, Evil-WinRM, CrackMapExec, rpcclient, smbclient) handle host specification, especially in Active Directory domain environments.

Below we explore why the ordering and format of host entries matter in these scenarios, how differences can lead to DNS resolution changes, Kerberos vs NTLM authentication, or even outright failures in domain reconnaissance—and also note how SPNEGO (a common negotiation mechanism for Kerberos) is similarly affected by host resolution across platforms.

Hosts File Order and Name Resolution

Operating systems consult the local hosts file (e.g. /etc/hosts on Linux or %SystemRoot%\System32\drivers\etc\hosts on Windows) before querying DNS for name resolution. This means any mappings in the hosts file will override DNS lookups for those hostnames. If a hostname is mapped to a specific IP in hosts, that is the IP your tools will use, regardless of what DNS says. This local override is useful for pentesting (e.g. to redirect a domain name to a chosen IP), but the order of entries in the hosts file is crucial when duplicates or multiple addresses are involved.

First Match Wins
If you have multiple entries for the same hostname, most systems will return the first IP listed. The hosts file can act like multiple DNS “A” records for a name, but client behavior varies. Some clients will just use the first address unless it fails, rather than cycling through. For example, if your hosts file contains:

10.0.0.5   fileserver.corp.local fileserver
10.0.0.8   fileserver.corp.local

a lookup of fileserver.corp.local will typically resolve to 10.0.0.5 (the first entry). The second IP (10.0.0.8) might never be used unless the application explicitly tries the next address on failure. Order matters – an outdated or incorrect first entry will cause misresolution.

Canonical vs Alias Names
On each line, the first hostname is treated as the canonical name and subsequent names are aliases. For instance:

192.168.1.10  app.example.com  appserver

Queries for either app.example.com or appserver will return 192.168.1.10. If you accidentally reverse these (putting an alias first), it might not behave as expected in some edge cases. Generally, ensure the primary hostname is listed immediately after the IP.

Override and Failover Effects
Because the hosts file bypasses DNS, it’s a double-edged sword. On one hand, it lets you reach hosts when DNS is unavailable or to fake a DNS entry (e.g. mapping a domain controller name to a specific IP in an isolated lab). On the other hand, a wrong hosts entry can lead your tools to contact the wrong machine. For example, if you map dc.corp.local to the wrong IP, your Kerberos authentication or LDAP queries could be going to a non-DC host, causing failures. Always double-check hosts file mappings during an engagement, and remove any stale entries. Typically, hosts file first, then DNS is the resolution order—so any entry in hosts will mask the real DNS record.
Practical Tip
In Active Directory labs, it’s common to add entries for the domain and domain controller to the hosts file (e.g. 10.0.0.5 corp.local and 10.0.0.5 dc.corp.local) so your tools can resolve the domain/DC without a DNS server. This works well, but ensure those entries are correct. If multiple DCs or IPs are involved, remember that the first listed IP for a given name will be used in most cases. If that IP is down, some tools might not automatically try the second. In short, the hosts file gives you control over name resolution – use it carefully. Yes, the hosts file does override DNS for standard resolution, so the order and accuracy of its entries can make or break your connections.

Effects on Pentesting Tools and Remote Access

Beyond just name-to-IP resolution, the way you specify the target host in your tools (IP vs hostname, domain name vs machine name, etc.) can affect authentication methods and enumeration results. This is especially true in Windows Active Directory environments, where choosing between an IP address and a hostname can mean the difference between using Kerberos or NTLM, and where targeting a Domain Controller vs. a member server can change what data you can retrieve.

Authentication: Kerberos vs NTLM (Hostname vs. IP Address)

When interacting with domain-joined Windows machines, how you specify the target can determine which authentication protocol is used. In Active Directory, Kerberos is the default authentication mechanism, but it’s tied to hostnames (SPNs), whereas NTLM might be used as a fallback, especially for IP-based connections.

Connecting by Hostname Enables Kerberos
If you use a hostname (especially the FQDN) to connect to a target, your client can request Kerberos tickets for that service. Kerberos relies on the Service Principal Name (SPN), which includes the host’s name. For example, accessing a share as \\fileserver.corp.local\Share or using a tool to connect to fileserver.corp.local allows Windows to attempt Kerberos authentication for fileserver$ in the AD realm.
Connecting by IP Forces NTLM
In contrast, if you use an IP address (e.g. \\10.0.0.20\C$ or point a tool at 10.0.0.20), the system will not even attempt Kerberos by default. Windows doesn’t know an SPN for an IP without special configuration, so it immediately falls back to NTLM. If the environment has disabled NTLM (a security hardening step), connecting by IP will fail altogether.
Why It Matters
Environments moving to “Kerberos only” will exhibit this behavior, leading to confusing failures if you use IP addresses. For instance, if you have a valid domain credential or even a Kerberos TGT loaded, and you try to use wmiexec.py or evil-winrm against an IP, you may get access denied because the tool is stuck attempting NTLM—which the server rejects. The fix would be to use the hostname so Kerberos is used instead.
Evil-WinRM Example – IP vs Hostname
Evil-WinRM is a WinRM shell often used for post-exploitation. Suppose you have credentials for a domain user on a domain-joined host:

evil-winrm -i 10.0.0.20 -u 'CORP\\alice' -p 'Password123'

Because the target is specified by IP, Evil-WinRM will attempt NTLM. If NTLM is disabled or fails, you’re out of luck. Now try:

evil-winrm -i appserver.corp.local -u 'CORP\\alice' -p 'Password123'

This time, the hostname indicates a domain host, so Windows will attempt Kerberos authentication. The same host and credentials can succeed or fail solely based on whether you used an IP or a name.

NetBIOS vs FQDN
It’s generally best to use the full domain name (FQDN). Using only a short hostname might not always trigger Kerberos, especially from non-domain machines. If DNS suffixes are set, it might still resolve, but the safest approach is to use the full FQDN to avoid ambiguity.
SPNEGO Perspective (Cross-Platform Note)
This IP-vs-FQDN dynamic applies broadly to SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). On Windows or Unix-like systems, SPNEGO first attempts Kerberos if it can build an SPN from a fully qualified name. If only an IP or short name is available, it usually fails to match the SPN and falls back to NTLM or another mechanism. The IBM SPNEGO documentation also confirms that local resolution sources (like /etc/hosts) override DNS, and that a properly resolved FQDN is essential for Kerberos. This cross-platform view aligns with the same principle: use a resolvable FQDN if you want Kerberos to succeed.

Enumeration: Targeting Domain Controllers vs. Member Servers

In Windows Active Directory environments, many enumeration tasks (listing users, groups, shares, etc.) yield different results depending on which host you query. Domain Controllers (DCs) are the authoritative source for domain-wide information, whereas member servers or workstations typically only have information about local accounts or their own shares.

Domain Controllers Hold the Keys
Certain data can only be obtained by querying a DC. For example, to list all domain users via SMB/RPC, you need to connect to a DC’s SAMR service or LDAP. A tool like rpcclient can enumerate domain users with the enumdomusers command, but only if you’re connected to a domain controller. Pointing rpcclient at a member server will return only local accounts.
Local vs Domain Authentication Effects
When you use domain credentials on a member server, that server forwards your authentication to a DC for verification, but it only grants you local permissions. If you’re not an admin on that host, certain queries or shares might be off-limits—even though your domain credentials are valid. In contrast, a DC will at least let you query domain-wide info (users, groups, etc.) that’s readable by authenticated users. Always remember to test credentials on a DC to confirm domain validity before concluding they’re invalid.
CrackMapExec Example – Share Enumeration
CrackMapExec (CME) can take a list of targets (IPs/hostnames) and perform actions like share enumeration. If one of your targets is a DC, CME will enumerate domain-specific shares like SYSVOL and NETLOGON—which are typically readable by any domain user. If the DC is offline or excluded, you’ll miss those shares. This underscores the importance of including the DC in your enumeration steps.
Credential Validity and Order
CME or similar tools may show early failures if the first host is unreachable or if your user lacks local rights, but the same credentials might succeed on a DC. A best practice is to target the domain controller early when testing credentials.
Domain Enumeration Examples
Other tools like smbclient, ldapsearch, or Impacket scripts (GetADUsers.py, GetNPUsers.py) also require the right host—usually a DC—to retrieve full domain data. If your DNS/hosts mapping isn’t correctly pointing corp.local to the DC’s IP, these tools can fail to find the LDAP service. Again, be mindful of how you’re specifying hosts and ensure you’re hitting the DC for domain-wide queries.

Putting It All Together

In a domain pentest scenario, you often juggle both the hosts file and tool parameters. A slight misstep—like using an IP (breaking Kerberos) or mapping the domain name to a non-DC—can derail your attempts. Likewise, specifying the wrong order in your hosts file can silently override real DNS and lead your tools astray.

In summary, the order and format of host specifications matter because they determine where and how your tools connect:

A hosts file entry can short-circuit DNS and send your tool to a specific IP – great for control, but potentially harmful if wrong. Order those entries carefully and keep them updated.
The decision to use a hostname or an IP will control whether Kerberos or NTLM is used for authentication on Windows. Use hostnames (preferably FQDN) to leverage Kerberos (especially in AD).
When dealing with multiple targets, especially in AD, include the domain controllers and consider querying them first. They hold domain-wide data and will validate credentials directly.

By being mindful of these nuances, you can avoid common pitfalls like authentication failures that aren’t really credential problems, or missing out on domain-wide data that was readily available if only you queried the correct host. In pentesting, details matter – and something as simple as the order of IPs and hostnames can be the difference between a successful exploit and a frustrating misfire.

References

SPNEGO Algorithm to Resolve Host Names – IBM Documentation
Confirms that name resolution (hosts file first, then DNS) applies to SPNEGO/Kerberos. Stresses the requirement for a fully qualified domain name (FQDN) to match an SPN for Kerberos.
Security Stack Exchange – Kerberos vs IP – “Kerberos golden ticket works with DNS only – access denied with IP”
Polynomial’s answer reiterates Windows will not attempt Kerberos with IP addresses by default. Advises using FQDN or explicit SPN.
Stack Overflow – Hosts File Overrides DNS – .NET question on SQL connection + hosts override
Confirms that the hosts file takes precedence over DNS, which can break or fix name resolution unexpectedly.
SuperUser – Multiple Entries in Hosts File – “Can a host file DNS entry point to multiple IP addresses?”
Discusses multiple IPs for the same hostname. Typically, the client will pick the first IP, so order matters.
Hausec Blog – AD Enumeration with CrackMapExec – Penetration Testing Active Directory, Part II
Demonstrates CME usage for share enumeration; includes hitting the DC to see domain-specific shares like SYSVOL.
Hacking Articles – RPCClient – Active Directory Enumeration: RPCClient
Shows how querying a domain controller with rpcclient can enumerate domain users. Targeting a member server shows only local accounts.