Buzeli
buzeliSoluções Digitais
安全

WordPress恶意重定向却无感染文件：如何在5分钟内诊断DNS劫持并避免格式化服务器

发布于 2026年4月24日

症状：重定向到未知页面

紧急求助电话打来了：一个在线学术期刊门户正在将访客重定向到一个可疑页面。现象持续发生——任何对该域名的访问都会自动跳转。

遇到这种情况，第一反应通常是直接检查WordPress服务器：查找被修改的PHP文件、被注入恶意代码的插件、非法创建的管理员账户。这是显而易见的路径——但当攻击向量是DNS时，这恰恰是错误的路径。

在动服务器之前，先检查DNS。发生在WordPress处理任何请求之前的重定向，很少是WordPress造成的。

5分钟诊断法

可疑重定向的诊断方法遵循特定顺序，从最外层到最内层。从服务器开始就是在浪费时间：

第一步：解析当前DNS

复制
# 检查域名当前指向哪个IP
dig journal.example.org A +short

# 同时通过公共DNS解析（确保没有本地缓存干扰）
dig @8.8.8.8 journal.example.org A +short
dig @1.1.1.1 journal.example.org A +short

在这个案例中，dig返回了两个IP：<IP_atacante_1>和<IP_atacante_2>。服务器的正确IP是<IP_legitimo>。前两个IP不是WordPress所在的服务器。

DNS返回的IP：<IP_atacante_1>, <IP_atacante_2>

真实WordPress服务器IP：<IP_legitimo>

即时结论：域名正指向一台完全不同的服务器。

第二步：追踪重定向详情

复制
# 追踪完整重定向链并检查每个步骤
curl -sv -L https://journal.example.org/ 2>&1 | head -60

响应内容一目了然：

复制
* 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>

一个极简HTML页面，其中有一段JavaScript代码在页面加载时立即跳转到/lander。没有任何合法内容。接收请求的服务器只提供这个重定向。

第三步：检查SSL证书

复制
# 验证证书颁发机构和颁发日期
curl -sv https://journal.example.org/ 2>&1 | grep -E "issuer|expire|start|subject"

证书揭示了最重要的细节：

CN：journal.example.org（正确——为目标域名颁发）

颁发机构：GoDaddy TLS Intermediate CA DV - R1v1——不是真实服务器标准的Let's Encrypt

颁发日期：事故发现前数小时

由注册商在事故当天颁发的有效SSL证书是直接的法证证据：攻击者对DNS的控制程度足以颁发证书——并且知道需要HTTPS才能让重定向看起来合法。

第四步：检查域名服务器

复制
# 检查域名的权威域名服务器
dig journal.example.org NS +short
# 结果：ns71.domaincontrol.com, ns72.domaincontrol.com

domaincontrol.com是GoDaddy的DNS基础设施。该域名使用GoDaddy的域名服务器——客户的GoDaddy账户就是被入侵的节点。

最终诊断：通过注册商实施的DNS劫持

有了这四项数据，全貌已经清晰。WordPress没有被入侵。攻击过程是：

1. 未经授权访问客户的GoDaddy账户（密码泄露或缺少双因素认证）。

2. 将域名的A记录修改为攻击者控制的服务器IP。

3. 通过GoDaddy为该域名颁发SSL证书——因为攻击者控制了DNS，能完成DV验证。

4. 攻击者的服务器提供一个带有跳转到/lander的JavaScript页面。

原始WordPress服务器保持完好无损。没有任何文件被修改。没有任何插件被入侵。没有创建任何管理员账户。如果我们按照传统的'清理WordPress'路径走，将浪费数小时——而DNS仍然指向错误的服务器，网站依然无法正常访问。

综合证据

DNS A记录：<IP_atacante_1>, <IP_atacante_2>——与真实服务器无关的IP

真实服务器IP：<IP_legitimo>——与DNS不匹配

证书颁发机构：GoDaddy（非Let's Encrypt）——攻击者利用DNS控制权颁发

颁发日期：事故当天——攻击的时间标记

页面内容：带有window.location.href跳转到/lander的极简HTML

域名服务器：GoDaddy——修改在注册商账户内部完成

恢复操作（客户端）

恢复遵循特定顺序——顺序很重要：

1. 立即更改GoDaddy账户密码。 在任何其他操作之前——防止攻击者重新修改。

2. 在GoDaddy账户上启用双因素认证。 通过认证器应用进行双因素认证（不用SMS，SMS可能被SIM卡劫持拦截）。

3. 将域名A记录恢复为正确的IP。 使用低TTL（60秒）以快速传播。

4. 检查同一GoDaddy账户下的其他域名。 如果一个账户被入侵，同一账户管理的其他域名可能也被修改了。

5. 检查GoDaddy中的DNS更改历史。 确认攻击发生时间，以及是否有其他记录被修改（MX、TXT、CNAME）。

6. 向GoDaddy报告事故。 要求调查未经授权的访问，并撤销攻击者颁发的证书。

预防措施：两项抵得过任何WAF的保护

注册商处的双因素认证——不是可选项

访问注册商是域名最高级别的访问权限。控制注册商就控制了DNS。控制DNS就控制了该域名下的一切——包括颁发有效SSL证书的能力。

通过认证器应用进行双因素认证（Google Authenticator、Authy）是最低要求。GoDaddy等注册商还提供DNS更改的邮件通知功能——启用该通知可在DNS被未授权修改时立即发出警报。

注册商锁定：ICANN级别的保护

对于关键域名——直接产生收益、代表组织身份或一旦被入侵难以恢复的域名——存在注册商锁定（Registry Lock）机制。这是ICANN注册局层面的锁定，可防止任何转移或NS更改，除非经过与注册商的人工验证流程。

复制
# 检查域名的锁定状态
whois journal.example.org | grep -i "status"

# 表示主动保护的输出：
# clientDeleteProhibited
# clientTransferProhibited
# clientUpdateProhibited
# serverDeleteProhibited   ← 注册商锁定（ICANN级别）
# serverTransferProhibited ← 注册商锁定（ICANN级别）
# serverUpdateProhibited   ← 注册商锁定（ICANN级别）

带有client前缀的状态由注册商设置，可由客户账户修改。带有server前缀的状态由注册局（ICANN）设置，需要人工流程才能修改——不受注册商凭证泄露影响。

为什么服务器从来都不是问题所在

在WordPress服务器上进行的调查——PHP文件、插件、管理员、数据库选项——将耗费数小时且一无所获。因为根本没有什么可找的。服务器完好无损。

这是一个重要规律：当重定向发生在域名下的任何URL，包括WordPress中不存在的页面时，WordPress不是原因。WordPress只重定向它知道的路由。对任何请求都提供静态HTML重定向页面的服务器，是在DNS层面运作——而非应用层面。

在DNS指向另一台服务器时花数小时清理WordPress，就像在入侵者拿着钥匙站在隔壁房子里时换门锁。问题在注册商，不在服务器本身。

5分钟诊断法——dig、curl -sv -L、证书检查、域名服务器whois——足以排除服务器入侵并确认DNS劫持。只有在排除DNS问题之后，才有必要深入调查应用层。

相关文章