DNS 协议承载的海量查询数据折射出用户行为特征，单纯依靠 DNS 数据虽能高效识别 DGA 与 fastflux 等早期威胁，但恶意软件在不同目的与环境下留下的 DNS 痕迹差异巨大，仅凭 DNS 难以完成从清洗、聚合到验证、防御的闭环。360Netlab 基于六年 DNS 安全积累，构建 DNSMon 系统，将每日数千亿次 DNS 查询与 Whois、Web、沙箱、蜜罐、证书等多维安全数据关联，生成域名级 IOC 并大规模拦截高风险域名，服务约 2000 万国内用户，实测拦截域名比同类厂商名单早数周至数月进入视野。
DNSMon 关联分析机制：
DNSMon 接入 360Netlab 自有的 Whois 注册信息、Web 爬虫内容、沙箱动态行为、蜜罐捕获样本、SSL 证书透明度日志等异构数据源。系统对每日数千亿次被动 DNS 查询实时去重、聚合，提取域名、IP、TTL、响应码、客户端地理分布等特征，再与上述多维数据交叉比对。例如某域名在短时间内解析到大量无关 IP、且 Whois 注册信息匿名、证书为自签名、沙箱跑出挖矿进程，即可判定为高可信 IOC。该流程实现了从原始查询到可落地封锁列表的自动化产出，日均生成数千条恶意与高度可疑域名封锁规则。
Skidmap 挖矿程序溯源实例：
以 Skidmap 为例，DNSMon 首先在被动 DNS 中发现大量疑似 C2 域名呈现算法生成特征，且解析 IP 集中于特定云厂商网段。关联沙箱样本发现该家族通过内核模块隐藏进程、篡改 cron 定时任务下载挖矿载荷，并利用合法域名前缀拼接伪装合法流量。结合蜜罐捕获的攻击载荷与证书透明度日志中新增的自签名证书，确认其基础设施部署时间早于公开情报披露约三周。最终输出的 IOC 列表包含 142 个域名、37 个 IP 段，已同步下发至终端防护平台实施拦截。
对运维与网络工程师的启示：
单一数据源的异常检测易产生大量误报且难以定性，引入资产、流量、样本、证书等多维数据关联，能显著提升 IOC 产出的时效性与准确度。工程实践中应建立标准化的数据清洗与字段映射流程，优先接入高可信自有数据源，再逐步扩展第三方情报，形成可度量的检测-验证-封锁闭环。
原文: APNIC Blog（2021-04-19）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog