拓冰网站定制 
简介《HW溯源手册V2.0》是一份面向护网蓝队、应急响应及安全运营人员的实战型攻击溯源指南按技巧篇与实战篇组织内容。手册从攻击时间、攻击IP、预警平台、恶意文件等基础信息切入讲解端口扫描、命令执行、爬虫、恶意文件等攻击类型的溯源优先级并通过攻击详情请求包识别攻击者特征针对DGA域名给出解密与后续域名预测思路。实战操作层面覆盖威胁情报平台、whois与解析记录、IP反查及定位、ID/QQ/手机号/邮箱社工搜集、恶意文件C2分析等常用手法同时整理Ida、JEB、010 Editor、Wireshark、Process Monitor、Binwalk、微步云沙箱、奇安信云沙箱等工具清单并强调多源交叉验证、避免单一证据和报告逻辑连贯。压缩包内为单个DOCX文档包体约12.19MB已有571人学习下载适合护网值守、攻防演练和应急响应时快速查阅。1. 接到 HW 溯源任务先别急着查 IP这份手册把流程拆成了一部字典凌晨两点收到 HW 预警工单群里丢过来一条攻击记录攻击 IP、攻击类型、恶意文件下载地址、被攻击域名。多数人的第一反应是把 IP 扔进威胁情报平台查一下然后等着页面刷新出结果——但这份《HW溯源手册V2.0》给我的第一个提醒是先读攻击类型再查 IP。端口扫描大多来自个人 VPS 或空间搜索引擎命令执行大概率是没做隐匿的网络或肉鸡爬虫可以直接排到最后。整本手册分技巧篇和实战篇技巧篇讲方法论和平台工具实战篇落到样本分析和跳板机操作结构上更像一部字典而不是教科书。对第一次参加 HW 值守的新人以及想把溯源流程从凭感觉变成有章法的从业者这份资源值得花一个晚上从头过一遍之后的每一次溯源都可以按需翻查。2. 攻击信息定级与溯源入口攻击类型、恶意文件、C2 地址哪条线先走2.1 攻击详情里藏着优先级端口扫描、命令执行、爬虫谁先查一次标准溯源任务拿到的信息通常只有六项攻击时间、攻击 IP、预警平台、攻击类型、恶意文件、受攻击的域名/IP。手册把攻击 IP、攻击类型、恶意文件、攻击详情列为四个入手点其中攻击类型是最先应该被读取的字段因为它直接决定了这条溯源任务值不值得花大力气。按照手册的划分端口扫描大概率为个人 VPS 或空间搜索引擎。这类攻击覆盖面广、量很大目标不是特定的一家单位所以定位到真实攻击者的概率不高但任务量大的时候反而要优先处理——扫描源的 VPS 通常没有多层跳板反查域名和威胁情报命中率高。命令执行的优先级更高大概率来自未经任何隐匿的网络、移动网络或接到脚本扫描任务的肉鸡这类攻击者还没建立起隐蔽意识请求包里可能直接带本机特征属于溯源性价比最高的一类。爬虫可以放到最后大部分爬虫来自空间搜索引擎的爬取业务和人为攻击关系不大。我一般建议在接到任务后先做一轮分类而不是直接进威胁情报平台攻击类型大概率来源溯源优先级处理建议端口扫描个人 VPS / 空间搜索引擎高量大时优先反查 IP 关联域名和证书命令执行未隐匿网络 / 移动网络 / 肉鸡高直接抓请求包特征爬虫空间搜索引擎低放最后处理恶意文件攻击者投放的样本最高提取 C2 地址并做样本分析这里的大概率三个字要划重点。手册通篇都在强调不要用单一情报来源定结论攻击类型和来源之间的对应关系是基于统计经验的不是必然。比如端口扫描的源头也可能是被拿下的跳板机命令执行也可能是伪装后的定向攻击。遇到 webshell 文件上传这类漏洞攻击类型通常会被归类到命令执行或恶意文件这两类的溯源优先级都排在最前面请求包里往往带着上传的时间点和文件路径顺着这个入口往下挖比单纯查 IP 有效得多。拿到攻击类型后下一步是分析攻击详情里的请求包看有没有攻击者特征。请求包的 User-Agent、Cookie 构造、payload 写法、请求频率都能暴露工具来源sqlmap 的 UA 特征、nuclei 的模板痕迹、手工构造和工具生成的差异。这些特征要和后续威胁情报平台的查询结果互相印证而不是单独作为结论。2.2 恶意文件的 C2 地址与 DGA 域名把溯源面放大的两个杠杆如果预警信息里带了恶意文件这条线的优先级会立刻上升。原因很简单文件本身就是攻击者的产物里面藏着比 IP 有用得多的信息。手册明确提到要从恶意文件里提取三样东西C2 地址、未删除的带有敏感信息的代码比如常用 ID、组织信息、持续化控制代码。C2 地址即命令与控制服务器地址是 APT 攻击里的核心节点拿到它之后溯源目标会变得非常聚焦——不再是被动查一个 IP 的历史记录而是顺着恶意基础设施反向摸攻击者的部署习惯。很多攻击者会在 C2 的域名注册、证书申请、服务器配置里留下同套路的痕迹比如同一批邮箱、同一家注册商、同一个证书模板。持续化控制代码比 C2 地址更值得做深度分析。如果样本采用 DGA 域名上线的方式分析出域名生成算法后理论上可以预测出之后的全部上线域名。这个能力有两个直接收益一是在攻击者下次上线前拿到域名列表通知防护侧做预封堵减少损失二是生成的域名列表本身就是新的溯源面每个域名对应的注册信息、解析记录都是可以展开的线索。DGA 分析的常见做法是先把样本丢在线沙箱跑一轮看它对外发起了哪些 DNS 请求把请求的域名收集下来然后用 IDA 定位到样本里生成域名的算法函数通常在字符串常量附近能找到域名后缀和字符集最后根据时间戳、日期或随机种子复现生成逻辑批量生成后续域名。手动逆向 DGA 的成本不低但一旦跑通拿到的就是整个僵尸网络的上线计划表。需要注意DGA 分析依赖沙箱和逆向工具的配合单纯在沙箱里等它请求域名是不够的。有些样本会检测沙箱环境而延迟执行恶意功能或者使用白名单域名的 DNS 请求做掩护这时候要多跑几轮或者在本地搭一个可控的 DNS 环境观察请求走向。3. 外围信息收集威胁情报平台、whois 反查与 IP 画像的边界3.1 威胁情报平台四个入口怎么选、误报怎么识别手册列出的威胁情报平台有四个微步在线、奇安信威胁情报、360 威胁情报、VenusEye。此外还有 ipip.net、爱站、whois.com 这类辅助查询入口。威胁情报平台能查 IP 是否被标记恶意、域名解析记录、历史 whois、子域名、SSL 证书等是整个溯源工作的第一站。但手册有一句话比任何平台能力都重要不要过于依赖威胁情报仅供参考。这些平台大多由社区维护存在误报和时效性问题平台标签可能和真正攻击者毫无关系。一个 IP 被标记恶意可能是因为五年前被某一个样本反连过也可能只是被某台中了毒的机器当跳板用过一次后面的攻防活动和这个 IP 的当前使用者没有任何关系。把这种历史标签直接写进报告是最典型的翻车姿势。我的习惯是把威胁情报当成检索工具不是结论来源。同一个 IP 在四个平台上各查一次看三个维度是否被标记恶意、标记时间距今多久、标记类型和当前攻击事件的攻击类型是否匹配。只有三者对得上才把平台结果纳入证据链。为了不被某个平台的误报带偏实际操作里还会打开攻击详情里的原始请求包确认这个 IP 在预警时间点确实发起了对应类型的请求。3.2 已知域名反查信息whois 反查、SSL 证书、解析记录与 CDN 判断当手里拿到的是攻击者域名时手册给出的展开方向有四个历史 whois、SSL 证书、解析记录、CDN 判断。历史 whois 是最容易出个人信息的一步。通过站长之家的反查入口或 RiskIQ Community 这类服务可以按注册人名称、注册邮箱、联系电话反查同一注册者名下的其他域名。很多攻击者会在不同域名里用同一个邮箱注册这一步能直接带出一批关联域名。如果 whois 信息里出现了 ID 和邮箱那后续可以跳到 3.3 的身份反查流程继续展开。SSL 证书反查是另一个方向。在证书透明度日志和资产测绘平台比如 fofa里按证书的 CN 或组织名反查拿到的不仅有域名还有证书申请时留下的 ID、邮箱信息。这里要注意证书的签发时间和到期时间过期的证书往往带着更早的组织信息反而容易暴露早期身份。解析记录要看 A 记录和 CNAME。A 记录映射域名到一个或多个 IP拿到后就能从域名跳到 IP 画像CNAME 映射域名到另一个域名通常用来指向子域名或 CDN 节点。查询工具可以用 jsons.cn/nslookup 这类在线 DNS 查询也可以直接在本地用 dig。如果域名解析到的是 CDN 节点而不是源站 IP所有基于 IP 的溯源手段都会失效这就是接下来要说的 CDN 判断。判断 CDN 的通用做法是在全球 ping 平台比如 ping.chinaz.com上跑一轮。如果多个地区的解析结果落在不同 IP 段且这些 IP 归属云服务商基本可以断定使用了 CDN。这时候继续溯源要换思路查历史解析记录里的早期 A 记录找子域名里的非 CDN 解析或者检索代码仓库里残留的源站地址都是常见做法。CDN 本身不是死路只是需要绕一下。3.3 已知 IP 与 ID/手机号/邮箱反查域名和身份的常规路径拿到 IP 后先反查域名。手册给的入口是威胁情报平台加 ipip.net、爱站、whois.com。反查思路是看这个 IP 当前绑定了哪些域名、历史绑定过哪些域名再把这些域名按上一步的 whois 和证书方向展开。反向查询的结果对判断这个 IP 是代理还是真实 IP非常关键——一个绑定了大量无关域名的 IP大概率是共享主机或 CDN 节点一个只绑定一两个域名且注册信息完整的 IP才更接近攻击者的真实资产。IP 本身的信息要分两层看。一是 IP 段所属公司ipip.net 和 CNNIC whois 可以查到 IP 段的运营商信息判断是移动网络、IDC 还是云厂商。移动网络的 IP 往往对应手机热点或随身 WiFi这类攻击者没有固定物理位置溯源结果到市一级就基本到头IDC 和云厂商的 IP 则可以继续查资产的归属方部分云厂商也提供溯源相关的工单协助。二是 IP 定位chaipip.com 和 opengps.cn 可以拿到城市级定位但定位数据只能做参考不能作为报告里的实锤——很多定位数据库的精度本身就存在误差拿它当证据容易被人一句话问倒。手里有 ID、姓名、手机号或邮箱时可以走身份反查的路径。常规操作包括用社工库反查手机号或邮箱关联的账号信息用支付宝转账功能验证姓名转一笔极小金额输入姓名看是否匹配通过部分平台的账号找回密码流程猜测注册手机号用 QQ 和微信添加好友搜索在 reg007 上查这个手机号注册过哪些平台以及去抖音、脉脉这类社交平台检索 ID 痕迹。ID 和姓名还能配合谷歌、百度、src 平台、微博、贴吧做定向搜索。这套打法在 HW 场景里确实常用但要提醒一句这部分操作要在授权范围内做收集到的个人信息只用于溯源报告的内部验证。验证的逻辑是交叉印证——支付宝转账可以核对姓名和手机号是否匹配平台找回密码流程可以验证手机号是否注册过src 和微博搜索可以确认 ID 的使用习惯。每个来源都只能算一条线索全部指向同一个人才能形成结论。4. 恶意文件分析实战magic 识别、查壳、动态调试与多线程4.1 静态三板斧magic、哈希、字符串与导入表恶意文件分析的第一步永远是识别格式而不是直接拖进 IDA。不同格式的可执行程序有不同标志信息PE 文件开头是 MZ 头ELF 文件前四字节是 7F 45 4C 46Mach-O 是 FEEDFACE 或 CAFEBABE。用十六进制解析器载入样本看前四个字节就能确定格式也可以用 file 命令自动识别。格式决定后续工具链——PE 走 IDA、OllyDbg、WinDbgELF 走 IDA、GDB固件类走 Binwalk 和 BIN2BMP。识别格式后立刻计算哈希。哈希是样本的指纹用于威胁情报平台查询和样本库比对。手册特别强调不要只用一种算法MD5 理论上存在碰撞风险所以至少要 MD5、SHA-1 一起算推荐加上 SHA-256。实际操作里我会一次性把三种都算出来写报告时直接引用完整哈希也方便和其他平台共享# 识别文件格式 file ./sample.bin # 一次性计算多算法哈希 md5sum ./sample.bin sha1sum ./sample.bin sha256sum ./sample.bin # 提取可打印字符串最少 8 个字符 strings -n 8 ./sample.bin | head -50 # 查看 PE 导入表判断是否加壳 objdump -p ./sample.bin | grep DLL Name前两条命令最基础后面两条信息量大。strings 的输出里经常直接出现 URL、IP、注册表路径、互斥体名字和特定 API 函数这些都是程序功能的提示。我一般会先看字符串里有没有 http 和 https 字样有的话就是网络行为的方向标。objdump 看导入表要配合一个经验判断正常程序导入表会列出大部分使用的函数如果文件没有被加壳导入表却只有寥寥几个函数说明程序大概率用了动态获取 API 的方式行为需要动态调试才能摸清。4.2 查壳与宏解析动手调之前先做这两件事加壳是恶意文件最常见的对抗手段。壳会把原始代码加密或压缩让静态分析看不到真实逻辑。判断加壳最容易的观察点是字符串密度正常程序总有大量的可打印字符串加了壳的程序字符串会骤减。如果 strings 几乎什么都提不出来就先用 PEiD 这类工具查壳确定壳的种类UPX、ASP 等再决定脱壳还是直接动态调试。UPX 这类公开壳需要先脱壳再分析脱壳后字符串和导入表都会恢复自定义壳更适合走动态调试直接观察行为比强行脱壳效率高得多。IDA 反汇编后另一个常见问题是宏解析。IDA 不会自动把 API 常量解析成宏名反汇编视图里显示的是一串数字比如 0x80000000 这种可读性极差的常量。如果盯着数字猜含义分析进度会非常痛苦。处理方式是在对应数字上右键选择 Enum然后在弹出的枚举类型里选择对应的宏IDA 会自动替换成可读的宏名。这样一段反汇编代码的可读性立刻提升一个台阶函数的功能也能很快看明白。静态分析进入抽象函数时我会用 OllyDbg 动态执行一下把函数跑起来看实际效果这个习惯能省下大量读汇编的时间。4.3 多线程与子进程动态调试的两个硬骨头动态调试在溯源里绕不开两个难点多线程和子进程。多线程的问题在于调试器一次只能跟一个线程样本开了多个线程后恶意行为在哪个线程里执行、什么时候切过去都需要人为干预。CreateThread 的调用有六个参数其中第三个是线程入口地址第四个是线程参数。调试时定位到线程入口设置断点是第一步。多数样本创建线程后会调用 Sleep 或 WaitForSingleObject 来等待利用这个时机让控制权转移到新线程断点就能命中。如果样本没有调用这类阻塞函数可以改代码强制它调用把控制权交过去。还有一个偏门办法是直接修改 EIP 指向线程入口同时改寄存器指向参数地址但这种方式容易造成寄存器内容不正确、环境异常导致程序崩溃一般只在前面几种方式都失效时才用。如果样本反复调用 CreateThread只保留目标线程会更省事让目标线程创建成功后直接修改 CreateThread 函数让后续调用直接返回这样就不会再有新线程创建调试环境干净也不会因为频繁切换线程而漏掉关键行为。子进程调试又是另一套思路。有些样本运行时会创建子进程执行恶意功能这时候要判断父进程创建子进程的方式。如果是以挂起suspended方式创建的父进程会先向子进程注入代码再调用 ResumeThread 恢复运行。正确做法是先确定父进程写入代码的地址在代码写入之后、调用 ResumeThread 之前附加到子进程在注入地址下断点并按 F9 让子进程跑起来然后回到父进程运行 ResumeThread子进程就会准确地断在注入地址。整个过程的关键是时机早一步代码还没写入断点不生效晚一步子进程已经跑飞再追就难了。如果是简单开启子进程的方式直接用 OD 打开子进程把父进程要传的参数带上就行。4.4 本地工具与在线沙箱怎么配合手册给了一份完整的工具清单按用途可以分成四类类别工具用途逆向分析IDA、JEB反汇编、反编译、逻辑还原文件编辑010 Editor、Winhex十六进制查看、magic 识别、文件修复网络与进程监控Process Monitor、Wireshark、科来、SRsniffer抓包、进程行为监控、网络行为分析固件分析Binwalk、BIN2BMP、PIXD固件解包、图片化分析在线沙箱微步云沙箱、奇安信云沙箱、腾讯哈勃、Joe Sandbox自动行为分析、网络请求捕获沙箱在恶意文件分析的启动阶段价值最高。把样本丢进微步或奇安信的云沙箱跑一轮就能拿到文件行为、注册表操作、网络请求、C2 地址这些基础情报比手动逆向快得多。但沙箱的结论不能直接用进报告——样本可能检测沙箱环境而伪装行为或者因为沙箱网络受限而没有完整复现恶意活动。所以我的流程是先沙箱拿方向再用 IDA 和 OD 确认具体逻辑最后用 Process Monitor 和 Wireshark 在本地环境验证一遍网络行为。如果恶意文件来自邮件附件记得把邮件全格式保存用十六进制编辑器打开原始文件。邮件头部分能直接看到发送邮件的服务器 IP这个 IP 是溯源链路里一条独立的证据线和样本内部提取的 C2 地址互为补充。很多人只保存了附件丢掉了邮件原始格式等于主动扔掉了最直接的发送者信息。5. 避坑清单溯源全过程最容易翻车的五个环节这一章是我自己翻了车之后才整理出来的。溯源这件事前期收集线索的方法大家都会真正拉开差距的是后期判断哪些信息能信哪些信息只能参考哪条线索链能支撑结论。以下是五个最常见的翻车环节每一条都按现象、原因、解决拆开讲。5.1 威胁情报误报被当成实锤现象IP 在威胁情报平台被标记恶意直接写进报告作为已确认攻击者来源。原因威胁情报平台多为社区维护存在误报和时效性问题。一个 IP 被标记可能是历史遗留也可能与当前攻击事件毫无关系。过度依赖平台标签是新手最常见的问题本质上是把别人可能过时的结论当成了自己的判断。解决同一个 IP 至少跨两个平台查比对标记时间和当前攻击事件的时间、类型是否吻合再结合请求包里的实际特征确认。平台结果只当检索线索不直接进报告。如果某个标签的时间距今超过半年而与当前事件的攻击类型不匹配基本可以判定为误报需要换一条线继续。5.2 单面证据链就把报告写死现象通过 whois 反查到一个名字就写已定位到攻击者结果复盘时发现那个邮箱是注册商随机生成的或者是攻击者盗用的身份。原因单个来源的信息无法排除巧合、伪造和失误。溯源报告最忌讳的就是单面证据链——只有一条线索指向某个人却写成确定结论。解决每个关键结论都要有两条以上独立线索支撑。比如域名注册邮箱、SSL 证书信息、社交平台 ID 指向同一个人才写进结论框架。手册要求的理想溯源结果框架里包含姓名、IP、地理位置、联系方式、社交账号等多维信息不是为了凑字数而是为了让多个线索互相印证。写报告时也要明确区分已确认和待验证避免中途溯源错人。5.3 样本分析只算 MD5、邮件头没拿全现象报告里只有一个 MD5 值攻击详情里的邮件附件没有全格式保存发送服务器 IP 直接丢失。原因图快、图省事。MD5 是哈希工具默认输出很多人算完一个就收工邮件附件只拖了附件本体不知道还要保存原始格式。解决MD5、SHA-1、SHA-256 三种哈希一起算避免碰撞也在报告里更有说服力。邮件类恶意文件全格式保存用十六进制编辑器打开邮件头的 Received 字段里能找到发送 IP。这条线特别容易被漏但它往往比样本内部的功能更能定位到真实发送者。5.4 跳板机只查了 netstat 就收工不查进程和定时任务现象在跳板机上看到可疑端口和连接就认为找到了攻击入口报告写完才发现只覆盖了最表层的信息。原因netstat 输出直观、容易满足但它只能说明系统当前的外连状态不能还原完整的攻击路径和持久化手段。解决端口、进程、定时任务、历史命令四条线全部过一遍。netstat 看到可疑 PID 后跟 lsof -i 确认进程路径ps aux 排查异常进程crontab -l 查定时任务再翻 /home 各账号下的 .bash_history 看有没有攻击者执行过的命令痕迹。四路信息交叉比对才能还原攻击者从入口到驻留的完整轨迹。5.5 请求包特征没看上来先查 IP现象拿到预警信息后第一步就是查 IP 的威胁情报查完发现情报平台没标记接着就不知道干什么了。原因把威胁情报平台当成了溯源的全部忽略了攻击详情里最基础的请求包信息。请求包里的 UA、payload、时间特征才是第一手证据平台情报只是二手加工。解决先读请求包再做平台查询。请求包能确认攻击类型、工具类型、可能的手法带着这些特征去查情报才知道要重点看什么。顺序反了容易被平台的海量信息带乱节奏。这条我吃过亏现在每次接新任务都强制按类型 → 请求包 → 平台的顺序走。6. 溯源报告收口线索串联、验证清单和 Linux 历史命令加固6.1 线索怎么串才不是孤证排除了错误分支之后剩下的事情是写报告。手册提了一个原则避免单一面石锤需要反复验证各个溯源线索要能串起来具有逻辑性。每个溯源结论都要有至少两条独立数据线支持比如威胁情报标记、请求包特征、域名注册邮箱三者指向同一人才写已定位。纯单点信息写进报告复盘时被打回的概率极高。理想报告应该包含的攻击者画像包括姓名或 ID、攻击 IP、地理位置、QQ、微信、邮箱、手机号、支付宝、IP 所属公司、关联域名、社交账号信息等能溯源到名字和所属公司是加分项。但拿不到这些也不用硬凑写清楚每条线索的置信度和验证状态比写一份全篇可能的报告有价值得多。6.2 给 Linux 历史命令加上登录 IP 和时间戳跳板机的 .bash_history 默认没有时间和来源导致排查时看不到攻击者何时登录、从哪里登录。提前加固的方法是修改 /etc/profile 里的 HISTTIMEFORMAT 配置并扩大 HISTSIZE# 保存 1 万条命令 sed -i s/^HISTSIZE1000/HISTSIZE10000/g /etc/profile # 在 /etc/profile 尾部追加 USER_IPwho -u am i 2/dev/null | awk {print $NF} | sed -e s/[()]//g if [ $USER_IP ]; then USER_IPhostname; fi export HISTTIMEFORMAT%F %T $USER_IP whoami shopt -s histappend export PROMPT_COMMANDhistory -a # 让配置生效 source /etc/profile这段配置里 HISTTIMEFORMAT 的%F %T是日期和时间$USER_IP通过 who -u 提取本次登录来源 IPhistory -a 把命令实时写入历史文件避免退出登录时才落盘的丢失风险。从那以后我排查跳板机时都会先确认 /etc/profile 有没有这套配置没有就先补上再翻历史免得证据记录上是裸的。希望帮到你。本文还有配套的精品资源点击获取 HW溯源实战：从威胁情报到恶意文件的攻击者定位全流程
简介《HW溯源手册V2.0》是一份面向护网蓝队、应急响应及安全运营人员的实战型攻击溯源指南按技巧篇与实战篇组织内容。手册从攻击时间、攻击IP、预警平台、恶意文件等基础信息切入讲解端口扫描、命令执行、爬虫、恶意文件等攻击类型的溯源优先级并通过攻击详情请求包识别攻击者特征针对DGA域名给出解密与后续域名预测思路。实战操作层面覆盖威胁情报平台、whois与解析记录、IP反查及定位、ID/QQ/手机号/邮箱社工搜集、恶意文件C2分析等常用手法同时整理Ida、JEB、010 Editor、Wireshark、Process Monitor、Binwalk、微步云沙箱、奇安信云沙箱等工具清单并强调多源交叉验证、避免单一证据和报告逻辑连贯。压缩包内为单个DOCX文档包体约12.19MB已有571人学习下载适合护网值守、攻防演练和应急响应时快速查阅。1. 接到 HW 溯源任务先别急着查 IP这份手册把流程拆成了一部字典凌晨两点收到 HW 预警工单群里丢过来一条攻击记录攻击 IP、攻击类型、恶意文件下载地址、被攻击域名。多数人的第一反应是把 IP 扔进威胁情报平台查一下然后等着页面刷新出结果——但这份《HW溯源手册V2.0》给我的第一个提醒是先读攻击类型再查 IP。端口扫描大多来自个人 VPS 或空间搜索引擎命令执行大概率是没做隐匿的网络或肉鸡爬虫可以直接排到最后。整本手册分技巧篇和实战篇技巧篇讲方法论和平台工具实战篇落到样本分析和跳板机操作结构上更像一部字典而不是教科书。对第一次参加 HW 值守的新人以及想把溯源流程从凭感觉变成有章法的从业者这份资源值得花一个晚上从头过一遍之后的每一次溯源都可以按需翻查。2. 攻击信息定级与溯源入口攻击类型、恶意文件、C2 地址哪条线先走2.1 攻击详情里藏着优先级端口扫描、命令执行、爬虫谁先查一次标准溯源任务拿到的信息通常只有六项攻击时间、攻击 IP、预警平台、攻击类型、恶意文件、受攻击的域名/IP。手册把攻击 IP、攻击类型、恶意文件、攻击详情列为四个入手点其中攻击类型是最先应该被读取的字段因为它直接决定了这条溯源任务值不值得花大力气。按照手册的划分端口扫描大概率为个人 VPS 或空间搜索引擎。这类攻击覆盖面广、量很大目标不是特定的一家单位所以定位到真实攻击者的概率不高但任务量大的时候反而要优先处理——扫描源的 VPS 通常没有多层跳板反查域名和威胁情报命中率高。命令执行的优先级更高大概率来自未经任何隐匿的网络、移动网络或接到脚本扫描任务的肉鸡这类攻击者还没建立起隐蔽意识请求包里可能直接带本机特征属于溯源性价比最高的一类。爬虫可以放到最后大部分爬虫来自空间搜索引擎的爬取业务和人为攻击关系不大。我一般建议在接到任务后先做一轮分类而不是直接进威胁情报平台攻击类型大概率来源溯源优先级处理建议端口扫描个人 VPS / 空间搜索引擎高量大时优先反查 IP 关联域名和证书命令执行未隐匿网络 / 移动网络 / 肉鸡高直接抓请求包特征爬虫空间搜索引擎低放最后处理恶意文件攻击者投放的样本最高提取 C2 地址并做样本分析这里的大概率三个字要划重点。手册通篇都在强调不要用单一情报来源定结论攻击类型和来源之间的对应关系是基于统计经验的不是必然。比如端口扫描的源头也可能是被拿下的跳板机命令执行也可能是伪装后的定向攻击。遇到 webshell 文件上传这类漏洞攻击类型通常会被归类到命令执行或恶意文件这两类的溯源优先级都排在最前面请求包里往往带着上传的时间点和文件路径顺着这个入口往下挖比单纯查 IP 有效得多。拿到攻击类型后下一步是分析攻击详情里的请求包看有没有攻击者特征。请求包的 User-Agent、Cookie 构造、payload 写法、请求频率都能暴露工具来源sqlmap 的 UA 特征、nuclei 的模板痕迹、手工构造和工具生成的差异。这些特征要和后续威胁情报平台的查询结果互相印证而不是单独作为结论。2.2 恶意文件的 C2 地址与 DGA 域名把溯源面放大的两个杠杆如果预警信息里带了恶意文件这条线的优先级会立刻上升。原因很简单文件本身就是攻击者的产物里面藏着比 IP 有用得多的信息。手册明确提到要从恶意文件里提取三样东西C2 地址、未删除的带有敏感信息的代码比如常用 ID、组织信息、持续化控制代码。C2 地址即命令与控制服务器地址是 APT 攻击里的核心节点拿到它之后溯源目标会变得非常聚焦——不再是被动查一个 IP 的历史记录而是顺着恶意基础设施反向摸攻击者的部署习惯。很多攻击者会在 C2 的域名注册、证书申请、服务器配置里留下同套路的痕迹比如同一批邮箱、同一家注册商、同一个证书模板。持续化控制代码比 C2 地址更值得做深度分析。如果样本采用 DGA 域名上线的方式分析出域名生成算法后理论上可以预测出之后的全部上线域名。这个能力有两个直接收益一是在攻击者下次上线前拿到域名列表通知防护侧做预封堵减少损失二是生成的域名列表本身就是新的溯源面每个域名对应的注册信息、解析记录都是可以展开的线索。DGA 分析的常见做法是先把样本丢在线沙箱跑一轮看它对外发起了哪些 DNS 请求把请求的域名收集下来然后用 IDA 定位到样本里生成域名的算法函数通常在字符串常量附近能找到域名后缀和字符集最后根据时间戳、日期或随机种子复现生成逻辑批量生成后续域名。手动逆向 DGA 的成本不低但一旦跑通拿到的就是整个僵尸网络的上线计划表。需要注意DGA 分析依赖沙箱和逆向工具的配合单纯在沙箱里等它请求域名是不够的。有些样本会检测沙箱环境而延迟执行恶意功能或者使用白名单域名的 DNS 请求做掩护这时候要多跑几轮或者在本地搭一个可控的 DNS 环境观察请求走向。3. 外围信息收集威胁情报平台、whois 反查与 IP 画像的边界3.1 威胁情报平台四个入口怎么选、误报怎么识别手册列出的威胁情报平台有四个微步在线、奇安信威胁情报、360 威胁情报、VenusEye。此外还有 ipip.net、爱站、whois.com 这类辅助查询入口。威胁情报平台能查 IP 是否被标记恶意、域名解析记录、历史 whois、子域名、SSL 证书等是整个溯源工作的第一站。但手册有一句话比任何平台能力都重要不要过于依赖威胁情报仅供参考。这些平台大多由社区维护存在误报和时效性问题平台标签可能和真正攻击者毫无关系。一个 IP 被标记恶意可能是因为五年前被某一个样本反连过也可能只是被某台中了毒的机器当跳板用过一次后面的攻防活动和这个 IP 的当前使用者没有任何关系。把这种历史标签直接写进报告是最典型的翻车姿势。我的习惯是把威胁情报当成检索工具不是结论来源。同一个 IP 在四个平台上各查一次看三个维度是否被标记恶意、标记时间距今多久、标记类型和当前攻击事件的攻击类型是否匹配。只有三者对得上才把平台结果纳入证据链。为了不被某个平台的误报带偏实际操作里还会打开攻击详情里的原始请求包确认这个 IP 在预警时间点确实发起了对应类型的请求。3.2 已知域名反查信息whois 反查、SSL 证书、解析记录与 CDN 判断当手里拿到的是攻击者域名时手册给出的展开方向有四个历史 whois、SSL 证书、解析记录、CDN 判断。历史 whois 是最容易出个人信息的一步。通过站长之家的反查入口或 RiskIQ Community 这类服务可以按注册人名称、注册邮箱、联系电话反查同一注册者名下的其他域名。很多攻击者会在不同域名里用同一个邮箱注册这一步能直接带出一批关联域名。如果 whois 信息里出现了 ID 和邮箱那后续可以跳到 3.3 的身份反查流程继续展开。SSL 证书反查是另一个方向。在证书透明度日志和资产测绘平台比如 fofa里按证书的 CN 或组织名反查拿到的不仅有域名还有证书申请时留下的 ID、邮箱信息。这里要注意证书的签发时间和到期时间过期的证书往往带着更早的组织信息反而容易暴露早期身份。解析记录要看 A 记录和 CNAME。A 记录映射域名到一个或多个 IP拿到后就能从域名跳到 IP 画像CNAME 映射域名到另一个域名通常用来指向子域名或 CDN 节点。查询工具可以用 jsons.cn/nslookup 这类在线 DNS 查询也可以直接在本地用 dig。如果域名解析到的是 CDN 节点而不是源站 IP所有基于 IP 的溯源手段都会失效这就是接下来要说的 CDN 判断。判断 CDN 的通用做法是在全球 ping 平台比如 ping.chinaz.com上跑一轮。如果多个地区的解析结果落在不同 IP 段且这些 IP 归属云服务商基本可以断定使用了 CDN。这时候继续溯源要换思路查历史解析记录里的早期 A 记录找子域名里的非 CDN 解析或者检索代码仓库里残留的源站地址都是常见做法。CDN 本身不是死路只是需要绕一下。3.3 已知 IP 与 ID/手机号/邮箱反查域名和身份的常规路径拿到 IP 后先反查域名。手册给的入口是威胁情报平台加 ipip.net、爱站、whois.com。反查思路是看这个 IP 当前绑定了哪些域名、历史绑定过哪些域名再把这些域名按上一步的 whois 和证书方向展开。反向查询的结果对判断这个 IP 是代理还是真实 IP非常关键——一个绑定了大量无关域名的 IP大概率是共享主机或 CDN 节点一个只绑定一两个域名且注册信息完整的 IP才更接近攻击者的真实资产。IP 本身的信息要分两层看。一是 IP 段所属公司ipip.net 和 CNNIC whois 可以查到 IP 段的运营商信息判断是移动网络、IDC 还是云厂商。移动网络的 IP 往往对应手机热点或随身 WiFi这类攻击者没有固定物理位置溯源结果到市一级就基本到头IDC 和云厂商的 IP 则可以继续查资产的归属方部分云厂商也提供溯源相关的工单协助。二是 IP 定位chaipip.com 和 opengps.cn 可以拿到城市级定位但定位数据只能做参考不能作为报告里的实锤——很多定位数据库的精度本身就存在误差拿它当证据容易被人一句话问倒。手里有 ID、姓名、手机号或邮箱时可以走身份反查的路径。常规操作包括用社工库反查手机号或邮箱关联的账号信息用支付宝转账功能验证姓名转一笔极小金额输入姓名看是否匹配通过部分平台的账号找回密码流程猜测注册手机号用 QQ 和微信添加好友搜索在 reg007 上查这个手机号注册过哪些平台以及去抖音、脉脉这类社交平台检索 ID 痕迹。ID 和姓名还能配合谷歌、百度、src 平台、微博、贴吧做定向搜索。这套打法在 HW 场景里确实常用但要提醒一句这部分操作要在授权范围内做收集到的个人信息只用于溯源报告的内部验证。验证的逻辑是交叉印证——支付宝转账可以核对姓名和手机号是否匹配平台找回密码流程可以验证手机号是否注册过src 和微博搜索可以确认 ID 的使用习惯。每个来源都只能算一条线索全部指向同一个人才能形成结论。4. 恶意文件分析实战magic 识别、查壳、动态调试与多线程4.1 静态三板斧magic、哈希、字符串与导入表恶意文件分析的第一步永远是识别格式而不是直接拖进 IDA。不同格式的可执行程序有不同标志信息PE 文件开头是 MZ 头ELF 文件前四字节是 7F 45 4C 46Mach-O 是 FEEDFACE 或 CAFEBABE。用十六进制解析器载入样本看前四个字节就能确定格式也可以用 file 命令自动识别。格式决定后续工具链——PE 走 IDA、OllyDbg、WinDbgELF 走 IDA、GDB固件类走 Binwalk 和 BIN2BMP。识别格式后立刻计算哈希。哈希是样本的指纹用于威胁情报平台查询和样本库比对。手册特别强调不要只用一种算法MD5 理论上存在碰撞风险所以至少要 MD5、SHA-1 一起算推荐加上 SHA-256。实际操作里我会一次性把三种都算出来写报告时直接引用完整哈希也方便和其他平台共享# 识别文件格式 file ./sample.bin # 一次性计算多算法哈希 md5sum ./sample.bin sha1sum ./sample.bin sha256sum ./sample.bin # 提取可打印字符串最少 8 个字符 strings -n 8 ./sample.bin | head -50 # 查看 PE 导入表判断是否加壳 objdump -p ./sample.bin | grep DLL Name前两条命令最基础后面两条信息量大。strings 的输出里经常直接出现 URL、IP、注册表路径、互斥体名字和特定 API 函数这些都是程序功能的提示。我一般会先看字符串里有没有 http 和 https 字样有的话就是网络行为的方向标。objdump 看导入表要配合一个经验判断正常程序导入表会列出大部分使用的函数如果文件没有被加壳导入表却只有寥寥几个函数说明程序大概率用了动态获取 API 的方式行为需要动态调试才能摸清。4.2 查壳与宏解析动手调之前先做这两件事加壳是恶意文件最常见的对抗手段。壳会把原始代码加密或压缩让静态分析看不到真实逻辑。判断加壳最容易的观察点是字符串密度正常程序总有大量的可打印字符串加了壳的程序字符串会骤减。如果 strings 几乎什么都提不出来就先用 PEiD 这类工具查壳确定壳的种类UPX、ASP 等再决定脱壳还是直接动态调试。UPX 这类公开壳需要先脱壳再分析脱壳后字符串和导入表都会恢复自定义壳更适合走动态调试直接观察行为比强行脱壳效率高得多。IDA 反汇编后另一个常见问题是宏解析。IDA 不会自动把 API 常量解析成宏名反汇编视图里显示的是一串数字比如 0x80000000 这种可读性极差的常量。如果盯着数字猜含义分析进度会非常痛苦。处理方式是在对应数字上右键选择 Enum然后在弹出的枚举类型里选择对应的宏IDA 会自动替换成可读的宏名。这样一段反汇编代码的可读性立刻提升一个台阶函数的功能也能很快看明白。静态分析进入抽象函数时我会用 OllyDbg 动态执行一下把函数跑起来看实际效果这个习惯能省下大量读汇编的时间。4.3 多线程与子进程动态调试的两个硬骨头动态调试在溯源里绕不开两个难点多线程和子进程。多线程的问题在于调试器一次只能跟一个线程样本开了多个线程后恶意行为在哪个线程里执行、什么时候切过去都需要人为干预。CreateThread 的调用有六个参数其中第三个是线程入口地址第四个是线程参数。调试时定位到线程入口设置断点是第一步。多数样本创建线程后会调用 Sleep 或 WaitForSingleObject 来等待利用这个时机让控制权转移到新线程断点就能命中。如果样本没有调用这类阻塞函数可以改代码强制它调用把控制权交过去。还有一个偏门办法是直接修改 EIP 指向线程入口同时改寄存器指向参数地址但这种方式容易造成寄存器内容不正确、环境异常导致程序崩溃一般只在前面几种方式都失效时才用。如果样本反复调用 CreateThread只保留目标线程会更省事让目标线程创建成功后直接修改 CreateThread 函数让后续调用直接返回这样就不会再有新线程创建调试环境干净也不会因为频繁切换线程而漏掉关键行为。子进程调试又是另一套思路。有些样本运行时会创建子进程执行恶意功能这时候要判断父进程创建子进程的方式。如果是以挂起suspended方式创建的父进程会先向子进程注入代码再调用 ResumeThread 恢复运行。正确做法是先确定父进程写入代码的地址在代码写入之后、调用 ResumeThread 之前附加到子进程在注入地址下断点并按 F9 让子进程跑起来然后回到父进程运行 ResumeThread子进程就会准确地断在注入地址。整个过程的关键是时机早一步代码还没写入断点不生效晚一步子进程已经跑飞再追就难了。如果是简单开启子进程的方式直接用 OD 打开子进程把父进程要传的参数带上就行。4.4 本地工具与在线沙箱怎么配合手册给了一份完整的工具清单按用途可以分成四类类别工具用途逆向分析IDA、JEB反汇编、反编译、逻辑还原文件编辑010 Editor、Winhex十六进制查看、magic 识别、文件修复网络与进程监控Process Monitor、Wireshark、科来、SRsniffer抓包、进程行为监控、网络行为分析固件分析Binwalk、BIN2BMP、PIXD固件解包、图片化分析在线沙箱微步云沙箱、奇安信云沙箱、腾讯哈勃、Joe Sandbox自动行为分析、网络请求捕获沙箱在恶意文件分析的启动阶段价值最高。把样本丢进微步或奇安信的云沙箱跑一轮就能拿到文件行为、注册表操作、网络请求、C2 地址这些基础情报比手动逆向快得多。但沙箱的结论不能直接用进报告——样本可能检测沙箱环境而伪装行为或者因为沙箱网络受限而没有完整复现恶意活动。所以我的流程是先沙箱拿方向再用 IDA 和 OD 确认具体逻辑最后用 Process Monitor 和 Wireshark 在本地环境验证一遍网络行为。如果恶意文件来自邮件附件记得把邮件全格式保存用十六进制编辑器打开原始文件。邮件头部分能直接看到发送邮件的服务器 IP这个 IP 是溯源链路里一条独立的证据线和样本内部提取的 C2 地址互为补充。很多人只保存了附件丢掉了邮件原始格式等于主动扔掉了最直接的发送者信息。5. 避坑清单溯源全过程最容易翻车的五个环节这一章是我自己翻了车之后才整理出来的。溯源这件事前期收集线索的方法大家都会真正拉开差距的是后期判断哪些信息能信哪些信息只能参考哪条线索链能支撑结论。以下是五个最常见的翻车环节每一条都按现象、原因、解决拆开讲。5.1 威胁情报误报被当成实锤现象IP 在威胁情报平台被标记恶意直接写进报告作为已确认攻击者来源。原因威胁情报平台多为社区维护存在误报和时效性问题。一个 IP 被标记可能是历史遗留也可能与当前攻击事件毫无关系。过度依赖平台标签是新手最常见的问题本质上是把别人可能过时的结论当成了自己的判断。解决同一个 IP 至少跨两个平台查比对标记时间和当前攻击事件的时间、类型是否吻合再结合请求包里的实际特征确认。平台结果只当检索线索不直接进报告。如果某个标签的时间距今超过半年而与当前事件的攻击类型不匹配基本可以判定为误报需要换一条线继续。5.2 单面证据链就把报告写死现象通过 whois 反查到一个名字就写已定位到攻击者结果复盘时发现那个邮箱是注册商随机生成的或者是攻击者盗用的身份。原因单个来源的信息无法排除巧合、伪造和失误。溯源报告最忌讳的就是单面证据链——只有一条线索指向某个人却写成确定结论。解决每个关键结论都要有两条以上独立线索支撑。比如域名注册邮箱、SSL 证书信息、社交平台 ID 指向同一个人才写进结论框架。手册要求的理想溯源结果框架里包含姓名、IP、地理位置、联系方式、社交账号等多维信息不是为了凑字数而是为了让多个线索互相印证。写报告时也要明确区分已确认和待验证避免中途溯源错人。5.3 样本分析只算 MD5、邮件头没拿全现象报告里只有一个 MD5 值攻击详情里的邮件附件没有全格式保存发送服务器 IP 直接丢失。原因图快、图省事。MD5 是哈希工具默认输出很多人算完一个就收工邮件附件只拖了附件本体不知道还要保存原始格式。解决MD5、SHA-1、SHA-256 三种哈希一起算避免碰撞也在报告里更有说服力。邮件类恶意文件全格式保存用十六进制编辑器打开邮件头的 Received 字段里能找到发送 IP。这条线特别容易被漏但它往往比样本内部的功能更能定位到真实发送者。5.4 跳板机只查了 netstat 就收工不查进程和定时任务现象在跳板机上看到可疑端口和连接就认为找到了攻击入口报告写完才发现只覆盖了最表层的信息。原因netstat 输出直观、容易满足但它只能说明系统当前的外连状态不能还原完整的攻击路径和持久化手段。解决端口、进程、定时任务、历史命令四条线全部过一遍。netstat 看到可疑 PID 后跟 lsof -i 确认进程路径ps aux 排查异常进程crontab -l 查定时任务再翻 /home 各账号下的 .bash_history 看有没有攻击者执行过的命令痕迹。四路信息交叉比对才能还原攻击者从入口到驻留的完整轨迹。5.5 请求包特征没看上来先查 IP现象拿到预警信息后第一步就是查 IP 的威胁情报查完发现情报平台没标记接着就不知道干什么了。原因把威胁情报平台当成了溯源的全部忽略了攻击详情里最基础的请求包信息。请求包里的 UA、payload、时间特征才是第一手证据平台情报只是二手加工。解决先读请求包再做平台查询。请求包能确认攻击类型、工具类型、可能的手法带着这些特征去查情报才知道要重点看什么。顺序反了容易被平台的海量信息带乱节奏。这条我吃过亏现在每次接新任务都强制按类型 → 请求包 → 平台的顺序走。6. 溯源报告收口线索串联、验证清单和 Linux 历史命令加固6.1 线索怎么串才不是孤证排除了错误分支之后剩下的事情是写报告。手册提了一个原则避免单一面石锤需要反复验证各个溯源线索要能串起来具有逻辑性。每个溯源结论都要有至少两条独立数据线支持比如威胁情报标记、请求包特征、域名注册邮箱三者指向同一人才写已定位。纯单点信息写进报告复盘时被打回的概率极高。理想报告应该包含的攻击者画像包括姓名或 ID、攻击 IP、地理位置、QQ、微信、邮箱、手机号、支付宝、IP 所属公司、关联域名、社交账号信息等能溯源到名字和所属公司是加分项。但拿不到这些也不用硬凑写清楚每条线索的置信度和验证状态比写一份全篇可能的报告有价值得多。6.2 给 Linux 历史命令加上登录 IP 和时间戳跳板机的 .bash_history 默认没有时间和来源导致排查时看不到攻击者何时登录、从哪里登录。提前加固的方法是修改 /etc/profile 里的 HISTTIMEFORMAT 配置并扩大 HISTSIZE# 保存 1 万条命令 sed -i s/^HISTSIZE1000/HISTSIZE10000/g /etc/profile # 在 /etc/profile 尾部追加 USER_IPwho -u am i 2/dev/null | awk {print $NF} | sed -e s/[()]//g if [ $USER_IP ]; then USER_IPhostname; fi export HISTTIMEFORMAT%F %T $USER_IP whoami shopt -s histappend export PROMPT_COMMANDhistory -a # 让配置生效 source /etc/profile这段配置里 HISTTIMEFORMAT 的%F %T是日期和时间$USER_IP通过 who -u 提取本次登录来源 IPhistory -a 把命令实时写入历史文件避免退出登录时才落盘的丢失风险。从那以后我排查跳板机时都会先确认 /etc/profile 有没有这套配置没有就先补上再翻历史免得证据记录上是裸的。希望帮到你。本文还有配套的精品资源点击获取