The way agency-managed sites get DNS-hijacked in practice has almost nothing to do with the BGP-level attacks that get written up in security journals. It's far more boring and far more common.
This post lists the actual attack patterns we've seen in agency portfolios and what catches each one in practice.
What "DNS hijack" actually means in the agency context
In most security writing, "DNS hijacking" refers to BGP-level rerouting of DNS traffic — country-scale attacks like the famous 2018 MyEtherWallet incident. That's not what happens to your clients.
The agency-scale failure modes are:
- Registrar account compromise. Attacker gets into the client's GoDaddy / Namecheap / Cloudflare Registrar account (phished credentials, no 2FA) and changes nameservers or specific records.
- Email-driven social engineering at the registrar. Attacker convinces support to "recover" account access via a forged ID.
- Insider mistake or junior dev. A staff member changes records intending to point at staging and the production site goes dark for an hour.
- Expired domain repurposing. Client lets a secondary domain expire, attacker buys it the day it drops, points it at malware.
- Subdomain takeover. Old CNAME points at an Amazon S3 bucket or Heroku app that's been deleted; attacker claims that resource and serves content from your client's subdomain.
Numbers 3-5 are the most common in real agency portfolios. 1 and 2 are rarer but devastating.
What changes during each attack
Pattern 1 — Registrar account compromise
Attacker logs in, changes the NS records at the registrar (now pointing at attacker-controlled DNS), and within minutes the entire domain redirects to whatever they want. Mail goes to their inbox, traffic to their pages.
What you see externally:
- All NS records change at once
- A records change (often to a different ASN entirely)
- MX records change to attacker mail server
- TTLs are often suspiciously low (the attacker wants flexibility)
Pattern 2 — Registrar social engineering
Similar to 1 from the DNS observer's point of view — NS or A records change. The difference is forensic (audit logs at the registrar show "account recovery via support ticket" not "logged in normally") but you can't see that externally. Same external signature as 1.
Pattern 3 — Insider mistake
Usually one record changes. A record points at the staging server. Or someone flipped the AAAA record to test IPv6 and forgot. Often resolved within hours when someone notices the production site is broken, but the alert is what gets you the visibility.
External signature: a single record changed, others normal.
Pattern 4 — Expired domain repurposed
The client's oldcompany.com (which they used 2015-2020) expired. Three weeks after expiry, registrant changed. New owner points it at affiliate spam pages or worse. Anyone who had bookmarks, old email signatures, or third-party integrations referencing that domain now resolves to attacker content.
External signature: NS records change, then everything changes — A, MX, sometimes TXT. The WHOIS registrant field is the giveaway.
Pattern 5 — Subdomain takeover
The client's marketing.client.com was a CNAME at client.s3.amazonaws.com from a 2022 campaign. The bucket was deleted in 2024. The CNAME stayed. Six months later, an attacker registers client.s3.amazonaws.com (S3 names are first-come-first-served) and serves their content from your client's subdomain.
External signature: the CNAME itself didn't change, but the resolved IP did (because the target it points at is now under attacker control). HTTP probe returns different content than before.
What probes catch each pattern
| Pattern | Catches it | |---|---| | Registrar account compromise | NS/A/MX drift detection on a daily cron | | Registrar social engineering | Same as above (external signature is identical) | | Insider mistake | Single-record drift alert; HTTP content-hash mismatch | | Expired domain repurposed | WHOIS / RDAP expiry tracking + registrant change | | Subdomain takeover | HTTP fetch comparing body hash; certificate validation (often the new cert doesn't match) |
The single highest-impact monitoring upgrade for any agency portfolio is daily DNS snapshot with diff detection. Doesn't matter what tool — could be Pleenx, could be Oh Dear, could be a homegrown cron with dig. The mechanism: take a full DNS snapshot per domain per day, compare against yesterday's, alert on any change.
What "daily" actually means and why faster doesn't help
A common question: "Shouldn't we monitor DNS more often than daily? An hour of malware is bad."
Two answers:
-
DNS changes have TTL. Most records have 1-24 hour TTLs. Caching layers between you and the authoritative nameservers may serve stale data for that window. Polling every 5 minutes doesn't help because you'll see stale data for several hours regardless.
-
Attacker patience. Most agency-scale DNS attacks aren't covert. The attacker changes records and runs their thing for hours or days. Daily detection catches 95%+ of real cases. Hourly catches 99%. The marginal effort to go from daily → hourly is significant; you're better off using that effort on broader coverage.
If you want sub-hour detection on the most critical domains: do daily DNS + every-15-minute HTTP content-hash + alert when content changes unexpectedly. The HTTP probe catches the consequence of a DNS hijack (different content served) faster than the DNS probe catches the cause.
Practical setup for an agency portfolio
For each client domain, set up a daily probe doing:
- Resolve all five record types (A, AAAA, MX, NS, TXT) via DNS query
- Compare against last known good snapshot from yesterday
- Categorize the diff:
- No change → log, exit
- Added/removed a record → warn-level alert with context
- Wholesale NS change → critical alert, page on-call
- Single A or MX flipped → warn-level alert, expect human to validate
- WHOIS / RDAP check:
- Days remaining until expiry
- Registrant name (alert if changed)
- Nameservers reported by registry (cross-check with NS records)
- HTTP content-hash:
- Fetch the homepage
- SHA-256 the normalized body
- Compare to last known good
When all three (DNS, WHOIS, HTTP) align with yesterday's snapshot — silent. When any one differs — alert with the specific diff.
What we use at Pleenx
Same flow as above, run from fra1 daily at 08:00 UTC, alerts dispatched within ~3 minutes of detection to whatever channels the agency has wired (email, Slack, Discord, Telegram, webhooks). When a diff is detected, the alert email includes:
- What changed (specific records, before/after)
- WHOIS context (days remaining, registrant)
- A link to the full DNS history for that domain on the dashboard
The point isn't that this is magic; it's that doing this manually for 50+ client domains is tedious enough that nobody does it, and "we'll just check when something seems wrong" means catching attacks 4-72 hours too late.
Subdomain takeover specifically — the case for content-hash
Patterns 1-4 above are caught by DNS+WHOIS drift detection. Pattern 5 — subdomain takeover — is a special case where the DNS record doesn't change but the resolved content does.
The detection method is:
- Fetch the homepage of every subdomain you control
- Hash the body content with SHA-256 after normalizing (strip dynamic timestamps, query strings, etc.)
- Save hash + first 200 bytes + final URL
- Alert when the hash changes by more than a small threshold and the first 200 bytes look completely different (catches "page redesigned" vs "page replaced with attacker content")
This is the "defacement detection" probe. Pleenx ships it. Most uptime tools don't, because content-changing-legitimately is so common on dynamic sites that the false-positive rate is hard to manage. Solution is to scope the probe to subdomains you know are static or under specific change control.
What to ask a client when you onboard
Before you set up DNS hijack detection, learn:
- Where is the domain registered? (GoDaddy, Namecheap, Cloudflare Registrar, etc.)
- Who has access to the registrar account? Are there 2FA-required users?
- When was the registrar password last rotated?
- What secondary domains do they own? (These often expire forgotten.)
- What subdomains do they have? Active vs deleted-but-DNS-still-there?
The answer to that last question is usually "I don't know, the previous agency set up half of them." Your value-add is mapping that out and watching it.
TL;DR
- DNS hijacks at agency scale are usually boring: stolen registrar logins, junior dev mistakes, expired domains, subdomain takeovers.
- The single highest-impact detection upgrade is daily DNS snapshot diff + WHOIS expiry tracking + HTTP content-hash for high-trust subdomains.
- Daily is enough. Hourly DNS doesn't help much; faster HTTP content-hash does.
- Externally: monitor A, AAAA, MX, NS, TXT records, WHOIS registrant, and HTTP body hash. Alert on any unexpected diff.
- Don't manually
dig50 client domains every day. Cron it or use a monitoring tool that does this out of the box.