Pharming: Redirecting Users Without a Click, and How to Prevent It

Phishing persuades a user to click a link to a malicious site. Pharming sends them there when they type the correct address themselves. The user does everything right — no link clicked, no attachment opened, the real domain typed by hand — and still arrives at the attacker's server. That is what makes it worth understanding separately.

The methods, roughly in order of how common they are

Router and gateway compromise is the leading route in practice. Home and small office routers are reachable from the internet with default credentials and unpatched firmware more often than anyone would like. An attacker who gains access changes the DHCP-assigned DNS server to one they control, and every device on that network resolves names through the attacker — no malware on any endpoint, and a factory reset of a laptop fixes nothing.

Hosts file modification is the simplest. Every operating system consults a local file mapping names to addresses before querying DNS, so malware with sufficient privilege adds entries for banking or corporate sites pointing at attacker servers. The lookup never leaves the machine, so no network control sees it.

DNS cache poisoning injects false records into a resolver's cache, affecting every user of that resolver until the entry expires. Source port randomization made the classic attack much harder, and DNSSEC validation removes it where deployed, but misconfigured and legacy resolvers remain vulnerable.

Registrar or authoritative server compromise is the most damaging and least common: the attacker changes the real records at source, so every resolver in the world gets the wrong answer, correctly. The defence is registrar-level protection — registry lock, multi-factor authentication on the registrar account, and monitoring your own records for unexpected changes, which organizations rarely do until it happens once.

Local network redirection through ARP spoofing achieves the same effect on a single segment without touching DNS at all.

Why the usual advice does not help

User training for phishing centres on checking the link before clicking and typing the address yourself instead. Against pharming, both of those are exactly what the victim did.

The address bar shows the correct domain because the domain is correct — only the resolution is wrong. Users cannot detect this by looking, which is why detection has to come from the certificate rather than from the name.

The control that does work

TLS certificate validation is the one that holds. The attacker's server cannot present a valid certificate for the real domain without obtaining one, so the browser warns. A user who stops at a certificate warning is protected regardless of how the redirection happened.

The implication for training is a useful one: teach people to treat certificate warnings as a stop rather than an obstacle, which is more durable advice than teaching them to inspect URLs.

Supporting controls strengthen it. HSTS prevents downgrade to plain HTTP and, with preloading, prevents the user clicking through the warning at all. Certificate transparency monitoring means a certificate improperly issued for your domain is publicly logged and detectable — the same monitoring used against brand impersonation.

DNSSEC validation at the resolver prevents accepting forged records, and encrypted DNS to a trusted resolver prevents on-path tampering with the queries themselves — though note the distinction discussed under DNS over HTTPS and DNS over TLS: encryption protects the channel while DNSSEC authenticates the records, and pharming needs the second.

Practical hardening

For the router vector: change default credentials, disable administration from the internet, keep firmware current, and check the configured DNS servers periodically. For managed environments, push DNS settings by policy so a compromised router's DHCP options are overridden.

For the hosts file: monitor it for changes as a file integrity check. It is small, it rarely changes legitimately, and an unexpected modification is a high-confidence indicator worth alerting on.

Force clients to use approved resolvers by blocking outbound DNS to anything else, which also gives you the query visibility described under DNS filtering — and a workstation resolving a banking domain to an unexpected address is exactly the kind of anomaly that surfaces there.

Exam angles

Define pharming as redirecting users to a malicious site without requiring them to click anything, by corrupting name resolution. Know hosts file modification, DNS cache poisoning, router or DHCP-assigned DNS compromise, and registrar compromise as the methods. Recognize that URL inspection does not detect it because the address is correct, and that TLS certificate validation is the control the user can act on. Name DNSSEC as the record authenticity control and HSTS as preventing click-through.