应急响应的内存检索领域, 三五年前还是只有取证专家才会触及的领域, 如今就已然是一线蓝队工程师的日常操作场景。处置应急响应时最让人犯难的情况不是进程扎堆不好杀干净, 而是你上手操作, 恶意进程已经全部退去, 磁盘空荡荡的清清爽爽, 攻击者仿佛没出现过一般。这类情形我碰见过不只一次, 此后便强迫自身在全套动作里补充一个环节: 先调取内存日志内容, 再着手处置其他相关事宜。

这篇文章围绕应急响应中的内存检索工具, 将自身的工具筛选、完整操作全流程、关键参数以及踩坑的经验一次性讲完整, 适配刚入行正被各类日志信息淹没的安全行业新人, 也适配带领团队的负责人拿去作为现成的排查盘点清单, 先说结论: 内存检索并非是在已有良好基础上再增添光彩, 它恰恰就是你是否能锁定恶意行为的关键分界要点。

1. 为什么得先做内存检索不可: 磁盘永远抓不到“正在发生的恶意行为” 1.1 无文件攻击与内存驻留乃是真正难缠的对手。

应急响应最常碰上的窘境堪为: 杀毒软件做完全盘扫描了, 毒没检出；日志翻了几万行了, 异常寻不出；Word文档原封在着, 邮件仍原样在着, 但你竟就是搞不清攻击者进犯而入到底干了什么事呢。这并非你的本事存在问题, 而是取证方向自身本身就出偏差了, 现下大量攻击不用恶意代码写入磁盘, 而是直接寄养在合法进程的内存当中, 惯用措施包含进程注入、内联钩子函数Hook、加载恶意脚本、无文件下载器等等。

譬如攻击者透过漏洞或是供应链渠道混入, 直接在内存中弹出一个C2会话, 整体攻击链或许仅涵盖几个命令行的字节, 毫不存在实体文件落地。你事后审视磁盘, 自然啥都找不到。可内存不一样, 进程一经启动, 它的可执行映像、加载的DLL、划分的堆栈、命令行的参数, 全留在内存里。只要系统未重启, 这些东西便很难被尽数消除。

用更贴近日常的方式来理解: 磁盘好似一本全都写满了的日记, 攻击者能够依照自己的喜好将当中某几页撕掉、涂改；内存更就如同你思索过程里的“工作台”, 其上的便签与那些半成品内容, 只要没有关机断掉电源, 就始终摊放在那儿不走。应急响应之中的内存检索操作, 就是把这些便签完完全全地进行拍照并留存, 而后一张一张依次逐张去读取和辨识下去呀。

1.2 应急处置的优先级：先保现场再谈分析

不少接到了应急响应需求的多团队, 第一反应总是是紧急断网紧急杀毒紧急隔离。这套流程过程本身倒也没错, 但问题就在于——断网操作和杀毒操作往往会伴随着进程重启, 亦或是把已经处在运行状态里的恶意程序进程直接地杀掉这么一杀。

我对此类事项的处理流程按先后依次是: 先判断可在不改变系统状态前提之下采集内存镜像, 镜像落地终结再去完成断网作业、开展隔离操作、推进杀毒步骤。也就是称, “完成保护现场这项工作”对应的任务优先级其实远高于“开展处置”这类工作。这一思路所借鉴的, 是传统刑事案件勘查工作之中的“第一现场原则”相关内容, 待到抵达现场后, 不优先翻查抽屉, 反倒是要先采取拍照的方式固定所涉所有证据。内存这一东西, 是主机方面最为重要的第一现场。

实际操作中会碰到不少噪音, 比如业务部门常会提出立刻恢复服务的诉求, 是不能和你一样等来搜集情况的；这时候就要在不加重损失的前提下, 尽可能快速抓下内存镜像, 哪怕只有一份原本的镜像放在旁边——后面分析不分析得出来是一回事, 连能不能抓住镜像又是另一回事；好多见过的案例里, 最后复盘时镜像是没留的, 关键早就已不可考, 整个应急响应要到猜猜攻击者当初留下了什么痕迹的阶段。

