从发现SMB共享到还原恶意载荷这次靶场实战我完整走了一遍攻击链路分析。整个过程最有意思的不是某个单一技巧而是把“SMB共享里拿到pcap”这个偶然发现一步步变成一份可落地的溯源结论和可验证的载荷样本。下面把这次操作的完整路径、踩坑点、修复思路全部记录下来供做流量分析和应急取证的朋友参考。提示以下所有操作均在我自己搭建的授权靶场环境中完成目标IP、账号、口令均为模拟数据不要对未授权系统执行任何类似测试。流量分析是典型的蓝队工作目的是把攻击者的行为、工具、样本从网络证据中还原出来。1. 场景复盘为什么SMB共享里会躺着一份pcap1.1 这次实战的靶场拓扑与角色靶场里有三台机器一台Linux主机模拟内网文件服务器开放了SMB共享一台Windows机器模拟被攻陷的业务主机我所在的工作机运行Kali承担流量分析和取证工作。攻击者先前通过弱口令进入文件服务器在内网横向移动过程中留下了不少痕迹。靶场管理员把攻击发生时段抓取的pcap文件放进了一个共享目录要求我通过SMB把包拿回来分析攻击者的行为并提取出恶意传输载荷。这个设定的现实意义在于真实应急响应中经常遇到交换机镜像流量拿不到、终端日志不全的情况而文件服务器上的共享目录反而成了证据集中地。攻击者可能把自己抓的包、落地的脚本、临时工具都放在某个共享里这些文件就是还原攻击链的关键线索。1.2 一条SMB链路藏着两条故事线SMB在这个场景里是双重角色。一方面攻击者利用SMB做横向移动、枚举共享、传输工具445端口上的交互本身就是攻击行为记录另一方面取证人员也要用SMB把pcap下载到本地分析。同一套协议攻击者用过的痕迹和取证者留下的操作记录会在同一个共享目录里交叠分析时必须先分清楚哪条流量是攻击者的哪条是管理员或自己的。所以拿到pcap后第一步绝对不是打开Wireshark就开始滚包而是先确认你手里的这份pcap是谁抓的、覆盖了什么时间段、文件本身是否完整。这个习惯能避免后面分析完全跑偏。1.3 pcap作为“证据”的文件完整性问题通过网络传输的pcap文件存在被截断或篡改的风险尤其是经过SMB下载时如果会话中途断开本地拿到的文件可能比源文件少了几KB而Wireshark对这种尾部截断的包往往能正常打开只会提示“File appears to be truncated”。如果不校验直接开始分析丢失的尾部数据可能恰好包含攻击者的最后一步操作。因此在下载完成后我会先用file确认格式再算一次MD5和SHA256和源文件的哈希对一下。后面提取载荷、复现分析步骤时这个哈希也是保证证据同一性的依据。2. 从Kali挂载SMB共享把pcap拿到本地2.1 先探测共享列表再决定要不要登进去我不建议拿到一个IP就直接用账号密码登录SMB先探测共享列表的成本更低、信息更足smbclient -L 192.168.10.20 -N-N表示匿名枚举。靶场里这台服务器的SMB配置没有关闭匿名枚举所以能直接看到共享名列表。输出里会出现evidence、public、IPC$等共享名。这一步的价值在于不用猜目录路径共享名本身就是线索。如果目标环境禁止了匿名枚举-L会返回Access Denied那时候再考虑用已知的低权限账号登录。2.2 匿名与低权限账号两条登录路径遇到允许匿名访问的共享直接进smbclient //192.168.10.20/evidence -N如果匿名失败尝试用靶场提供的最低权限账号例如smbclient //192.168.10.20/evidence -U audit%Passw0rd这里有个细节真实场景里不要一上来就用管理员账号。先用最低权限账号摸清目录结构确认目标文件的位置后再考虑提权或临时开启读写权限。靶场里evidence共享是只读的但这不影响下载pcap反而能避免误改证据文件。2.3 有技巧地翻目录、拉文件进入smbclient交互界面后我的习惯是先看根目录再逐层深入smb: \ ls smb: \ cd pcap smb: \pcap\ lsls输出每行包含文件的日期、时间、属性、大小和名称。留意那些大小异常或时间戳集中在攻击时段的文件。找到目标后用mget批量拉取smb: \pcap\ prompt off smb: \pcap\ mget *.pcapprompt off的作用是让mget批量下载时不再逐个询问确认。如果共享目录层级很深可以用recurse ON开启递归再配合mget把整个目录树拉回来。图形界面爱好者也可以挂载到本地再浏览sudo mkdir -p /mnt/smb_share sudo mount -t cifs //192.168.10.20/evidence /mnt/smb_share -o usernameaudit,passwordPassw0rd挂载方式在文件数量大时确实更顺手但交互式smbclient有个优势——它能保留服务器端的文件时间戳信息方便你在下载前做初步时间判断。2.4 下载之后先做完整性校验文件落地后立刻执行file evidence.pcap md5sum evidence.pcap sha256sum evidence.pcapfile命令应该输出pcap capture file或pcapng capture file以及对应的抓包引擎版本。如果输出成了data说明下载过程可能出了问题。算完哈希后和共享目录里记录的原始哈希对比。靶场里管理员事先提供了原始哈希所以我能在这一步就确认文件没有被篡改或截断。3. Wireshark初步摸排不要一上来就滚包3.1 三个统计面板先建立全局观拿到pcap后直接用Wireshark打开第一件事不是翻数据包而是打开Statistics菜单下的三个面板Protocol Hierarchy展示各层协议的比例。如果看到SMB2占了很大比重说明这份包确实抓到了大量文件共享流量如果HTTP和DNS也不少攻击者的载荷投递很可能走了Web通道。Endpoints按IPv4标签页统计所有通信端点最活跃的IP会被顶到最上面攻击者和受害主机的轮廓就出来了。Conversations按TCP标签页看会话流量大小。字节数最大的TCP会话往往对应文件传输优先跟进。这三个面板能在30秒内告诉你“这份包里发生了什么级别的通信”避免直接滚包被海量SMB流量淹没。3.2 按协议定位可疑会话全局观建立后再针对性地用显示过滤器缩小范围。我常用的过滤条件smb2 smb ntlmssp http.request dns tcp.port 445smb2过滤所有SMB2协议报文配合ntlmssp可以快速找到认证过程。http.request用于定位HTTP请求很多工具下载动作都会在这里暴露。如果只关心445端口的通信直接用tcp.port 445。另外我在分析时会顺手打开Edit-Preferences-Protocols-TCP确保勾选了Allow subdissector to reassemble TCP streams。不勾这个选项的话某些应用层数据会因为在多个TCP段之间分布而显示不全这也是不少人遇到“怎么只显示520字节、看不到后面的2090字节”这类问题的原因——不是包丢了是Wireshark默认没有把分段的TCP流重组起来。3.3 快速还原攻击时间线在Wireshark的包列表里默认第一列是序号第二列是时间。点击时间列按升序排列然后看最早出现的高风险流量。靶场这份pcap覆盖了大约40分钟我在第3分钟就看到了对445端口的TCP SYN扫描第6分钟出现NTLM认证失败第15分钟出现了大量SMB2写入操作第20分钟后转向HTTP下载。把这些时间点记录下来攻击链路的时间线就基本成型了。3.4 顺手把pcap导出为txt做二次检索某些分析思路在图形界面里操作太慢我会用tshark把关键字段导成文本再做二次检索tshark -r evidence.pcap -T fields -e frame.number -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e _ws.col.Info traffic_dump.txt这个文本文件可以用notepad、grep或Python脚本检索比如找出所有HTTP请求的URI、统计可疑IP的会话频率。很多藏在图形界面下的规律在纯文本检索时反而更容易跳出来。4. 溯源攻击者从流量里拼出对手画像4.1 扫描与枚举阶段的指纹在pcap最开头我找到了一连串目的端口为445的TCP SYN包源IP是10.10.10.5目的IP覆盖了靶场内网的多台主机。这个行为符合端口扫描特征大量SYN、没有完整的三次握手、目标端口集中在445。继续顺着10.10.10.5过滤能看到它随后对192.168.10.20的445端口发起SMB连接并做了Tree Connect尝试访问IPC$。IPC$是SMB的进程间通信共享攻击者访问它往往是为了后续的命名管道操作或暴力枚举。这些动作叠加起来基本可以判定10.10.10.5是攻击入口。4.2 认证过程里的用户与主机线索过滤ntlmssp可以看到NTLM认证包。Wireshark对NTLMSSP的解析比较友好会在Info列显示NTLMSSP_AUTH这类字段。点开详细视图重点关注NTLMSSP: User nameNTLMSSP: Domain nameNTLMSSP: Host name靶场pcap里出现了两次失败的认证尝试用户名是administrator第三次尝试换成了backup账号并成功建立了Session。这个细节很重要说明攻击者没有盲目爆破而是通过某种方式获取了有效账号信息后精准切换了用户名。4.3 横向移动与载荷投递的关联证据顺着成功认证后的SMB2流量我看到192.168.10.20把某个文件写入了admin共享目录文件名是svcmonitor.ps1。几乎在同时192.168.10.20向另一台主机发起HTTP请求目标URI是/download/a2b3e4.binUser-Agent是curl/8.0.1。到这里攻击链已经清晰起来10.10.10.5通过SMB横向移动把PowerShell脚本投递到文件服务器再通过HTTP从外部下载一个二进制载荷。两条线索指向同一个攻击者时间点紧挨着。4.4 把零散证据整理成溯源结论我习惯把分析结论整理成一张表方便汇报和后续检索时间点源IP目的IP协议行为特征分析结论00:03:1110.10.10.5192.168.10.0/24TCP大量SYN到445端口扫描00:06:2410.10.10.5192.168.10.20SMB2匿名枚举共享共享枚举00:08:3710.10.10.5192.168.10.20NTLMSSP失败的认证账号试探00:09:1210.10.10.5192.168.10.20NTLMSSPbackup账号成功获取权限00:15:40192.168.10.20192.168.10.20SMB2写入svcmonitor.ps1载荷投递00:21:03192.168.10.20外部IPHTTP下载a2b3e4.bin载荷下载这张表就是溯源报告的核心素材。每一行都要能从pcap里找到对应的原始数据包不能凭印象写结论。5. 提取传输载荷把藏在协议里的文件抠出来5.1 为什么“右键另存”经常失败很多新手直接从Wireshark的包列表右键选择“导出分组字节流”结果拿到的文件打不开。原因在于网络层与应用层之间存在分段、封装和编码直接导出的字节流可能只包含某个TCP段的数据或者在SMB报文里还夹着SMB2头部、长度字段等协议元数据根本不是完整文件。正确思路是先判断这个文件是怎么传的如果是HTTP下载优先用File-Export Objects-HTTP如果是SMB写操作优先用File-Export Objects-SMB。Wireshark的导出对象功能会自动处理SMB/TCP重组拿到的文件已经剥离了协议头。5.2 用tshark批量导出HTTP对象命令行做批量导出更高效mkdir -p /tmp/exp_http tshark -r evidence.pcap --export-objects http,/tmp/exp_http执行后/tmp/exp_http目录下会出现所有从HTTP流量中还原出来的对象文件。靶场pcap里还原出了a2b3e4.bin大小大约200KB。但file查看后发现它显示为data不是任何已知文件格式——载荷被处理过了。5.3 从SMB2会话里还原被传输的文件对于SMB传输的文件可以用同样的方式导出mkdir -p /tmp/exp_smb tshark -r evidence.pcap --export-objects smb,/tmp/exp_smb导出结果里包含svcmonitor.ps1。查看内容后可以看到一段使用Base64编码和简单异或操作的脚本它把一段数据解码后写入了一个.bin文件。这个脚本就是理解载荷构造方式的关键后面修复载荷时我反复参考了它的处理逻辑。5.4 strings与foremost兜底搜索有些小型载荷不通过HTTP或SMB传输而是直接嵌入在协议字段里比如DNS TXT记录、ICMP数据段。这时候导出对象帮不上忙需要换思路strings -n 8 evidence.pcap | grep -iE http|user-agent|\.exe|\.dll|\.ps1|cmd|powershell或者直接用foremost对整个pcap做文件雕刻foremost evidence.pcap -o /tmp/foremost_outforemost会按文件签名识别并切分嵌入的图片、压缩包、可执行文件等。虽然它有一定误报率但作为兜底搜索很实用。我在这次分析里没用上foremost但在之前的靶场里它帮我从混杂流量里挖出过一个压缩包里面正好是攻击者收集的内网信息这种“意外收获”在取证中很常见。6. 载荷修复流量里抠出来的文件为什么是坏的6.1 三种最常见的“损坏”成因从流量中提取的文件无法直接使用原因通常有三类成因表现典型场景TCP分段后只导出了部分字节文件大小明显偏小直接“右键导出字节流”协议编码未反转file识别为data或乱码HTTP chunked、Base64、XOR编码文件头被刻意抹除file识别为data攻击者为避免静态检测手动删头分析时必须先判断属于哪一类再决定用哪套修复方案。拿到靶场里的a2b3e4.bin我第一反应是看它完整不完整然后看内容特征。6.2 场景一chunked传输导致的不完整如果HTTP响应使用了Transfer-Encoding: chunked服务端会把响应体切成多个chunk每个chunk前面带一个十六进制的长度行。直接保存TCP流文件里会混入\r\n和长度数字导致无法解析。修复方法分两步先用tshark提取完整的TCP流tshark -r evidence.pcap -Y tcp.stream eq 15 -T fields -e data.data stream_hex.txt xxd -r -p stream_hex.txt stream_raw.bin再用Python或者010 Editor手动删除每行开头的chunk长度标记把chunk边界重新拼接起来。更偷懒的做法是直接用tshark的导出对象功能因为Wireshark在处理HTTP对象时会自动解chunked导出的就是解码后的完整数据。我在靶场这次遇到的不是chunked但之前在分析真实恶意流量时被坑过一次后来就养成了“先尝试导出对象”的习惯。6.3 场景二自定义编码需要反转svcmonitor.ps1揭示了编码方式载荷先做Base64解码再对每个字节异或0x5A。照着写一个Python脚本还原import base64 with open(a2b3e4.encoded, rb) as f: b64_data f.read().strip() raw base64.b64decode(b64_data) decoded bytes([b ^ 0x5A for b in raw]) with open(a2b3e4_recovered, wb) as f: f.write(decoded)执行后file a2b3e4_recovered立刻显示为PE32 executable (GUI) Intel 80386。这一步说明攻击者做了编码混淆但编码逻辑本身没有加密只要顺着脚本逻辑反转就能还原。6.4 场景三文件头被刻意抹掉还有一种常见情况还原出来发现开头十几字节是乱的但后面的结构能看出是PE文件——这种情况通常是攻击者或抓包工具截掉了文件头部分字节。用010 Editor之类的十六进制工具打开文件人工补上缺失的头部。以PE文件为例如果文件头缺失但Dos头还在补齐时需要在最前面恢复MZ标记以及DOS头中的关键字段如果整个文件头都丢了则需要根据代码段的起始位置推算入口点这属于更复杂的逆向工作了。靶场里a2b3e4_recovered的头部完整不需要这一步但如果真的遇到记住不要随便补值先参考同类型文件的头部结构再结合文件内偏移做推算。6.5 修复之后的验证方法文件恢复后必须做验证。最简单的验证file a2b3e4_recovered sha256sum a2b3e4_recovered strings a2b3e4_recovered | head -50file能确认载荷的真实格式sha256sum算出的哈希既用于IoC查杀也可以直接同步给威胁情报平台做哈希匹配strings则能快速给出文件内的可读字符串线索。更进一步的静态分析可以在隔离的虚拟机里用pefile、capa或DIE检查编译时间、导入表、C2配置等。注意所有恶意样本的分析必须在隔离环境中完成之后不要再在原机上双击运行。验证通过后我会把样本连同它的SHA256、解码脚本、关联的pcap包号一起存档。这就是最终交付的“修复后载荷”比一个单纯提取出的乱码文件有价值得多。7. 这套流程能复用到哪些真实场景7.1 整个分析最关键的三个习惯第一证据先保全再分析。下载文件后立刻做哈希校验确保你手里的pcap和你分析的对象一致这是所有后续结论的根基。第二先全局统计再局部过滤。Protocol Hierarchy、Endpoints、Conversations三个面板只用一分钟却能省下半小时盲目翻包的时间。第三把手工操作沉淀成命令。能用tshark导出的对象不用鼠标右键能用Python脚本解码的不在十六进制编辑器里手工改这套“命令化”的分析路径可以反复用在下一个样本上。7.2 检测侧可以落地的三个改进这次靶场分析其实也暴露了防守侧的一些优化点。文件服务器上应该开启SMB对象访问审计记录谁在什么时间读取或写入了共享里的文件出口HTTP流量需要对未知外部域的下载请求做告警445端口的入站扫描行为在边界防火墙上应该单独统计频率。很多攻击链在事后看非常清晰但如果连“谁连过我、传过什么文件”这样的基础日志都没有再好的流量分析工具也无从下手。7.3 最后再分享一个小经验我刚开始做流量分析时总想着把所有数据包都看完才敢下结论。后来发现做不到也不需要。真正有效的方式是让统计面板帮你圈定目标让过滤表达式帮你缩小范围让导出工具帮你提取对象让脚本帮你做还原。分析人员要做的是在关键节点做出判断这段流量值不值得跟这个文件是不是真正的恶意载荷这组行为能不能串成一条完整的攻击链。把问题变成可复用的流程流量分析就不再是“碰运气找包”的手艺活而是一套稳定输出的取证能力。
