glossary-pharming

—\ntitle: "Pharming: Definition, How It Works, and How to Recognize It"\nmeta_title: "Pharming Attack: Definition, Examples, and Detection"\nmeta_description: "Pharming is a silent redirect to fake sites via DNS or local settings—even when the URL is correct. Learn how to spot and stop it."\ndate: 2026-05-16\nupdated: 2026-06-22\nkeywords:\n [\n pharming,\n DNS poisoning,\n DNS hijacking,\n man-in-the-middle,\n malicious redirection,\n credential theft,\n HTTPS spoofing,\n hosts file attack,\n domain spoofing,\n ]\ntweet_draft: "Pharming = silent redirection to a fake site even when you type the correct URL—often via DNS poisoning or router compromise. Learn how it works, where it shows up, and what to check. #infosec #DNS"\nlinkedin_draft: "Pharming is one of the more deceptive web threats: users type the correct address but still land on a counterfeit site. In this short guide, I break down how pharming works (DNS poisoning, rogue resolvers, router hijacks, hosts file edits), where you’ll encounter it in real environments, and the key related terms security teams should align on."\ntopic: "pharming"\nintent: "howto"\n—\n\n# Pharming: Definition, How It Works, and How to Recognize It\n\nPharming is a stealthy redirect attack that sends users to a fake site even when they enter the correct web address, usually by tampering with DNS, router settings, or local name resolution. It matters because the page can look legitimate at a glance, making pharming a practical way to steal credentials, payment details, or session access before a user realizes anything is wrong.\n\n> TL;DR\n>\n> - Pharming redirects you to a fraudulent site even when you enter the correct URL, usually by tampering with DNS or local name resolution.\n> - Anyone using compromised DNS (home routers, ISP/public resolvers, corporate DNS) or endpoints with altered hosts/proxy settings can be affected—verify DNS, TLS, and resolver configuration.\n> - Treat as urgent when users report “the right URL but wrong site,” certificate warnings, or sudden credential prompts.\n\nPharming is a malicious redirection attack that sends users to a fake website even when they type the right domain—most often through DNS poisoning or DNS hijacking. Because pharming targets the “name-to-address” step behind the scenes, it can quietly enable credential theft at scale (for example, redirecting users from a real login page to an attacker-controlled clone).\n\nFor broader context on DNS-driven redirection and how it fits into modern compromise chains, see: what is a supply chain attack.\n\n## Definition\n\nPharming is an attack that silently redirects users from a legitimate website to a malicious look‑alike—often even when the user types the correct domain name. It commonly works by compromising DNS or local name resolution so the domain resolves to an attacker-controlled IP address.\n\n## How pharming works\n\nPharming is fundamentally a name-to-address manipulation problem: the victim asks “Where is bank.example?” and receives a wrong answer that points to infrastructure the attacker controls.\n\n### 1) DNS poisoning / DNS cache poisoning\n\nAttackers attempt to corrupt DNS responses so that a resolver caches a malicious mapping (e.g., login.example.com -> 203.0.113.50). Once cached, many users who rely on that resolver will be redirected until the bad record expires or is flushed.\n\nWhere it happens:\n\n- Vulnerable or misconfigured recursive resolvers\n- Network devices performing DNS interception (“DNS hijack” behavior)\n- Compromised internal DNS infrastructure\n\nWhy it’s effective: users still see the correct URL in the address bar, because the browser requested the right hostname; the underlying resolution is wrong.\n\n### 2) DNS hijacking (resolver or registration layer)\n\nPharming can also occur without “poisoning” caches—by changing authoritative answers or routing users to a rogue resolver.\n\nCommon routes:\n\n- Compromised router/DHCP: attacker changes DHCP options so clients use attacker DNS servers.\n- Compromised ISP/local network: attacker controls the network path and forces DNS to their resolver.\n- Registrar/account compromise: attacker changes nameservers or DNS records at the domain’s DNS provider (this is more accurately domain/DNS takeover, but results can look like pharming to end users).\n\n### 3) Hosts file manipulation (endpoint-level pharming)\n\nOn individual endpoints, malware (or an attacker with local admin rights) can modify the OS hosts file so that a domain resolves to a specific IP.\n\nTypical targets are high-value domains:\n\n- Banking/fintech portals\n- Email and SSO login pages\n- Popular SaaS apps (M365, Google, Salesforce)\n- Crypto exchanges, payment processors\n\nThis bypasses DNS entirely for the affected host.\n\n### 4) Proxy/WPAD and captive portal abuse\n\nSome “pharming-like” redirections happen through:\n\n- Malicious proxy settings pushed via malware, group policy abuse, or browser policy\n- WPAD (Web Proxy Auto-Discovery) manipulation on local networks\n- Evil twin Wi‑Fi / captive portal trickery to steer traffic\n\nThese aren’t strictly DNS pharming, but the user experience is similar: correct URL, wrong destination.\n\n### 5) The HTTPS factor: why certificate warnings matter\n\nHistorically, pharming was devastating because HTTP sites provided no cryptographic identity. Today, TLS/HTTPS is a major hurdle—but not a guarantee.\n\n- If the attacker cannot obtain a valid certificate for the target domain, browsers should show a certificate warning. Users who click through are still at risk.\n- Attackers can still succeed by:\n - Using look-alike domains (paypaI.com with capital I) with valid certs (more “typosquatting” than pharming)\n - Compromising a certificate issuance path in the victim environment (e.g., installing a malicious root CA on endpoints to enable TLS interception)\n - Targeting services that users access via links and don’t carefully validate (e.g., “Sign in to your account” flows)\n\nIn practice, a large share of successful “pharming” incidents combine DNS manipulation with credential phishing and session capture.\n\n## How to recognize pharming (user and admin signals)\n\n### User-visible symptoms\n\nCommon signs the helpdesk or security team will hear about:\n\n- Certificate warnings on previously trusted sites\n- Unexpected login prompts or “re-authenticate” loops\n- Branding slightly off (fonts, spacing, missing MFA step)\n- URL looks correct, but password manager refuses to autofill (domain mismatch or certificate change)\n\nTip: a strong password manager can reduce damage from credential theft by refusing to fill on the wrong origin. If your team is standardizing, 1Password is a common option for business use: Try 1Password →.\n\n### Admin/IT signals\n\n- Multiple users report “right URL, wrong site” at the same time\n- Sudden resolver/DHCP setting changes\n- Spikes in DNS failures (NXDOMAIN/SERVFAIL) or unusual forwarders\n- Endpoints with new proxy/WPAD settings or a newly installed root CA\n\n## Technical notes: fast triage checks\n\n### Check what DNS thinks the domain is\n\nUse multiple resolvers to compare answers:\n\nbash\n# Query your current resolver\nnslookup login.example.com\n\n# Compare against a known public resolver\ndig @1.1.1.1 login.example.com A +short\ndig @8.8.8.8 login.example.com A +short\n\n# Show full resolution path and TTL\ndig login.example.com A +noall +answer\n\n\nRed flags:\n\n- Different IPs returned than expected (especially if geolocation/ASN is suspicious)\n- Very long TTLs on records that should be short (varies by org)\n- Sudden changes without a corresponding change request\n\n### Verify the resolver configured on an endpoint\n\nbash\n# Windows\nipconfig /all\n\n# macOS\nscutil --dns | head -n 80\n\n# Linux (systemd-resolved)\nresolvectl status\n\n\nLook for:\n\n- DNS servers you don’t recognize\n- DNS search domains that shouldn’t be present\n- “DNS over HTTPS” (DoH) policy changes you didn’t deploy\n\n### Detect local hosts-file overrides\n\nbash\n# Windows\ntype C:\\Windows\\System32\\drivers\\etc\\hosts\n\n# macOS / Linux\ncat /etc/hosts\n\n\nAny entries mapping well-known domains to fixed IPs warrant investigation.\n\n## Where you’ll encounter pharming most often\n\n### 1) Home and small office networks (router compromise)\n\nSMBs and remote workers are frequent targets because home routers:\n\n- Run outdated firmware\n- Have weak admin passwords\n- Expose management interfaces unintentionally\n- Use default DNS settings provided by ISP or attacker-changed DHCP settings\n\nA compromised router can silently set DNS to attacker-controlled servers for every device on the network.\n\n### 2) Public Wi‑Fi and “free internet” hotspots\n\nIn cafés, hotels, airports, and conferences, users may connect to networks where:\n\n- DNS is intercepted or redirected\n- Captive portals are abused\n- Rogue access points imitate legitimate SSIDs\n\nIf employees travel frequently, a reputable VPN can reduce exposure to certain network-layer attacks (though it doesn’t “fix” DNS compromise everywhere). Examples used by many teams include NordVPN: Check NordVPN pricing → or Surfshark: Try Proton VPN →.\n\n### 3) Corporate networks with split-horizon DNS and legacy resolvers\n\nEnterprises often rely on internal DNS for:\n\n- SSO, internal apps, VPN endpoints\n- Split DNS for cloud services\n- Security controls like DNS filtering\n\nIf an attacker compromises internal DNS or gains access to network management systems, pharming can become a high-impact lateral movement and credential theft technique.\n\n## What to review in logs and telemetry\n\n### DNS server / resolver logs (internal)\n\nLook for:\n\n- Spikes in NXDOMAIN or SERVFAIL\n- Unusual external forwarding destinations\n- Changes to forwarding settings\n- Unexpected zone transfers or dynamic updates (if enabled)\n\nIf you have query logs, investigate high-risk domains and sudden shifts in resolved IPs.\n\n### Network/security telemetry\n\n- DNS queries to rare/unknown resolvers (clients bypassing policy)\n- Router/DHCP config changes\n- New admin logins to network devices from unusual IPs\n- TLS inspection/root certificate installation events (endpoint management logs)\n\nEndpoint security can also help catch the malware that changes hosts/proxy settings. If you’re evaluating options, you can compare business endpoint coverage here: best antivirus for windows business endpoints 2026. Malwarebytes is another commonly used toolset in this space: Get Malwarebytes →.\n\n## Related terms (quick alignment)\n\n- Phishing: Social engineering that tricks users into clicking or submitting credentials. Pharming often enables phishing by making the fake site appear when the user requests the real one.\n- DNS poisoning / DNS cache poisoning: Corrupting cached DNS entries so resolvers return attacker-chosen IPs.\n- DNS hijacking: Redirecting DNS resolution by controlling resolvers, network paths, router/DHCP options, or authoritative DNS settings.\n- Typosquatting / look-alike domains: Registering similar domains (e.g., micros0ft.com) to catch mistakes; not pharming because the user goes to the wrong domain, not redirected from the right one.\n- Man-in-the-middle (MITM): Intercepting traffic between client and server. Pharming can be part of a MITM chain, but pharming focuses on where the client connects.\n- Evil twin Wi‑Fi: A rogue access point mimicking a legitimate network to capture traffic or manipulate DNS/proxy settings.\n- HTTPS/TLS interception: Installing a trusted root CA on a device to decrypt and re-encrypt traffic. This can make pharming harder to detect because certificate warnings may not appear.\n- Domain takeover / DNS record compromise: Attacker gains control over domain records or registrar access. Users experience redirection similar to pharming, but the control point is the authoritative DNS layer.\n\n—\n\nThis article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.\n