2. 工具链怎么搭建: 从镜像采集到分析落盘 2.1 内存镜像采集工具选型怎么选。

能采集内存镜像的工具算不上很多, 但已然够满足绝大多数场景, 我自己常用到的便是下面这几个, 各自有各自的适用针对不同方面与领域的具体使用范围。

是比较老牌的命令行工具，体积较小, U盘里边常常备用着。运行后会将整块物理内存镜像写到指定位置, 格式多半是.raw或.img, 适配7到10的多版本环境。它的优势是傻瓜化、速度较快, 缺陷是对系统自身的抗干扰性一般, 在一些被深度管控的机器上有可能先于你被执行。

RAM 是图形界面工具, 免费, 操作门槛低。选择保存路径, 请点一下，就能输出.mem格式镜像。遇到不熟悉命令行的同事, 我会优先推荐它, 至少不会出现参数敲错, 把镜像截断的问题。

这是开源工具, 命令行的灵活程度是相对更高的, 在脚本化的批量采集方面很适用, 许多人会将它封闭置入自己的应急响应工具箱里头, 配备一条指定的命令直接输出到外置存储, 我使用它去做自动化的采集还是比较多的, 因为它具备配合MD5校验的条件, 可以在采集完全完成后即刻验证镜像的整体完整性。

挑选时刻数多个细节要留意: 榜首, 须得用处理员权限运转；第二, 输出方位不许写到被查计算机主体系盘, 最合适直接写到外置USB盘或许网络同享目录, 阻挠镜像写依据介质；第三, 尽或许用与被查体系架构相同的版本, 64位体系用64位搜集东西, 32位体系用32位东西, 避开搜集效果不完全。

2.2 分析主力： 3及常用插件

采集完内存镜像, 紧接下来就是要分析, 目前主流的内存分析工具就是3, 也是我日常使用时的主力, 相较于2需要手动指定系统, 3可以自动识别操作系统的类型和版本, 省却了最让人头疼的配置环节, 对10、2019这类新出系统支持也更好。

它的插件体系覆盖了内存检索的林林总总大大小小。我这里列一份我几乎次次都跑的插件清单, 方便你径直对照使用:

插件名称 作用 适用场景

.

列举进程列表

第一轮筛查，看有没有可疑进程

.

以树状显示进程父子关系

发现异常交互启动，如启动

.

通过内存池扫描进程

对抗进程隐藏，查找看不见的进程

scan

扫描网络连接

定位外联C2地址、异常通讯

.

查看进程命令行参数

还原攻击者的具体执行命令

.

查看进程环境变量

判断进程启动来源、环境异常

.

列出进程加载的DLL

发现DLL注入痕迹

.

搜索可疑内存注入区域

定位和恶意代码片段

.

扫描文件对象

找出内存中存在的可执行文件

.

提取内存中的文件映像

导出恶意样本做进一步分析

.

生成时间线

把多个事件串起来还原攻击顺序

这套由多个插件组合到一起搭配使用的插件组合下来, 几乎已然完全覆盖进程、各类网络相关、各类命令行操作、注入技术应用、各类文件处置、各类时间线排布六个关键面向的核心操作需求。

2.3 配套辅助工具：与YARA

仅仅仅仅依靠原有手段确实不够, 我还会协同多件工具集搭配运用YARA有关常用规则去开展交叉性的验证分析。其中所涉及到的各式各样工具本身是很关键重要, 尤其在专项处理对应内存镜像这类内容时, 它会按照与专属ASCII两种特有的不同编码同时去提取各类字符串, 同时这样子做会比直接取用Linux下某专用软件砸取专属原始类raw镜像而言, 更让大家觉得能够托付依靠靠谱上许多很多。

YARA拿来做恶意代码特征匹配。先把已知攻击团伙征的、别的征的、常见远控征的写成YARA规则, 交给3批量加载规则扫描进程内存, 大幅提升检索效。本身3是支持yara扫描插件, 要是负责大型企业的网络, 还特意建议您提早整理定制规则库, 不是每次都临时凑命令。

3. 一份关于内存样本完整排查及全流程化实操的镜像采集与专用完整性校验内容为三點一以上。

