干威胁狩猎这行的人应该都有同感真正熬人的往往不是样本逆向那一关而是顺着样本留下的痕迹一层一层往回摸清楚背后的C2基础设施。一次应急响应里EDR把恶意程序拦下来了告警关闭了但如果不知道它回连的服务器在哪、同一批基础设施还服务着多少其他域名那这次事件处理只能算做了一半。Keklick就是在这种场景下被我用顺手的一款C2追踪与可视化工具它把散落在沙箱报告、证书日志、被动DNS和WHOIS里的线索归拢到一起再变成一张能直接读懂的关联关系图。这篇文章我打算从工具定位、数据接入、可视化逻辑、完整追踪流程以及落地运营会踩的坑这五个方面展开。适合正在做威胁猎人、恶意软件分析、事件响应或者想给自己的分析流程加一个基础设施视角的人参考如果你是新手也可以把它当作理解C2追踪工作流的一篇入门笔记。1. 为什么威胁猎人最终都会回到追踪C2这件事上1.1 真实的狩猎场景里样本只是起点不是终点先还原一个很常见的日常某天值班邮箱里躺着一封带附件的钓鱼邮件沙箱跑完以后给出一个结论——该可执行文件会从某个域名拉取下一阶段载荷并尝试建立持久化。到这一步很多分析报告就收尾了。但作为威胁猎人我的习惯是多问一句这个域名是谁注册的它解析到哪个IP这个IP上还挂着多少别的域名那些域名又是不是同一个团伙在运营。这一连串再问一句的行为本质就是C2基础设施追踪。攻击者为了不让基础设施被一锅端通常会做域名轮换、IP跳变、CDN前置、证书复用这些操作。防御方如果只盯住单一IOC就会陷入打地鼠的循环今天封一个域名明天它换一个新域名继续用。如果把视角从单个IOC提升到一块基础设施才能看到攻击者真正的业务骨架。Keklick这个工具在我理解里就是为这个场景设计的。它不是一个能自动抓到恶意样本的检测器也不是一个靠特征码做查杀的杀毒引擎它的核心工作是把已经发现的线索做二次加工关联、聚类、可视化、沉淀。1.2 手动追踪C2的三大痛点在没有这类工具之前我追踪C2基础设施主要靠的是一堆浏览器标签页和脑内关联。最难受的其实是下面三点信息源太散。WHOIS注册信息要去注册商查证书记录要去证书透明度日志搜被动DNS数据要单独拉一个平台沙箱报告又存在另一个系统里几个平台之间的数据没法直接打通每换一个平台就要重新复制粘贴一遍查询。关联关系难记录。发现A域名和B证书被同一个注册邮箱申请过这个关联可能只是一次查询里的偶然发现如果把浏览器标签页关掉这条线索就断了更没办法积累成可复用的知识。证据链要跨时间线拼接。C2基础设施不是静态的攻击者会在两周内完成一次从注册域名、配置解析到更换IP的完整生命周期手工在多个时间节点上追踪并且保证不漏点非常消耗精力出了错还不好回溯。这些痛点单独拎出来任何一个都算不上难解决但组合在一起就会让一次基础设施追踪从几个小时拖到一个下午。Keklick把我从这种状态里解放了出来。1.3 Keklick的定位和它能补上的那一块拼图用一句话概括Keklick是放在沙箱检测和情报平台之间的中间分析层。它不替代EDR、不替代沙箱也不替代威胁情报源它做的是把分析和情报源产生的原始数据接过来通过内置的关联逻辑找出哪些IOC其实属于同一套基础设施然后在前端用一种直观的方式把关系展示出来。如果你团队里已经有一套完整的威胁情报管理平台那Keklick可以充当一个轻量化的前置分析界面如果你们还在靠Excel管理IOC那它可以直接作为团队共享的追踪工作台。实践下来它补上的那块拼图正是威胁猎人和恶意软件分析师最需要却又最容易被忽视的部分把零散的IOC变成一整张基础设施关系网。2. Keklick的数据底座支持哪些线索源与指纹类型2.1 输入层从沙箱报告到被动DNS都能接Keklick的数据接入做得比较实用。常见的数据源比如沙箱JSON报告、DNS解析日志、WHOIS导出、证书透明度日志、威胁情报平台API返回的告警数据都可以按模块导入。我日常用得最多的是三类沙箱报告从动态分析结果里提取的网络行为部分包括Extracted domains、IP、HTTP请求列表、JA3指纹等字段。Keklick会自动映射这些字段不需要手动掰开json一条条看。被动DNS批量文件rDNS系统导出的域名解析记录是关联扩展最有力的数据源一个IP今天解析了100个域名这些域名里可能就藏着同伙。证书透明度日志通过CT日志查询某个证书序列号或者签发者名称可以反查同一本证书下挂载的所有域名。除了这些还有Restful API可以通过脚本把任何内部平台的数据推进来比如自家SAR系统导出的恶意文件关联域名列表。接入层的设计逻辑很简单只要能提供IP、域名、证书、邮箱、哈希这五类基础实体Keklick就有办法纳入统一分析。2.2 指纹提取一把钥匙开多把锁的关联逻辑C2追踪里最典型的关联方式就一句大白话找共同点。攻击者往往会为了省事在同一批基础设施上复用某些钥匙。Keklick的指纹提取模块关注的正是这类复用痕迹。我把最常用的几种指纹类型整理成了一张表方便理解指纹类型含义和作用典型场景TLS证书指纹同一证书被多个域名共用说明这些域名很可能由同一主体部署单本证书挂载了十几个子域名注册邮箱/名称WHOIS里的注册人信息是基础设施家族识别的重要线索不同域名注册信息指向同一个邮箱HTTP响应头特征C2面板框架会留下特定的Server头、meta标签、静态资源路径多个主机返回完全一致的404页面结构JA3/JA3S指纹TLS握手特征服务端与客户端的组合指纹有助于识别同一工具集沙箱报告里多个样本回连的TLS指纹一致ASN与托管段IP归属的自治域和网段能看出基础设施是否集中在同一托管商多个C2 IP落在同一个AS下的相近段里这条逻辑很像我们日常认车一辆车被贴了膜、换了号牌但轮毂样式和尾灯造型还是同一批老车迷一眼就能认出来。Keklick把轮毂和尾灯这些特征点做了结构化提取后续找车就容易多了。2.3 关联算法背后的去重与打分策略光有指纹还不够如果一股脑把找到的关联全部塞进图里出来的关系网会稠密到没法看。Keklick的处理方式是对每一条关联做置信度打分再通过阈值控制展示范围。具体做法大致是置信度 基础权重(指纹类型) × 时效衰减因子 × 证据强度系数证书指纹复用这类强关联基础权重就高单纯IP段相邻这类弱关联权重就低。时效衰减因子用来处理三个月前的关联现在还剩多少参考价值——时间越久线索的可信度越低。证据强度系数则根据证据来源判断沙箱分析里观察到的直接回连行为系数大于从被动DNS里推测出的间接关联。打分后的结果前端会按照置信度从高到低做展示。这个设计我比较喜欢因为实际分析的时候你第一眼想看到的不是“这个域名可能和很多资产有关系”而是“哪几条关联是最确定的可以优先深挖”。3. 可视化视图设计把基础设施痕迹变成可读的关系网3.1 实体关系图域名、IP、证书、邮箱如何连成一张网Keklick的实体关系图是默认工作台也是我打开工具后最先落的页面。图上节点类型用不同颜色做了区分域名、IP地址、SSL证书、注册邮箱、哈希值、URL路径各用一类色系。关系边则分成实线和虚线实线代表直接观测到的连接虚线代表推导出来的弱关联。实际看图的体验很像在解一道连线题一个IP节点被多个域名节点环绕说明这些域名都解析到同一台服务器两个域名节点同时连接同一个证书节点说明它们共用一本TLS证书一个邮箱节点连着几个不同TLD的域名说明这一套域名的注册人信息可能都出自同一个人。每点一个节点右侧栏就会把该实体的时间线、来源、原始证据条数铺出来省了来回切窗口。我自己用下来最深的体会是图越稀疏反而越可疑。正常情况下一个正经业务域名的关联节点不会太多如果一个C2域名关联出几十个节点那这个集群的扩张程度就相当吓人了优先处置的价值也越高。3.2 时间线视图判断C2基础设施活跃窗口实体关系图回答的是谁和谁有关时间线视图回答的是这些关系从什么时候开始、到什么时候结束。Keklick的时间线视图把每个实体的首次观测和最后观测时间画成一条横条。多个横条按时间轴排列以后能很直观地看出基础设施的运营节奏。比如说一批域名的解析记录都集中在某个星期内批量上架这个批量上架的动作本身就是很强的关联信号如果之后再批量下线那可能整个集群进入了休眠状态。这个视图对应急响应特别有用。比如我们凌晨发现在野攻击样本如果对应域名在上周就开始有DNS活动那整个被入侵的时间窗口就要相应往前推处置范围也要跟着扩大。否则只分析样本发现之后的数据很容易低估影响面。3.3 地理分布与归属信息快速定位托管位置Keklick还提供了一类简单但很实用的地理视图把IP节点按GeoIP信息和ASN归属投到地图上。这里得说清楚IP地理定位本身精度有限城市级别误差比较大但用来观察基础设施的托管分布足够了。我从这个视图里总结出两个判断思路如果整个集群的IP集中在单一数据中心比如某一栋机房或者某一段特定AS里说明攻击者的基础设施是集中采购的端点暴露出租商之后容易做封禁集群的耐药性也比较弱。如果IP横跨好几个大洲而且AS分布五花八门说明攻击者做了明显的分散部署这种集群在处置时更要谨慎可能需要从域名注册商层面的投诉和注销入手。当然这个视图的判断价值有限只能作为辅助依据真正决定处置动作的还得看关联证据的置信度。4. 一次完整C2追踪的复现从单一域名到基础设施集群4.1 场景起步拿到一份恶意样本的分析结果为了讲清楚完整流程我在这里用一个虚构但非常典型的场景来演示。假设你在做样本分析沙箱报告里只有一个外联域名evil-update[.]com解析到198.51.100.23这是文档保留地址现实中不会直接遇到。按照常规流程你可能会先看WHOIS、再查证书而我现在会用Keklick把整个追踪过程串起来。第一步是把沙箱报告导入Keklick。你可以直接选择JSON文件上传也可以用API推送。工具会自动识别其中的实体并把样本哈希关联到相应的域名和IP上这样一来后续每一步分析动作都能有一条可追溯的来源路径报告的审计性也更好。4.2 用Keklick做关联扩展拿到初始实体后真正的追踪开始了。我习惯按下面这个顺序操作先跑一次直接关联。Keklick通过内置的证书日志和被动DNS数据源把evil-update[.]com的A记录历史、证书记录、注册邮箱信息都拉出来。这一步不需要额外配置数据源在部署阶段配好以后界面上一键就能触发。查看关联回来的新实体。假设证书记录显示同一本证书还覆盖了upgrade-cdn[.]net和support-patch[.]org两个域名而且WHOIS里注册邮箱和初始域名相同。此时关系图里就会浮现出一个小集群雏形。对新域名继续扩展。因为upgrade-cdn[.]net和support-patch[.]org都是新出现的域名把它们分别作为新的源实体再点一次扩展把IP解析记录纳进来。用指纹聚类做无损回溯。被动DNS数据里198.51.100.23这个IP在最近三个月内一共解析过17个域名其中6个域名的TLS证书指纹完全相同。Keklick会把指纹一致的那6个域名自动归成同一组。这样一个“单域名”开局经过两三轮扩展就变成了一个包含7个域名、3个IP、2本证书、1个注册邮箱的完整集群。整个过程如果手工做至少得两个小时起步而现在二十分钟以内可以跑完。4.3 结果解读与报告输出扩展完之后解读这一步决定了整个过程的价值。我在Keklick的实体关系图里关注三类信息集群的规模。7个域名用同一本证书不管怎么看都不像正常业务更像可控的基础设施集合。集群的存活时间。时间线视图中这些域名的首次注册时间集中在同一个月随后一个接一个开始解析到同一IP这个时间序列本身就说明它们由同一个运营者管理。关联置信度最高的边。优先看置信度90分以上的关系它们足以支撑一封请求域名下线的投诉函低置信度关系留作线索不用于处置依据。报告环节Keklick支持导出当前视图的高清图和相关证据列表。我会把图放进事件报告再把实体清单、关联依据、置信度分数作为附录导出。这里有个细节导出的证据列表建议保留原始日志条目而不是只留结论后续涉及更深入的追踪或者撤诉复核时可以直接回到原始数据。5. 长期运营中一定会遇到的坑与调整建议5.1 时效性陷阱旧数据比脏数据更坑Keklick部署完的前两周我踩过最大的坑是误报率飙升。排查下来发现问题不是下载数据出错而是被动DNS数据源里包含了大量长达两年的历史解析记录。一个IP在两年前解析过正常业务域名不代表它现在还在服务那个域名但关联图会把这条历史凭证画成实线导致我一度把一个正常托管商的IP段当成C2基础设施来查。处理办法是给Keklick加时效策略在配置里对被动DNS类型的数据设置时间窗口过滤只保留最近90天内的解析记录证书日志按证书有效期做二次过滤只保留与观测时间重叠的证书记录。这个调整做完之后图中的边就干净多了。现在团队每次接入新数据源之前都会先做一次数据新鲜度评估。老话讲garbage ingarbage out在威胁情报这个领域里还要补半句stale data infalse positive out。5.2 可视化性能边界与处理策略实体关系图在所有节点全量渲染的时候会有明显的性能压力。我在做大范围基础设施普查时一次堆了4000多个节点进去浏览器直接卡到拖动都成问题。这种情况不是Keklick独有的几乎所有图数据库可视化工具都绕不开。我的处理思路是分级加载先只展示置信度超过70分的强关联关系把弱关联边收起来确认方向之后再按需展开某一块子图。Keklick的渲染设置里可以调节“关系深度”和“每层最大节点数”把这两个值分别调到2层和200个日常浏览的性能就很流畅了。如果你有定期大规模批处理的习惯建议把初始分析放到服务端跑完只把过滤后的关系结果推送给前端这样体验会好很多。5.3 误报处理和团队协作的建议最后说误报。Keklick会自动关联出不少“看似有关、实际无关”的线索尤其是云服务商和CDN的共享IP段。举个例子同一台Web服务器上通过虚拟主机托管了100个域名这100个域名解析到同一个IPKeklick默认会把它们画成一个“关联集群”但在实际业务场景里它们可能只是同一个CDN节点上的租户攻击者未必拥有整台服务器。应对方式是在配置文件里维护一张“已知基础网络白名单”把常用CDN段、云厂商段、公共邮箱分发域名标成基础设施类型。这样Keklick在关联时会把它们当作“中转节点”而不是“目标集群”打分权重也会相应降低。在团队协作上我个人的经验是给每一个事件线建一个独立项目标签比如按命名规则或者值班批次归档。Keklick支持把每一次追踪的视图连同证据沉淀成一个案例快照这个功能对交接班特别有用——下一个分析师接手时不需要重新梳理打开前一天存的快照就能在图上接着干活。现在这批C2追踪结果我会定期导成标准化格式回灌到团队情报库里做长期观测。每过一两周重新打开旧项目跑一遍新增数据看看有没有新的域名挂到熟悉的证书或者IP段下面这已经成了我团队例行狩猎里最省力的一个环节。
C2追踪与基础设施可视化：Keklick工具实战指南
干威胁狩猎这行的人应该都有同感真正熬人的往往不是样本逆向那一关而是顺着样本留下的痕迹一层一层往回摸清楚背后的C2基础设施。一次应急响应里EDR把恶意程序拦下来了告警关闭了但如果不知道它回连的服务器在哪、同一批基础设施还服务着多少其他域名那这次事件处理只能算做了一半。Keklick就是在这种场景下被我用顺手的一款C2追踪与可视化工具它把散落在沙箱报告、证书日志、被动DNS和WHOIS里的线索归拢到一起再变成一张能直接读懂的关联关系图。这篇文章我打算从工具定位、数据接入、可视化逻辑、完整追踪流程以及落地运营会踩的坑这五个方面展开。适合正在做威胁猎人、恶意软件分析、事件响应或者想给自己的分析流程加一个基础设施视角的人参考如果你是新手也可以把它当作理解C2追踪工作流的一篇入门笔记。1. 为什么威胁猎人最终都会回到追踪C2这件事上1.1 真实的狩猎场景里样本只是起点不是终点先还原一个很常见的日常某天值班邮箱里躺着一封带附件的钓鱼邮件沙箱跑完以后给出一个结论——该可执行文件会从某个域名拉取下一阶段载荷并尝试建立持久化。到这一步很多分析报告就收尾了。但作为威胁猎人我的习惯是多问一句这个域名是谁注册的它解析到哪个IP这个IP上还挂着多少别的域名那些域名又是不是同一个团伙在运营。这一连串再问一句的行为本质就是C2基础设施追踪。攻击者为了不让基础设施被一锅端通常会做域名轮换、IP跳变、CDN前置、证书复用这些操作。防御方如果只盯住单一IOC就会陷入打地鼠的循环今天封一个域名明天它换一个新域名继续用。如果把视角从单个IOC提升到一块基础设施才能看到攻击者真正的业务骨架。Keklick这个工具在我理解里就是为这个场景设计的。它不是一个能自动抓到恶意样本的检测器也不是一个靠特征码做查杀的杀毒引擎它的核心工作是把已经发现的线索做二次加工关联、聚类、可视化、沉淀。1.2 手动追踪C2的三大痛点在没有这类工具之前我追踪C2基础设施主要靠的是一堆浏览器标签页和脑内关联。最难受的其实是下面三点信息源太散。WHOIS注册信息要去注册商查证书记录要去证书透明度日志搜被动DNS数据要单独拉一个平台沙箱报告又存在另一个系统里几个平台之间的数据没法直接打通每换一个平台就要重新复制粘贴一遍查询。关联关系难记录。发现A域名和B证书被同一个注册邮箱申请过这个关联可能只是一次查询里的偶然发现如果把浏览器标签页关掉这条线索就断了更没办法积累成可复用的知识。证据链要跨时间线拼接。C2基础设施不是静态的攻击者会在两周内完成一次从注册域名、配置解析到更换IP的完整生命周期手工在多个时间节点上追踪并且保证不漏点非常消耗精力出了错还不好回溯。这些痛点单独拎出来任何一个都算不上难解决但组合在一起就会让一次基础设施追踪从几个小时拖到一个下午。Keklick把我从这种状态里解放了出来。1.3 Keklick的定位和它能补上的那一块拼图用一句话概括Keklick是放在沙箱检测和情报平台之间的中间分析层。它不替代EDR、不替代沙箱也不替代威胁情报源它做的是把分析和情报源产生的原始数据接过来通过内置的关联逻辑找出哪些IOC其实属于同一套基础设施然后在前端用一种直观的方式把关系展示出来。如果你团队里已经有一套完整的威胁情报管理平台那Keklick可以充当一个轻量化的前置分析界面如果你们还在靠Excel管理IOC那它可以直接作为团队共享的追踪工作台。实践下来它补上的那块拼图正是威胁猎人和恶意软件分析师最需要却又最容易被忽视的部分把零散的IOC变成一整张基础设施关系网。2. Keklick的数据底座支持哪些线索源与指纹类型2.1 输入层从沙箱报告到被动DNS都能接Keklick的数据接入做得比较实用。常见的数据源比如沙箱JSON报告、DNS解析日志、WHOIS导出、证书透明度日志、威胁情报平台API返回的告警数据都可以按模块导入。我日常用得最多的是三类沙箱报告从动态分析结果里提取的网络行为部分包括Extracted domains、IP、HTTP请求列表、JA3指纹等字段。Keklick会自动映射这些字段不需要手动掰开json一条条看。被动DNS批量文件rDNS系统导出的域名解析记录是关联扩展最有力的数据源一个IP今天解析了100个域名这些域名里可能就藏着同伙。证书透明度日志通过CT日志查询某个证书序列号或者签发者名称可以反查同一本证书下挂载的所有域名。除了这些还有Restful API可以通过脚本把任何内部平台的数据推进来比如自家SAR系统导出的恶意文件关联域名列表。接入层的设计逻辑很简单只要能提供IP、域名、证书、邮箱、哈希这五类基础实体Keklick就有办法纳入统一分析。2.2 指纹提取一把钥匙开多把锁的关联逻辑C2追踪里最典型的关联方式就一句大白话找共同点。攻击者往往会为了省事在同一批基础设施上复用某些钥匙。Keklick的指纹提取模块关注的正是这类复用痕迹。我把最常用的几种指纹类型整理成了一张表方便理解指纹类型含义和作用典型场景TLS证书指纹同一证书被多个域名共用说明这些域名很可能由同一主体部署单本证书挂载了十几个子域名注册邮箱/名称WHOIS里的注册人信息是基础设施家族识别的重要线索不同域名注册信息指向同一个邮箱HTTP响应头特征C2面板框架会留下特定的Server头、meta标签、静态资源路径多个主机返回完全一致的404页面结构JA3/JA3S指纹TLS握手特征服务端与客户端的组合指纹有助于识别同一工具集沙箱报告里多个样本回连的TLS指纹一致ASN与托管段IP归属的自治域和网段能看出基础设施是否集中在同一托管商多个C2 IP落在同一个AS下的相近段里这条逻辑很像我们日常认车一辆车被贴了膜、换了号牌但轮毂样式和尾灯造型还是同一批老车迷一眼就能认出来。Keklick把轮毂和尾灯这些特征点做了结构化提取后续找车就容易多了。2.3 关联算法背后的去重与打分策略光有指纹还不够如果一股脑把找到的关联全部塞进图里出来的关系网会稠密到没法看。Keklick的处理方式是对每一条关联做置信度打分再通过阈值控制展示范围。具体做法大致是置信度 基础权重(指纹类型) × 时效衰减因子 × 证据强度系数证书指纹复用这类强关联基础权重就高单纯IP段相邻这类弱关联权重就低。时效衰减因子用来处理三个月前的关联现在还剩多少参考价值——时间越久线索的可信度越低。证据强度系数则根据证据来源判断沙箱分析里观察到的直接回连行为系数大于从被动DNS里推测出的间接关联。打分后的结果前端会按照置信度从高到低做展示。这个设计我比较喜欢因为实际分析的时候你第一眼想看到的不是“这个域名可能和很多资产有关系”而是“哪几条关联是最确定的可以优先深挖”。3. 可视化视图设计把基础设施痕迹变成可读的关系网3.1 实体关系图域名、IP、证书、邮箱如何连成一张网Keklick的实体关系图是默认工作台也是我打开工具后最先落的页面。图上节点类型用不同颜色做了区分域名、IP地址、SSL证书、注册邮箱、哈希值、URL路径各用一类色系。关系边则分成实线和虚线实线代表直接观测到的连接虚线代表推导出来的弱关联。实际看图的体验很像在解一道连线题一个IP节点被多个域名节点环绕说明这些域名都解析到同一台服务器两个域名节点同时连接同一个证书节点说明它们共用一本TLS证书一个邮箱节点连着几个不同TLD的域名说明这一套域名的注册人信息可能都出自同一个人。每点一个节点右侧栏就会把该实体的时间线、来源、原始证据条数铺出来省了来回切窗口。我自己用下来最深的体会是图越稀疏反而越可疑。正常情况下一个正经业务域名的关联节点不会太多如果一个C2域名关联出几十个节点那这个集群的扩张程度就相当吓人了优先处置的价值也越高。3.2 时间线视图判断C2基础设施活跃窗口实体关系图回答的是谁和谁有关时间线视图回答的是这些关系从什么时候开始、到什么时候结束。Keklick的时间线视图把每个实体的首次观测和最后观测时间画成一条横条。多个横条按时间轴排列以后能很直观地看出基础设施的运营节奏。比如说一批域名的解析记录都集中在某个星期内批量上架这个批量上架的动作本身就是很强的关联信号如果之后再批量下线那可能整个集群进入了休眠状态。这个视图对应急响应特别有用。比如我们凌晨发现在野攻击样本如果对应域名在上周就开始有DNS活动那整个被入侵的时间窗口就要相应往前推处置范围也要跟着扩大。否则只分析样本发现之后的数据很容易低估影响面。3.3 地理分布与归属信息快速定位托管位置Keklick还提供了一类简单但很实用的地理视图把IP节点按GeoIP信息和ASN归属投到地图上。这里得说清楚IP地理定位本身精度有限城市级别误差比较大但用来观察基础设施的托管分布足够了。我从这个视图里总结出两个判断思路如果整个集群的IP集中在单一数据中心比如某一栋机房或者某一段特定AS里说明攻击者的基础设施是集中采购的端点暴露出租商之后容易做封禁集群的耐药性也比较弱。如果IP横跨好几个大洲而且AS分布五花八门说明攻击者做了明显的分散部署这种集群在处置时更要谨慎可能需要从域名注册商层面的投诉和注销入手。当然这个视图的判断价值有限只能作为辅助依据真正决定处置动作的还得看关联证据的置信度。4. 一次完整C2追踪的复现从单一域名到基础设施集群4.1 场景起步拿到一份恶意样本的分析结果为了讲清楚完整流程我在这里用一个虚构但非常典型的场景来演示。假设你在做样本分析沙箱报告里只有一个外联域名evil-update[.]com解析到198.51.100.23这是文档保留地址现实中不会直接遇到。按照常规流程你可能会先看WHOIS、再查证书而我现在会用Keklick把整个追踪过程串起来。第一步是把沙箱报告导入Keklick。你可以直接选择JSON文件上传也可以用API推送。工具会自动识别其中的实体并把样本哈希关联到相应的域名和IP上这样一来后续每一步分析动作都能有一条可追溯的来源路径报告的审计性也更好。4.2 用Keklick做关联扩展拿到初始实体后真正的追踪开始了。我习惯按下面这个顺序操作先跑一次直接关联。Keklick通过内置的证书日志和被动DNS数据源把evil-update[.]com的A记录历史、证书记录、注册邮箱信息都拉出来。这一步不需要额外配置数据源在部署阶段配好以后界面上一键就能触发。查看关联回来的新实体。假设证书记录显示同一本证书还覆盖了upgrade-cdn[.]net和support-patch[.]org两个域名而且WHOIS里注册邮箱和初始域名相同。此时关系图里就会浮现出一个小集群雏形。对新域名继续扩展。因为upgrade-cdn[.]net和support-patch[.]org都是新出现的域名把它们分别作为新的源实体再点一次扩展把IP解析记录纳进来。用指纹聚类做无损回溯。被动DNS数据里198.51.100.23这个IP在最近三个月内一共解析过17个域名其中6个域名的TLS证书指纹完全相同。Keklick会把指纹一致的那6个域名自动归成同一组。这样一个“单域名”开局经过两三轮扩展就变成了一个包含7个域名、3个IP、2本证书、1个注册邮箱的完整集群。整个过程如果手工做至少得两个小时起步而现在二十分钟以内可以跑完。4.3 结果解读与报告输出扩展完之后解读这一步决定了整个过程的价值。我在Keklick的实体关系图里关注三类信息集群的规模。7个域名用同一本证书不管怎么看都不像正常业务更像可控的基础设施集合。集群的存活时间。时间线视图中这些域名的首次注册时间集中在同一个月随后一个接一个开始解析到同一IP这个时间序列本身就说明它们由同一个运营者管理。关联置信度最高的边。优先看置信度90分以上的关系它们足以支撑一封请求域名下线的投诉函低置信度关系留作线索不用于处置依据。报告环节Keklick支持导出当前视图的高清图和相关证据列表。我会把图放进事件报告再把实体清单、关联依据、置信度分数作为附录导出。这里有个细节导出的证据列表建议保留原始日志条目而不是只留结论后续涉及更深入的追踪或者撤诉复核时可以直接回到原始数据。5. 长期运营中一定会遇到的坑与调整建议5.1 时效性陷阱旧数据比脏数据更坑Keklick部署完的前两周我踩过最大的坑是误报率飙升。排查下来发现问题不是下载数据出错而是被动DNS数据源里包含了大量长达两年的历史解析记录。一个IP在两年前解析过正常业务域名不代表它现在还在服务那个域名但关联图会把这条历史凭证画成实线导致我一度把一个正常托管商的IP段当成C2基础设施来查。处理办法是给Keklick加时效策略在配置里对被动DNS类型的数据设置时间窗口过滤只保留最近90天内的解析记录证书日志按证书有效期做二次过滤只保留与观测时间重叠的证书记录。这个调整做完之后图中的边就干净多了。现在团队每次接入新数据源之前都会先做一次数据新鲜度评估。老话讲garbage ingarbage out在威胁情报这个领域里还要补半句stale data infalse positive out。5.2 可视化性能边界与处理策略实体关系图在所有节点全量渲染的时候会有明显的性能压力。我在做大范围基础设施普查时一次堆了4000多个节点进去浏览器直接卡到拖动都成问题。这种情况不是Keklick独有的几乎所有图数据库可视化工具都绕不开。我的处理思路是分级加载先只展示置信度超过70分的强关联关系把弱关联边收起来确认方向之后再按需展开某一块子图。Keklick的渲染设置里可以调节“关系深度”和“每层最大节点数”把这两个值分别调到2层和200个日常浏览的性能就很流畅了。如果你有定期大规模批处理的习惯建议把初始分析放到服务端跑完只把过滤后的关系结果推送给前端这样体验会好很多。5.3 误报处理和团队协作的建议最后说误报。Keklick会自动关联出不少“看似有关、实际无关”的线索尤其是云服务商和CDN的共享IP段。举个例子同一台Web服务器上通过虚拟主机托管了100个域名这100个域名解析到同一个IPKeklick默认会把它们画成一个“关联集群”但在实际业务场景里它们可能只是同一个CDN节点上的租户攻击者未必拥有整台服务器。应对方式是在配置文件里维护一张“已知基础网络白名单”把常用CDN段、云厂商段、公共邮箱分发域名标成基础设施类型。这样Keklick在关联时会把它们当作“中转节点”而不是“目标集群”打分权重也会相应降低。在团队协作上我个人的经验是给每一个事件线建一个独立项目标签比如按命名规则或者值班批次归档。Keklick支持把每一次追踪的视图连同证据沉淀成一个案例快照这个功能对交接班特别有用——下一个分析师接手时不需要重新梳理打开前一天存的快照就能在图上接着干活。现在这批C2追踪结果我会定期导成标准化格式回灌到团队情报库里做长期观测。每过一两周重新打开旧项目跑一遍新增数据看看有没有新的域名挂到熟悉的证书或者IP段下面这已经成了我团队例行狩猎里最省力的一个环节。
