官网被黑实录：TDK 被整组替换、AI 恢复，和没清理干净的遗留

官网后台曾用弱口令。攻击者进来后，把整站 TDK——标题、描述、关键词——全部换成了自己的内容；维护者后来用 AI 把文案逐项写了回去。当时没弄清两件事：数据库有没有被动过？服务器上除了 TDK 还留没留别的东西？

这次调查就围绕这两个问题展开。结论先说：

1. 全站 TDK 的集中落点是一个 PHP 数据文件，不是数据库表——改 TDK 这条路径从头到尾不需要碰数据库。

2. 数据库只读核查：文章级 TDK 字段当前没有任何被批量替换的痕迹，但历史无法证明。

3. 恢复过程在后台日志里留有完整记录：前后三轮迭代。

4. 与 TDK 独立的另一条遗留仍在运行：框架里的爬虫劫持代码加三份后门，这是搜索结果至今仍被污染的原因。

一、TDK 到底存在哪

后台"基本设置"的读写链路很短：保存时写入一个 898 字节的序列化数组文件，读取时直接取这个文件。全站 TDK 的唯一集中存储就是它，不存在"基本设置"数据库表。

首页是动态渲染的，标题和描述每次请求都从这份文件取值。也就是说：改这一个小文件，全站每个页面的 TDK 立即跟着变。"完整的 TDK 都被改了"，在存储结构上就是这么一句话的事。

文章级 TDK 在数据库里——每篇新闻有自己的关键词和描述字段，详情页优先用文章自己的值。静态首页和个别模板则是独立的硬编码，不走配置。

所以攻击者改全站 TDK 有两条现成的路：后台表单，或者任意一份 WebShell 直接写文件。两条路都不需要登录数据库。

二、恢复过程：日志里留着三轮记录

后台应用日志共 534 份，全量扫描后，恢复的迭代过程完整浮了出来。

第一轮，8 月 22 日。 上午两次走表单保存；下午封禁旧管理员、新建两个新账号——弱口令的处置实际发生在这个下午；随后连续重建首页缓存，静态首页文件的修改时间与缓存请求精确对上。

第二轮，8 月 30 日。 一次"打开、保存、回看"的补丁。仍不是最终版。

第三轮，9 月 15 日。 上午 10:56，配置文件落盘为最终版，与正常样本逐字节一致。关键差异是：落盘前后，日志里没有任何后台请求。 最终这次恢复不是走表单，而是内容拟好后直接写进文件——与"AI 生成内容后写入"的方式吻合。紧接着 11:06 隔离可疑文件、11:07 Nginx 加固、11:08 一次复核性登录。

另一个发现：全库 534 份日志里，走表单的保存只有三次，全是维护者会话，没有攻击者的保存记录。攻击者若走表单改 TDK 会留下同样的请求痕迹——所以篡改更可能是 WebShell 直接写文件，同样绕过了应用日志。

而"被改时长什么样"已经永远无法还原：磁盘上没有保留任何一份被黑 TDK 的历史快照，两份静态首页备份里的 TDK 都是正常内容。

三、数据库查到了什么

限定授权的只读核查：只读事务、只查表结构和 TDK 相关字段、不读客户反馈内容、不改任何数据。

71 篇文章的检查结果：关键词全部有值、去重后 59 种——一篇文章一个值，是正常人工维护的形态；赌博、色情、引流类词在所有 TDK 字段零命中。

但有三条硬限制：文章表的 update_time 全部为 0（应用从不维护这个字段）、数据库 binlog 和 general log 都关着。所以当前数据干净只能说明"现在没被改"，不能证明"历史上从未被改"。

结合第一节的存储结构，诚实的结论是：全站 TDK 篡改本就不需要数据库参与，当前证据也指向数据库大概率只是旁观者。

四、TDK 恢复了，搜索结果为什么还是脏的

这是本次调查的起点：搜索引擎里仍能搜到大量色情、引流类地址指向这个域名。

复现很直接：同一个异常地址，普通浏览器标识访问是 404；换成爬虫标识，返回 200 和完整的垃圾文章；再换回普通标识，又是 404。在服务器上绕过公网直连本机复测，结果相同——异常就在源站，不是搜索缓存。

定位到的植入点在框架公共函数文件里：一段顶层代码，识别到爬虫标识加垃圾路径特征时，实时从外部内容服务取文、输出、终止请求；普通请求则继续走应用，因控制器不存在返回 404。文章内容是请求时远程取回的，本站不落地。

这和 TDK 篡改是两条独立的链：TDK 管"这个站对外自称是什么"，劫持管"给爬虫实时喂什么"。AI 把 TDK 改回来，对这段代码没有任何影响——这就是"表面恢复、搜索污染仍在"能同时成立的原因。

五、到现在还遗留什么

• 爬虫劫持代码仍在框架公共函数里，搜索污染持续；

• 三份后门（代码执行型、综合 WebShell、文件管理型）仍在框架目录——只要它们在，恢复好的 TDK 随时可以被再改写；

• 上传链缺陷：子控制器空构造没继承登录检查，上传无扩展名白名单——改密码覆盖不了这条写入路径；

• 文件权限 0777、数据库端口映射到宿主机所有网卡、访问日志指向 /dev/null、binlog 关闭——出事时依然没有审计通道。

结语

弱口令进后台，改的是一份 898 字节的配置文件，数据库全程不必参与；恢复走了三轮，最终一轮是 AI 拟好内容直接写文件；但另一条独立的爬虫劫持链和三份后门还在，搜索污染持续到今天。

TDK 恢复了，不等于入侵处理完了。 真正的验收标准是：同样的异常请求不再返回垃圾内容、后门无处可写、日志能回答"下一次是什么时候"。

发布说明：文中域名、服务器地址、后门入口均已脱敏；数据库核查为只读事务且未读取客户数据；处置尚未完成，发布前应更新真实结果。