拿一台真实的服务器举例。登录之后第一件事不是打开事件查看器, 而是要确认采集工具所在的外置盘是可以被访问的, 随后以管理员的身份来运行这套采集工具。

用的命令大概是这样：

winpmem_mini.exe -o E:\evidence\2025_0102_server01.raw

执行完成后，立刻计算哈希值，并把哈希记录到取证登记表里：

certutil -hashfile E:\evidence\2025_0102_server01.raw MD5
certutil -hashfile E:\evidence\2025_0102_server01.raw SHA256

这一步很关键, 后面不管是做分析或者做报告, 全得拿着这个哈希说明我分析的镜像就是这个镜像, 其中间没遭所有变造。不少团队在复盘时因为拿不來哈希, 造成整个取证链条存在较大折損。

镜像采集工作完成结束后, 才可以执行断网、隔离、终止执行恶意进程的相关处理操作动作。我看过了解到最标准合规规范工作流程是将内存镜像和磁盘镜像一同同步采集, 随后再让业务计算机主动脱离网络连接。这里需要格外提示提醒告知大家: 采集图像自身是具有留存时间周期窗口的, 计算机机器绝对不会无尽时间周期来等待你, 于是你到达现场务必要赶紧快速；但就算怎样的快都不能跨略绕开哈希值校验。

3.2 进程和网络层面筛查

于所提及分析机上我时常会将 3 装进洁净系里, 引入映照后第一轮进行运转的是进程维度下的三个插件: 、、。

python vol.py -f E:\evidence\2025_0102_server01.raw windows.pslist
python vol.py -f E:\evidence\2025_0102_server01.raw windows.pstree
python vol.py -f E:\evidence\2025_0102_server01.raw windows.psscan

把先看一遍这样的结果, 关注那些明显的地方异常点: 看上去像系统进程但路径不在此的可疑进程? CPU占用占比或者内存占用量呈现明显失常情况的进程；还有同一时刻大量同名进程一同出现存在的那种状况。

核心要点要辨看父子对应干系: 比方Word的进程底下挂着相关子进程此一属性正是危殆信号。Exe文件经由脚本宿主拉取获取, 相同值得深度钻研。进犯方常会运用白名单进程充当父进程, 由此绕过若干举动的拦束阻截。

和协同开展隐藏检测操作。假使在此内能看到某个进程项目, 而在那里却看不到, 大致可以判定该进程存在隐藏动作, 极大概率属于级别恶意代码。此时不应停止动作, 继续向下开展排查。

网络层面跑这个：

python vol.py -f E:\evidence\2025_0102_server01.raw windows.netscan

获取完了外联用址此后, 关注那些分外态端克, 久长构筑的TCP相接, 另了外海外IP址地的通信。如若内网状况里有危险谍报平台, 能够批量查问这些宗旨IP。我不提倡只看IP, 因为一点C2会放到CDN云主机上, IP自己有可以或许不“脏”, 还需求互助过程行动和流量周记志所有鉴别。

3.3 命令行、环境变量与注入检测

确认异常进程后，立刻提取它的完整命令行参数：

python vol.py -f E:\evidence\2025_0102_server01.raw windows.cmdline

命令行参数往往匿着最关键的关键信息: 下载器的执行URL、解密脚本密钥的参数、计划任务的落盘路径这类。即便文件早已删除, 这些参数仍留存于系统的内存之中。我目睹过诸多具体的案例场景, 而攻击者自认为已经彻底删除了脚本文件, 并且当初所执行的命令原文还完好无缺地停留在内存里边, 能够直接拿获跨外联的数据地址以及对应文件的哈希。

接着对可疑进程做DLL和环境变量的检查：

python vol.py -f E:\evidence\2025_0102_server01.raw windows.envars --pid 3284
python vol.py -f E:\evidence\2025_0102_server01.raw windows.dlllist --pid 3284

要是某个环境变量出现很奇异的能够被用户控制的路径注入, 又或是这个DLL列表里头包含不是系统目录底下的动态链接库的话, 就应当去考虑存在注入行为, 随后再开展一次内存的区域扫描:

python vol.py -f E:\evidence\2025_0102_server01.raw windows.malfind --pid 3284

