Pharming is an attack that redirects users to a fraudulent website even when they type the correct address, usually by tampering with name resolution on the device, the router or the DNS service. Phishing needs the victim to click a bad link. Pharming does not. Certificate checks and phishing resistant sign-in blunt it.
How do the definitions read?
NIST's glossary gives two definitions. One, from SP 800-44, is "using technical means to redirect users into accessing a fake Web site masquerading as a legitimate one and divulging personal information." The other, from the digital identity guidelines, describes an attack in which the subscriber is redirected to a fraudulent website, typically a fraudulent verifier or relying party in an authentication setting, which may lead the user to reveal a password, download harmful software or contribute to a fraud.
How is the redirection done?
Every web visit starts with a name lookup. The attacker needs to change the answer. Common places:
- The device. Malware edits the local hosts file or changes the configured DNS server.
- The router. Home and office routers with weak admin passwords or old firmware can be set to hand out a hostile DNS server.
- The DNS service. Compromise or poisoning of a resolver, or of a domain's registrar account, changes answers for many users at once.
RFC 4033 explains why the underlying problem exists. Classic DNS gives no authentication or integrity to its data, so a resolver cannot tell a forged answer from a true one. DNS Security Extensions add data origin authentication and data integrity to the system, though they do not provide confidentiality.
What stops it at the browser?
TLS. A fake site at the right address still has to present a certificate valid for that name, issued by an authority the browser trusts. RFC 8446 describes how the server proves its identity during the handshake. Pharming only works smoothly if the attacker can also obtain such a certificate or if the user ignores a certificate warning. That is why training people to stop and report certificate warnings matters.
A constructed example
A small accounting firm's office router still uses its factory admin password. An attacker changes its DNS setting to a server they control. Staff typing the bank's address are sent to a copy of the bank's login page. If staff proceed past a certificate warning, they hand over credentials. If they stop, the attack fails. If they use passkeys or a hardware key bound to the real site, there is nothing for the fake page to capture, because the authenticator will not respond to the wrong domain.
How to check or apply this
- Change default router and gateway passwords, update firmware, and turn off remote administration.
- Check the DNS server settings on routers and devices, and use a resolver you trust.
- Turn on DNSSEC validation in your resolvers, and sign your own zones where your provider supports it.
- Lock your domain at the registrar and protect the account with phishing resistant MFA.
- Use passkeys or security keys for important logins, since they are bound to the real site.
- Teach staff that a certificate warning on a known site is a stop sign.
- Monitor for unexpected changes to your own DNS records.
- Run endpoint protection that watches the hosts file and proxy settings.
Quick check
Does HTTPS stop pharming?
It stops most of it, since the fake site cannot present a valid certificate for your name. It fails if users click through warnings or the attacker gets a certificate.
Is pharming a type of phishing?
They are related fraud techniques, but pharming redirects traffic without a lure, while phishing tries to persuade the user to act.
Sources
- NIST CSRC Glossary, Pharming
- RFC 4033, DNS Security Introduction and Requirements
- RFC 8446, The Transport Layer Security Protocol Version 1.3
Last reviewed: 18 October 2026.
