Malicious WordPress redirect with zero infected files: how to diagnose DNS hijack in 5 minutes before wiping the server
Published on April 24, 2026
The symptom: redirect to an unknown page
The call came in urgently: a scientific online journal was redirecting visitors to a suspicious page. The behavior was consistent — any access to the domain resulted in an automatic redirect.
The first instinct in such cases is to go straight to the WordPress server: check for modified PHP files, plugins with injected malicious code, illegitimately created admins. It is the obvious path — and exactly the wrong one when the attack vector is DNS.
Before touching the server, check the DNS. A redirect that happens before WordPress processes any request is rarely caused by WordPress.
The 5-minute diagnosis
The diagnostic methodology for a suspicious redirect follows a specific sequence, from the outermost layer inward. Starting at the server is wasting time:
Step 1: resolve the current DNS
# Check which IP the domain is pointing to
dig journal.example.org A +short
# Also check via public resolver (ensures no local cache interference)
dig @8.8.8.8 journal.example.org A +short
dig @1.1.1.1 journal.example.org A +shortIn this case, dig returned two IPs: <IP_atacante_1> and <IP_atacante_2>. The correct server IP was <IP_legitimo>. The first two IPs were not from the server where WordPress was hosted.
IPs returned by DNS: <IP_atacante_1>, <IP_atacante_2>
Real WordPress server IP: <IP_legitimo>
Immediate conclusion: the domain was pointing to a completely different server.
Step 2: follow the redirect with verbose output
# Follow the complete redirect and inspect each step
curl -sv -L https://journal.example.org/ 2>&1 | head -60The response was revealing:
* Trying <IP_atacante_1>:443...
* Connected to journal.example.org (<IP_atacante_1>) port 443
* SSL certificate verify ok
< HTTP/1.1 200 OK
< Content-Type: text/html
<!DOCTYPE html><html><head>
<script>window.onload=function(){window.location.href="/lander"}</script>
</head></html>A minimal HTML page with a JavaScript snippet that redirects to /lander immediately on load. Zero legitimate content. The server receiving the requests served exclusively this redirect.
Step 3: inspect the SSL certificate
# Check the certificate issuer and issuance date
curl -sv https://journal.example.org/ 2>&1 | grep -E "issuer|expire|start|subject"The certificate revealed the most important detail:
CN: journal.example.org (correct — issued for the target domain)
Issuer: GoDaddy TLS Intermediate CA DV - R1v1 — not the Let's Encrypt standard of the real server
Issuance date: hours before the incident was discovered
A valid SSL certificate issued by the registrar itself, on the day of the incident, is direct forensic evidence: the attacker controlled the DNS well enough to issue a certificate — and knew HTTPS was needed to make the redirect look legitimate.
Step 4: check the nameservers
# Check the domain's authoritative nameservers
dig journal.example.org NS +short
# Result: ns71.domaincontrol.com, ns72.domaincontrol.comdomaincontrol.com is GoDaddy's DNS infrastructure. The domain was using GoDaddy nameservers — and the client's GoDaddy account was the point of compromise.
The final diagnosis: DNS hijack via registrar
With these four data points, the picture was complete. There was no WordPress hack. The attack was:
1. Unauthorized access to the client's GoDaddy account (compromised password or absence of 2FA).
2. Modification of the domain's A records to IPs of a server controlled by the attacker.
3. SSL certificate issuance via GoDaddy for the domain — possible because the attacker controlled the DNS and completed DV validation.
4. Attacker's server serving a page with a JavaScript redirect to /lander.
The original WordPress server remained intact. No file was modified. No plugin was compromised. No admin was created. If we had followed the conventional 'clean WordPress' path, we would have wasted hours — and the site would have remained down while the DNS continued pointing to the wrong server.
Consolidated evidence
DNS A record: <IP_atacante_1>, <IP_atacante_2> — IPs unrelated to the real server
Real server IP: <IP_legitimo> — did not match the DNS
Certificate issuer: GoDaddy (not Let's Encrypt) — issued by the attacker using DNS control
Issuance date: on the day of the incident — temporal indicator of the attack
Page content: minimal HTML with window.location.href to /lander
Nameservers: GoDaddy — modification made from within the registrar account
Recovery actions (client)
Recovery followed a specific sequence — order matters:
1. Change the GoDaddy account password immediately. Before any other action — to prevent the attacker from redoing the change.
2. Enable 2FA on the GoDaddy account. Two-factor authentication via authenticator app (not SMS, which can be intercepted via SIM swap).
3. Revert the domain's A records to the correct IP. With a low TTL (60s) for fast propagation.
4. Check other domains in the same GoDaddy account. If one account was compromised, other domains managed in the same account may have been altered.
5. Check the DNS change history in GoDaddy. To identify when the attack occurred and whether other records were altered (MX, TXT, CNAME).
6. Report the incident to GoDaddy. For investigation of the unauthorized access and potential revocation of the certificate issued by the attacker.
Prevention: two measures worth more than any WAF
2FA at the registrar — not optional
Access to the registrar is the highest level of access that exists for a domain. Whoever controls the registrar controls the DNS. Whoever controls the DNS controls everything under that domain — including the ability to issue valid SSL certificates.
2FA via authenticator app (Google Authenticator, Authy) is the minimum. Registrars like GoDaddy also offer email notification options for DNS changes — enabling that notification creates an immediate alert if DNS is changed without authorization.
Registry Lock: ICANN-level protection
For critical domains — domains that generate direct revenue, identify an organization, or are difficult to recover if compromised — Registry Lock exists. It is a lock at the ICANN registry level that prevents any transfer or NS change without a manual verification process with the registrar.
# Check the lock status of a domain
whois journal.example.org | grep -i "status"
# Outputs indicating active protection:
# clientDeleteProhibited
# clientTransferProhibited
# clientUpdateProhibited
# serverDeleteProhibited ← Registry Lock (ICANN level)
# serverTransferProhibited ← Registry Lock (ICANN level)
# serverUpdateProhibited ← Registry Lock (ICANN level)Statuses with the client prefix are set by the registrar and can be changed by the client account. Statuses with the server prefix are set by the registry (ICANN) and require a manual process — immune to registrar credential compromise.
Why the server was never the problem
The investigation at the WordPress server — PHP files, plugins, admins, database options — would have taken hours and found nothing. Because there was nothing to find. The server was untouched.
This is an important pattern: when a redirect happens for any URL on the domain, including pages that do not exist in WordPress, WordPress is not the cause. WordPress only redirects routes it knows about. A server that serves a static HTML redirect page for any request is operating at the DNS level — not the application level.
Cleaning WordPress for hours while the DNS points to another server is like changing the lock on a house while the intruder is next door with the front door key. The problem was at the registry, not the property.
The 5-minute diagnostic — dig, curl -sv -L, certificate inspection, nameserver whois — is sufficient to rule out server compromise and identify DNS hijack. Only after ruling out DNS does it make sense to investigate the application.