的判定逻辑, 是查找那些具备读写执行权限、内存区段且通过扫描, 区段内容是否具备特征, 来做标记, 出现可疑区段时, 把对应的地址, 记下来, 准备后续提取。

3.4 样本提取与恶意代码落地

定位到可疑内存地址后，就要把这片内存提取出来：

python vol.py -f E:\evidence\2025_0102_server01.raw windows.dumpfiles --pid 3284 --virtaddr 0xFFFF8A0B1234

提取出来的文件莫要急于双击运行, 更勿放到一个可执行目录里。我习惯把所有dump出来的文件集中挪到某“样本暂存区”, 按PID和时间戳重新命名标位, 接着用杀毒引擎、威胁情报平台、YARA规则三重交叉核验校验。如果查实是远控木马, 就可持续提取对应进程的完整内存转储:

python vol.py -f E:\evidence\2025_0102_server01.raw windows.memdump --pid 3284

再配合的工具做字符串提取：

strings64 -n 8 -o dump_mem_3284.bin > dump_mem_3284.txt

进行搜索时, 我在先通常会搜取http协议、https协议这类和网络紧密相关的字符串, 接着才搜cmd这类常见的命令关键字以及reg类这类相关的内容。进行字符串搜索具备的价值体现在于, 即便有些恶意代码做了对应的免杀处理, 不少和网络通信的地址以及配置文件里所包含的内容, 依然会以明文的整个出现在内存里展现出来。

3.5 结合安全日志做时间线校准

内存检索给出的全是堆时间点的静态证据内容, 要还原为攻击所需串联成的逻辑完整故事件, 还需和各种安全日志里的对应时间线路条, 做详细交叉、逐一仔细比对的操作。

我习惯会同机导出安全日志里的数款重要事项: 进程创建事项（4688）、登录事项（4624）、特权动用事项（4672）以及服务装设事项（7045）, 将空间里查获的可疑进程发动时段, 和日志里4688事项记写下的进程创建时辰对应, 能加紧核实哪些进程是正经营生造出的，哪些是从打击路径上唤起的。

这里存在一个时区坑, 我已遭踩过一次坑: 即刻内存数据里留存的时刻一般来讲是UTC, 况且事件日志照旧依局部时间开展展出, 如果您直接对正整个表的话, 尤为容易冒出半个小时、八个小时的偏差。对的做法是先一致记录成UTC, 再遵守系统时区换算成你汇报里末尾需用的时间形式。

3的插件可以一次性把所有事件汇总：

python vol.py -f E:\evidence\2025_0102_server01.raw windows.timeliner

生成的时间线再配合安全日志过滤 就能比较清晰画出攻击者的动作路径: 什么时候登录进来的 什么时候启动的 什么时候外联的C2 什么时候创建的计划任务。

4. 常见问题与排查技巧实录 4.1镜像加载失败与格式识别。

实际分析时最常碰到的报错就是镜像无法识别, 直接提示文件头签名不对, 出现这种情况八成是采集环节出了问题, 比如采集过程中磁盘写满、工具版本和系统不匹配或者镜像被压缩过, 处理办法是先用工具查看镜像文件头部特征, raw格式的物理内存镜像一般能直接看到可执行的PE文件头信息, 倘若文件头看着就不像是内存页那就先回到采集现场重新确认。

另外, 采集工具生成的镜像有多种封装格式, raw、dmp、mem、img各有各的来源。你拿到其他格式先别慌, 得先尝试用官方文档说明的方式转换, 然后才能喂给分析工具——在这之后, 如果需要用到各种入口插件, 最省事的做法就是从采集之初就将镜像直接输出成raw格式。

从实战维度视角来看, 我提请团队内部把采集工具的输出参数予以规定成固定不变的既定值, 施行统一规格、统一定名规则, 进而就算换另一个不同的人去施行采集环节操作后, 开展后续工作的分析任务之时, 亦不会出现摸不着头绪、无从着手的状况。

4.2 时间线错位与系统时间被改

