DNS攻击前移到解析层，如何用IP离线库快速锁定恶意C2 IP？

2026年2月，微软披露的一类ClickFix攻击变种，让不少安全团队重新关注起DNS这条“老通道”。

以往恶意软件下发指令或载荷，更多依赖HTTP、HTTPS等Web请求，因此防火墙、EDR和流量分析系统也往往把重点放在Web访问、文件下载、脚本执行等环节。但这类新变种换了一种思路：攻击者诱导用户在Windows“运行”窗口中执行nslookup命令，随后通过DNS响应返回经过编码的PowerShell内容，进一步推动恶意行为执行。

从表面看，这个过程可能不像传统攻击那样出现明显的下载行为，也不一定会触发常见的Web访问告警。它更像一次普通DNS查询和响应。问题就在这里：攻击链被提前到了DNS解析阶段。

很多安全设备长期默认放行DNS流量，对DNS响应内容的检查强度也低于HTTP/S。攻击者正是利用了这个信任缺口，把DNS从“域名解析协议”变成了“指令传递通道”。

在这种情况下，防御重点不能只盯域名信誉，还要进一步分析DNS响应中返回的IP。通过IP离线库对目标IP进行网络类型、ASN归属、风险评分等画像分析，可以在载荷真正执行之前，提前识别可疑C2基础设施。

一、攻击为什么会前移到DNS解析层？

DNS本来是基础网络协议，几乎所有业务系统都依赖它完成域名解析。因此在很多网络环境中，DNS流量拥有较高的默认信任度。

攻击者利用这一点，把DNS流量伪装成正常解析行为，达到隐藏通信、下发指令或维持C2连接的目的。

1. ClickFix变种：把指令放进DNS响应

这类攻击中，攻击者并不直接让终端访问恶意下载地址，而是诱导用户执行DNS查询命令。

请求被发送到攻击者控制的解析服务器后，DNS响应中会返回经过编码的脚本内容。后续一旦被解码并执行，恶意载荷就可能完成落地。

这种方式的隐蔽性在于：
传统检测系统可能重点关注可执行文件、脚本下载、HTTP请求和命令执行行为，但DNS响应本身容易被忽略。尤其在未对DNS响应内容做深度检测的环境中，这类行为可能不会第一时间被发现。

2. DNS隧道：把C2通信伪装成正常查询

除了通过DNS响应传递指令外，DNS隧道也是常见方式之一。

攻击者可能将C2指令、心跳信息或数据片段放进TXT记录、异常子域或A记录响应中。恶意程序通过频繁查询看似正常的域名，与远端C2服务器保持通信。

更隐蔽的做法是采用“DNS探测 + HTTPS传输”的组合模式：
先通过DNS子域编码完成存活检测、环境探测或节点分配，再切换到伪装后的HTTPS连接完成更高带宽的数据交互。

因此，DNS已经不只是“查域名”的协议，它正在被攻击者当成攻击链中的前置通信层。

二、用IP离线库三步定位可疑C2 IP

当攻击链前移到DNS层，安全团队的处置窗口也被提前到了DNS查询和响应发生的瞬间。

这时可以采用一个简单的三步排查思路：

异常DNS日志提取 → 解析目标IP画像 → ASN聚类研判基础设施。

第一步：从DNS日志中筛出异常查询

首先需要从DNS服务器、网关、EDR或流量探针中导出异常时段的DNS日志，重点关注以下特征：

某个客户端短时间内DNS查询量异常增高；
查询域名长度明显偏长；
子域中出现大量随机字符串；
TXT、NULL、MX等记录类型请求占比异常；
同一终端频繁访问低信誉或新注册域名；
DNS响应返回的IP集中在数据中心或高风险ASN。

可以用类似下面的SQL做初步筛选：

SELECT 
    client_ip,
    COUNT(*) AS query_total,
    AVG(LENGTH(qname)) AS avg_qname_len,
    SUM(CASE WHEN qtype IN ('TXT', 'NULL', 'MX') THEN 1 ELSE 0 END) AS abnormal_qtype_total
FROM dns_logs
WHERE timestamp >= NOW() - INTERVAL 1 HOUR
GROUP BY client_ip
HAVING 
    query_total > 500
    OR avg_qname_len > 50
    OR abnormal_qtype_total > 10
ORDER BY query_total DESC;

如果同一客户端在短时间内产生大量DNS请求，并且查询域名里包含明显随机化子域，就需要进一步排查。这类行为很可能不是正常业务访问，而是DNS隧道、C2心跳或自动化探测。

第二步：用IP离线库分析DNS响应IP

筛出可疑域名后，下一步不是只看域名，而是提取这些域名解析出来的目标IP。

通过IP离线库，可以快速获得这些IP的网络类型、ASN、运营主体、风险评分等信息。这样可以判断它更像普通用户网络、云服务器、数据中心节点，还是高风险代理/异常基础设施。

示例代码如下：

import ipdatacloud

ip_db = ipdatacloud.OfflineIPLib(
    "/data/ipdb/ip_data_cloud.mmdb",
    enable_risk=True
)

def analyze_suspicious_ips(ip_list):
    result = []

    for ip in ip_list:
        info = ip_db.query(ip)

        result.append({
            "ip": ip,
            "net_type": info.get("net_type"),
            "risk_score": info.get("risk_score", 0),
            "asn": info.get("asn"),
            "asn_org": info.get("asn_org")
        })

    return result


dns_response_ips = [
    "45.33.22.11",
    "103.233.147.1",
    "94.156.232.40"
]

analysis_result = analyze_suspicious_ips(dns_response_ips)

c2_candidates = [
    item for item in analysis_result
    if item["net_type"] == "数据中心" and item["risk_score"] > 70
]

print(f"发现 {len(c2_candidates)} 个高风险疑似C2 IP")

可以重点关注以下判断逻辑：

特征	风险判断
数据中心IP + 高风险评分	疑似C2服务器概率较高
ASN归属云服务商	攻击者可能使用云主机搭建C2
多个可疑IP属于同一ASN	可能存在成组攻击基础设施
短时间频繁解析同一批IP	可能是C2轮询或探测行为
DNS响应IP与业务区域不匹配	需要进一步核查访问合理性