Attackers can tamper with /etc/hosts to redirect a hostname to a malicious local or internal IP address. That can be used for phishing, traffic interception or bypassing normal name resolution during compromise. Defenders should protect the file from unauthorised edits and check it when investigating unexpected connection failures.
How /etc/hosts is abused during compromise
Attackers use /etc/hosts because it can override normal DNS lookups on a Unix-like system. If they can edit it, they can make a legitimate hostname resolve to a different address under their control, which changes where the victim connects without changing the hostname the user sees.
That makes the file useful for redirecting email, update, proxy, internal portal, or identity endpoints to a malicious host, or for forcing traffic to an internal address that the attacker can reach more easily. In practice, the abuse is often quiet because the application still believes it is talking to the expected name.
The same technique can also support persistence or interference after an initial compromise. If a host keeps resolving key services to the wrong destination, security tools may see the right hostname in logs while the endpoint actually connects elsewhere, which complicates triage and can delay containment.
What the attacker gains from name-resolution tampering
The main value is control over destination selection at the endpoint layer. That can enable phishing by presenting a familiar name while serving a fake site, traffic interception by steering requests through a malicious listener, or operational disruption by breaking normal resolution for selected services.
It is especially useful when the attacker wants to stay local to the compromised machine rather than poison DNS globally. A modified hosts file can affect only one system, one user context, or one set of tools, which makes the change narrower and often harder to spot than a network-wide DNS attack.
A practical example is bypassing normal name resolution during compromise. If the attacker knows a workstation regularly reaches a cloud service or internal control plane, a hosts entry can redirect that request to a local sinkhole, an attacker-owned listener, or another reachable internal IP. MITRE ATT&CK Enterprise Matrix is useful here because it helps defenders think about destination redirection alongside credential access and lateral movement.
How defenders should check and harden against it
Defenders should treat unexpected connection failures, certificate warnings, or “wrong site” behaviour as possible indicators of local name-resolution tampering, not just DNS trouble. A quick comparison of the endpoint’s /etc/hosts file against a known-good baseline can reveal entries that should not be there.
Protection is mainly about limiting who can edit the file and detecting changes quickly. On managed systems that means strict file permissions, privileged access only when needed, integrity monitoring, and configuration management that flags unauthorised edits before they affect users. NIST Cybersecurity Framework 2.0 fits well because the issue spans protect, detect, respond, and recover activities.
When the investigation suggests the machine has been used for more than simple redirection, defenders should widen the check. A tampered hosts file can be one step in a larger compromise, so review local admin activity, browser and proxy settings, scheduled tasks, startup items, and any recently accessed secrets or sessions that might have been exposed through redirected traffic. CISA cyber threat advisories remain a good source for current compromise patterns and response guidance.
Risk and Threat Considerations
Hosts file tampering is low-noise but high-value because it operates below the application layer and can subvert trust in a hostname without breaking the user’s workflow. The risk is greatest when the affected machine is used for admin access, software updates, SSO access, or any workflow where the endpoint trusts local resolution more than external verification.
Failure mechanism: The attacker needs write access to the host or a process with sufficient privileges to modify name resolution behaviour. Once that happens, the system can be silently redirected to malicious infrastructure, and the compromise may persist until the file is reviewed or restored.
Impact: The result can be phishing, interception, service disruption, or credential capture, especially if the redirected service accepts reused passwords, session tokens, or other sensitive secrets. In incident response, this also creates misleading evidence because logs may show the expected hostname even when the connection target was altered locally.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1565 — Data Manipulation | Hosts-file tampering is local data manipulation used to redirect name resolution. |
| Recommendation — Map suspicious hosts-file edits to T1565 and hunt for related persistence or redirection activity. | ||
| NIST CSF 2.0 | DE.CM-01 — Security Continuous Monitoring | Unexpected resolution changes are detectable host integrity events. |
| PR.DS-01 — Data-at-Rest Is Protected | Restricting modification of the hosts file protects a local control file that shapes traffic routing. | |
| Recommendation — Monitor critical host files for unauthorised changes and alert on drift quickly. Apply file integrity and permission controls to prevent unauthorised hosts-file edits. | ||
| CIS Controls v8 | CIS-5 — Account Management | Hosts-file abuse often follows privilege misuse or compromised administrative access. |
| Recommendation — Restrict and review privileged access that can modify local resolution files. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Limiting unnecessary local change paths reduces the chance of malicious resolution tampering. |
| Recommendation — Remove unnecessary write access to system files and enforce least functionality. | ||
Practitioner Guidance
What to verify: Check the file whenever a host reaches the wrong destination, fails certificate validation unexpectedly, or cannot resolve a service that other systems can reach. Validate both the file content and the local permissions, because a clean file with weak permissions can be altered again immediately.
Decision rule: If the hosts file contains entries for production, identity, update, or security-related services, treat that as a containment issue first and an admin hygiene issue second. Restore the expected mappings, review adjacent persistence artefacts, and only then decide whether the change was malicious or accidental.
What practitioners underestimate: A hosts-file change often looks like a simple connectivity problem, but it can be the control point that makes downstream compromise possible. The safest operating assumption is that unexpected local name resolution deserves the same scrutiny as proxy tampering or DNS manipulation.
Practitioner takeaway: The key question is not just whether /etc/hosts was edited, but whether that edit changed which system the endpoint trusted. If it did, assume the attacker was shaping traffic flow, not merely changing a label.