当对应这条时间线和对应不上该当对应不上的时间点时, 先别急着怀疑这款工具, 先把被检机器里的这套系统时间戳和对应到的BIOS时间、对应到的网络时间源、对应到的日志时间戳一同都摆出来看一下瞧。有许多攻击者在攻陷入侵这个系统过来之后就会这么做把该系统里的时间给篡改掉了, 这最终目的目的就正是为了要让人使这个日志的时间线出现全部失真了, 全部扭曲了。这种这个处境该情况情况之下, 这个存在于该内存里的这相关的时间戳反而有可能才算是你想要彻底还原还原所有真相的唯一对应所依据。

我自身习惯于的处置方式: 在采集镜像那一刻, 将系统时及硬件时同步截屏留存下, 还记下来与标准时间源间的差值。后续开展研判时, 单凭镜像内部记载的时间为准认, 外加已知时间偏移量进行复原才可。绝对不能在研判机上强制改动系统时区以迁就被检查的机器, 这样非常易于污染其他证据具的时间脉络线。

4.3 误报、漏报和干扰

内存检索确实存在误报率这种状况。举例来说企业内部所用的杀毒软件进程, 其行为模式会和恶意软件十分相似, 会打开网络连接、往其他进程里注入东西、对文件做加解密, 如果不提前搭建白名单基线, 非常容易把安全软件辨识成攻击程序。因此我进行正式分析之前, 先让客户提供一份有关键业务进程、杀软进程、常用运维工具的清单, 先把整盘局面掌控住, 再专门注视真正可怀疑的进程。

漏报则更难防。在售的内存驻留手法十分之多, 恶意代码将尝试修改内核数据结构、挂钩系统调用, 让这类基于活性进程链表遍历的插件失效。对策是把、、这类基于内存池扫描的插件组合在一起, 从底层处找留存的对象痕迹。如果撞上了内核级别的, 分析仪本身亦要做好隔绝, 避免在分析进程里触发样本动作。

4.4 大内存机器与资源瓶颈

目前诸多生产用服务器内存已然突破64GB、128GB乃至更甚, 采集所得镜像动辄几十GB之巨。剖析此类镜像, 对于分析机的内存还有CPU全都是不算小的考验类问题。倘若分析机相关配置有所欠缺, 插件启动运行定就会卡到生不如死般难以置信。

可选择的解决思路哦仅两项。第一是做目标导向型分析先而非急于运行全量插件, 结合第一轮运算得到的各项结果, 仅针对那些可疑进程开展后续的dump相关操作哦与检索环节；第二是选用云主机亦或高速工作站这类设备来运行大镜像类内容，将分析环境交由独立设备把控与把处理能力合理拆分出来。你只要持有原镜像的哈希这类数值的内容, 不论把它放在何种类型的, 无论其处于何地的机器上运行, 形成的证据链哦皆完全具有成立的效力, 不存任何歧义之误。

另外, 对超大镜像执行提取时, 建议提前做好内存和磁盘空间评估。用跑64GB镜像时, 习惯把输出结果直接写到独立大容量磁盘, 并配合-n 8提取长度不少于8字节的字符串, 避免生成几GB的垃圾文本。

写在后面的一些经验

由自身踩过的各式坑里便可得见, 内存检索工作的优劣, 较多情形并非工具的症结, 实为流程的困局。诸多团队直至完成检测响应需拟写报告之际, 竟发觉竟连最为基础的内存镜象均未有留存, 可凭借残缺不全的记录硬行推演, 后续我给自己订下如此铁规: 但凡步入了应急场合, 第一优先之举措始终为采集内存镜像, 而后再探讨分析、处置及恢复。

最后再分享一个小技巧: 写成一个批处理脚本把整套3的常用命令, 配合你自己的YARA规则和威胁情报接口, 放进标准的应急响应工具箱里。这样换了一个现场就算经验不足的同事去操作, 不会因为也命令行参数记不全, 关键证据错过。

对, 分析完之后记得把提取出的样本、对应的哈希、分析结论还有时间线统一归档好, 做出的这个东西既是你给客户或者是领导的交付物, 也是下一次碰上同类的样本的时候最快的参考, 内存检索不是一回性的表演, 它应该要变成应急响应里头的常规动作的说?