第一次真正开始做恶意软件分析时,我面对一个已经中招的电脑,脑子里全是“接下来该点哪里”的困惑。那个阶段帮了我大忙的,不是某款昂贵的商业沙箱,而是一套可以随身带着跑的免费工具:Sysinternals。读了不少相关书籍和文档之后,我把它们梳理成了一份自己的笔记,其中最核心的部分,就是3个工具的组合拳打法——用Process Explorer看进程、用Autoruns看启动、用TCPView看网络。这篇博文就是我的读书笔记整理,目标是给同样刚入门的分析员或者做应急响应的朋友一条清晰的路径:不需要一开始就上很重型的手段,先用这套组合拳,把样本的“现在在哪、如何开机自启、正在和谁联系”这三件大事摸清楚,后面怎么处置都顺手很多。
1. 为什么这三款工具能成为恶意软件分析的首选勘察装备
1.1 Sysinternals工具的核心设计哲学
Sysinternals工具集从诞生之初就带着一个非常朴素的理念:一切分析和排障都从系统自身的“现场数据”出发,而不依赖外部监控设备。恶意软件无论怎么隐藏,只要它要在某台机器上运行,就一定会留下活动的痕迹。这些痕迹通常包括:一个进程、一个文件路径、一些注册表键、若干网络连接。问题在于Windows自带的任务管理器、资源监视器虽然能看到部分数据,但信息粒度远远不够——看不到进程的完整路径,看不到父进程是谁,看不到加载了哪些模块,更不便于批量核对签名。而Sysinternals家族里的Process Explorer、Autoruns、TCPView,恰好把这三块短板补上了。
读那几本恶意软件分析书籍时,反复出现的一个观点让我印象很深:分析恶意软件的起点不是“猜测它做了什么”,而是“观察它在系统上做了什么”。前者容易陷入分析师的主观臆断,后者则是客观事实堆积。Sysinternals这些工具的价值就是服务于后者。它们都是绿色软件,解压即可用,不需要安装,对分析机本身侵入性很低,这对于保护取证现场非常重要。我自己的习惯是专门准备一个U盘,里面放上一套对应架构(64位/32位)的Sysinternals工具,遇到现场需要就直接跑起来。
这套工具的另一个设计特点是从底层API获取数据。Process Explorer可以查看到比任务管理器更深的进程信息,例如进程令牌、句柄、内存分页情况;Autoruns会扫描系统所有常规的自动启动位置,不只是注册表的几个Run键;TCPView则直接订阅系统套接字状态变化,能捕捉到快速断开的一次性连接。这些能力都来自它对Native API层数据的读取和汇总,所以比普通系统监视工具看到的东西更多也更真实。
1.2 “组合拳”的含义:三种工具承担的三个分析阶段
组合拳这个词是我在整理笔记时自己总结的。单看其中任何一个工具,都有其局限性:Process Explorer只能说明进程此刻在运行,说明不了它下次开机是否还会跑起来;Autoruns只能说明有哪些东西会自启,但不知道自启后会做什么;TCPView只能看到网络连接的现状,但如果样本连完就断开或被主动结束,单纯靠它未必能捕获到完整的通信特征。把三个工具串起来之后,覆盖的分析阶段就完整了:
- Autoruns解决的是“持久化”问题:恶意软件如何确保自己在系统重启后依然存活?
- Process Explorer解决的是“运行态”问题:此刻系统里到底有什么进程在跑,它们从哪里来,加载了什么,父进程是谁?
- TCPView解决的是“通信”问题:当前或历史连接中,哪个进程在对外通信,目标地址和端口是什么?
笔记里我画过一张很概括的流程:先通过Process Explorer发现可疑进程,顺着进程的路径和启动项去Autoruns里找对应的持久化入口点;同时通过TCPView观察这个进程的外联IP和端口,再去威胁情报平台核对这个地址的关联信息。这三者互为印证,任何一个单一工具做不到这种交叉验证。
1.3 这套组合拳适用与不适用的场景
适用场景很清晰:处理一台已经疑似中毒的机器,做初步检测与研判,或者应急响应时快速判断感染范围。尤其适合还没有部署EDR等终端检测产品的小规模环境,或者经验不足的分析员练手阶段。
不适用场景也需要提一下。如果目标是抓捕一个已经结束运行、且完全没有持久化设计的无文件攻击,那么这三个工具就都不够——那种情况下需要内存取证工具或更专门的日志分析手段。另外,如果样本运行在完全隔离的离线环境,TCPView能看到的只有本机内部连接,无法揭示外联目标。理解工具的能力边界,比掌握工具本身更重要,这是我读那本笔记类书籍时最大的收获之一。
2. Process Explorer:从进程列表里揪出伪装的恶意进程
2.1 用“验证签名+查看路径”快速排除正常的系统进程
打开Process Explorer的第一眼,你会看到一棵进程树,和任务管理器不同的是,它默认按照父子关系展示,并且每个进程下面直接列出PID、描述、公司名称、完整路径。这个视图本身信息量就非常大。恶意软件分析中,我最先做的事情是开启签名验证功能:菜单栏“选项”里选择“验证图像签名”,或者在进程属性里直接查看“图像”选项卡中的签名状态。
系统正常进程通常都有微软或对应厂商的数字签名,签名验证可以立刻筛掉大量“看起来可疑但其实是正常系统组件”的目标。一个进程签名显示“无法验证”或“未签名”,同时路径又在用户的临时目录、下载文件夹或AppData等位置,那它就值得被重点怀疑。这种情况下恶意样本最喜欢伪装成svchost.exe或explorer.exe,但真实路径往往不在System32目录下。我记得一次实际的排查中出现过一个进程名为svchost.exe的样本,路径却指向C:\Users\某用户\Roaming。
查看路径之后还要核对父进程。正常的系统服务进程,父进程是“services.exe”或者“wininit.exe”;而一个由Office宏启动的样本,父进程往往是WINWORD.EXE。如果看到一个svchost.exe的父进程竟然是浏览器或文档阅读器,那几乎可以直接判定异常。这个逻辑是Process Explorer教给我的最重要的分析思路之一:判断可疑不能只看进程名字,更要看启动来源。
2.2 查看进程加载的DLL与线程栈,定位注入行为
双击进程打开属性窗口,里面有“线程”、“TCP/IP”、“字符串”等多个标签页。“字符串”标签专门用来浏览进程内存中的可读字符串,虽然数据量大,但它不需要额外下载工具就能在Process Explorer里直接完成,非常适合现场快速判断工具行为,比如看到罕见URL或命令行参数。
在“线程”标签里,可以查看每个线程的入口地址和栈信息。很多注入型恶意软件会通过远程线程或内存加载方式执行代码,线程栈中会出现指向“未标记映像”的模块。遇到这种情况,保存一份进程转储文件(右键进程选择“创建转储”)会更稳妥。虽然Process Explorer创建的转储文件主要用于故障分析,但分析恶意软件的代码逻辑时也是重要的参考材料,它至少保留了当前内存中的模块状态。
我在笔记里专门记录了一个动作顺序:看到可疑进程后先不去杀它,而是先打开进程属性,检查它的镜像路径、命令行、父进程,再查看线程列表确认是否存在被注入的模块。如果进程正在与外部通信,先截屏保存这些证据窗口,后面分析和报告都会用到。
2.3 用在线扫描服务交叉验证可疑文件
关于交叉验证,我需要特别说明一点:如果你是直接在一台用于分析的虚拟机里打开一个可疑样本,先不用急着拿它在线的扫描服务查询;但如果样本文件本身已经隔离保存,用在线扫描平台验证其恶意性是规范操作。
在实际分析中,我会把Process Explorer里看到的异常文件路径和哈希记录下来。多数在线扫描平台都支持按哈希查询,不需要你上传文件。比如一个进程路径C:\Users\Public\cache.exe,我会先右击进程属性,查看“图像”选项卡里显示的哈希值或者直接计算文件SHA256,再去在线平台查询。跨平台查询的价值在于快速判断这个文件是否已经被其他人研究过,从而初步了解它属于哪个家族、典型行为是什么。要注意的是,在线平台结果只能作为研判参考,不能作为唯一证据,因为有些新样本还没有被收录,也可能被反病毒引擎误判。
3. Autoruns:把持久化后门从开机启动链里挖出来
3.1 为什么处置恶意软件必须先看自动启动位置
一旦确认系统被感染,除了正在运行的可疑进程,更关键的问题是:它下次开机还会不会重新出现?恶意软件要保证生存,普遍会采用某种持久化手段。它们可能写入注册表Run键、创建计划任务、注册服务、安装驱动程序、添加启动文件夹,或者利用WMI的事件订阅机制。
Autoruns的界面把这些自动启动位置分类地列出来,无论哪种手段,它都会把对应的启动项注册信息扫描出来。我第一次用的时候对着满屏条目有点发呆,太多太多了。后来习惯了一个操作:在“选项”中勾选“过滤占位符”,再启用 “隐藏微软签名项”和“隐藏空项”,屏幕会一下子干净很多。这一步非常关键,它帮我们排除绝大多数正常系统组件,留下的才是需要我们逐条核对的第三方启动项。
但需要注意,自动隐藏微软签名并不等于绝对安全。某些恶意软件会偷用合法的签名或复用被签名过的白加黑文件,所以即便签名正常,如果它的文件位置异常、入口点可疑,依然不能掉以轻心。更稳妥的做法是把隐藏微软签名的视图作为“初始筛查视图”,然后复查一遍未被隐藏的那些条目。
3.2 如何高效排查启动项日志
排查启动项的正确姿势,不是盯着Autoruns界面一次看十条然后慢慢滚动,而是先把结果导出保存。我在做分析时一定会先点击“文件-保存”把autoruns结果导出成文件,再打开这个文件用表格来逐行看。为什么这样做?因为导出之后可以记录时间点,后续如果再发生感染,能对比前后差异,直接看出新增启动项。
在实际排查时,我还习惯使用Autoruns的“跳转”功能:右击某个启动项,选择“跳转”,它会直接打开注册表编辑器定位到对应键值,或者打开对应的文件所在目录。这种溯源能力在应急响应时非常有用——你能立刻搞清楚这个自启动项的配置来源,并能顺手查看文件创建时间、修改时间等时间线信息。
有一类典型的恶意启动项长这样:注册表项位于HKCU\Software\Microsoft\Windows\CurrentVersion\Run,名称看起来像是“SecurityUpdate”,值指向C:\ProgramData\某目录\wupdate.exe。如果跳过签名隐藏步骤,这种条目可能淹没在大量“微软更新”相关的正常项中。而真正核对下来,这个文件可能压根没有签名、路径不常见、创建时间也很可疑。
3.3 我在读启动项时的判断顺序
我在笔记里给自己定了这么一套判断顺序,分享给同样在做分析的朋友参考:
- 先隐藏所有微软签名项,扫一眼剩下的第三方启动项,数量多不多,有没有特别陌生的条目。
- 对每一个第三方启动项,看三层信息:一是文件路径是否处于常见的用户目录、临时目录;二是发布者签名是否可信;三是启动时间是否与用户报告的中毒时间吻合。
- 遇到可疑项,先不要禁用或删除,先记录它的具体位置和值,再用Process Explorer核对该文件当前是否正在运行,用TCPView核对该进程是否正在外联。
启动项分析最忌讳的一点就是急着删。删除操作会破坏现场,如果你还没有收集到足够证据,后续想判断传播路径或者提取样本都会变得困难。我在处理这类问题时,采取的思路是先隔离和拷贝文件,再考虑禁用启动项。
4. TCPView:顺着网络连接找到外联通信的元凶
4.1 网络连接表里到底该看什么
TCPView打开后是一张不断刷新的TCP/UDP连接列表,每一行都有自己的进程、协议、远程地址、远程端口和状态。很多书里都会告诉你“看哪些连接是ESTABLISHED”,但我觉得更有价值的是看“每个连接属于哪个进程”。TCPView特别方便的一点是,右键任意进程可以快速定位到进程对应的可执行文件路径,也可以直接跳转去Process Explorer查看它的完整信息。
分析网络连接时,我通常会关注下列几类信息。第一类是从高到低的远程端口,比如常见恶意样本外联到8080、8443、8888等非标准端口,虽然正常软件也可能使用这些端口,但出现在可疑进程上就是更强的信号。第二类是远程地址分布,如果大量外部IP集中在某些地区或某些IDC段,就要留心。第三类是UDP连接,一些僵尸程序使用UDP做心跳或指令接收,且UDP没有明显的连接状态,容易被普通工具忽略,而TCPView能显示UDP端点。
4.2 反连Shell的识别特征
Remote Shell这个概念对于做恶意软件分析的人来说应该不陌生,就是一个交互式命令行的网络连接。通过TCPView看到的最直接反连特征如下:
- 一个进程持续保持与某个远程IP的ESTABLISHED连接,连接长时间不变。
- 进程名与正常的Shell进程很像,在网络连接列表中频繁出现。
- 连接方向的端口通常是非标准高位端口,也可能是HTTP常量端口用来隐蔽。
遇到这类特征,我会立刻把目标进程在TCPView窗口里右键暂停进程活动,或先记录下所有与之相关的remote address和port,再去威胁情报平台查询这些地址有没有反连、C2等标签。需要说明的是,TCPView展示的是实时的套接字状态,TCP握手已经完成的状态它会显示ESTABLISHED,而一些恶意程序可能采用TCP连接后立刻断开的方式,这样在TCPView上就留下了TIME_WAIT或CLOSE_WAIT状态。这意味着排查时要留意那些状态异常的连接,而不是只盯着当前正在通信的连接。
4.3 结合“监听端口”看后门
TCPView除了看主动外联,也能看本机监听的端口。恶意软件经常会开启某个监听端口,用来接收攻击者后续的指令或反向连接。如果在一个通常不开放端口的进程上看到LISTENING状态,尤其是在非系统进程上,那就需要提高警惕。
我遇到过一个典型的后门场景:一台办公电脑上,某个正常办公软件所在目录里多了一个dll文件,进程运行后TCPView显示该进程一直处于LISTENING状态,监听一个不常见的端口。表面上看它没有任何外联连接,但如果攻击者从互联网直接连接这个端口,就能获得一个反向Shell。这种情况如果不看监听状态,只关注外联连接,很容易被漏掉。所以在整理笔记时,我把“看外联”和“看监听”放在一起,统称为“完成通信行为分析”的两个侧面。
5. 组合拳的实际打法:一次典型样本的完整排查链
5.1 先用Autoruns还是Process Explorer
很多人会纠结先打开哪个工具。我的习惯是先跑Autoruns,再根据启动项结果打开Process Explorer。原因很简单:如果一台机器的恶意进程已经退出了,Process Explorer看不到可疑进程;而Autoruns里的可疑启动项依然会保留。先确认持久化痕迹,再追查运行态,整个过程不容易漏掉关键证据。
当然,也有相反场景——用户报告电脑非常卡,明显有进程占高CPU,这时直接用Process Explorer按CPU使用率排序,看到可疑进程立刻定位,再去Autoruns里看它如何开机自启。这条路径适合“正在发作中”的顺手分析。无论是哪种路线,最终都会落到同一个交叉确认的闭环:启动项到文件到进程到网络。
5.2 一份尽量完整的排查记录模板
笔记里我为自己设计了一个记录模板,实战中反复修改过很多次,这里整理了一个简化版。逐台主机排查时,我至少会记下如下内容:
- 机器名/IP/排查时间;
- 可疑进程名、PID、完整路径、签名状态;
- 进程父进程和启动命令行;
- 对应的启动项位置(注册表路径或启动文件夹路径);
- 进程网络连接的目标IP、端口、连接状态;
- 文件SHA256、文件创建时间/修改时间;
- 执行的验证动作,比如是否已隔离文件,是否禁用了启动项。
字段不需要多花哨,关键是稳定和完整。排查时每一台主机都要走一遍同样的流程,这样后续做关联分析、判断感染范围时才有足够的数据支撑。记录时尽可能用无格式文本,方便归档和分析,同时避免书写过程中因格式转换丢失信息。
5.3 组合拳之外的“第4把工具”及其边界
三个工具的组合拳解决的是最常见的三类问题,但它不是万能的。笔记里我最后都会加一个提醒:在Process Explorer、Autoruns、TCPView之外,还要准备好一个“第4把工具”——Sysinternals Suite里的Procmon(Process Monitor)。Procmon可以记录文件系统、注册表和网络活动的完整日志,它对判断某个样本在运行时具体访问了哪些文件、哪些注册表项,具有不可替代的价值。它更适合做深度行为分析,而组合拳适合做快速筛查和定位。
做恶意软件分析的初学者,往往希望用一把工具解决所有问题,但现实是每种工具都只能揭示系统的一个侧面。组合拳的精髓在于,用这三面镜子照出来的同一个影子,相互印证之后才更接近真相。读了几本相关的书,又把它们的要点在虚拟机里演练了几十次之后,我的体会是:工具本身并不复杂,真正值钱的是面对一个未知样本时,心里有一套清晰的问问题和找答案的流程。Ctrl+L这个快捷键我在Process Explorer里用得比什么操作都多,仔细观察,它帮你打开的,不只是进程列表,而是洞察系统运行态的入口。