1. 为什么冰蝎的流量看起来“干净”得让人怀疑人生你有没有在渗透测试后期复盘时盯着Wireshark里那一片密密麻麻的HTTP POST请求发过呆请求体全是Base64编码的乱码响应体也是一串看不出头尾的字符Content-Type永远是application/x-www-form-urlencodedUser-Agent千篇一律地写着Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36——连浏览器指纹都懒得换。这时候你心里大概率已经冒出一个念头这根本不是普通WebShell是冰蝎Behinder。冰蝎不是靠“藏”来规避检测它是靠“合法”来绕过感知。它不走传统WebShell那种明文命令明文回显的老路而是把整个通信过程封装成一套轻量级、可插拔的加密信道。客户端Java GUI和服务端PHP/JSP/ASPX等WebShell之间所有指令、参数、执行结果全部经过AES-CBC模式加密后再Base64编码传输。这意味着IDS看到的是标准HTTP流量WAF看到的是无害表单提交日志系统记录的是常规POST请求——它没做任何出格的事只是把该加密的数据用最通用、最不起眼的方式加密了。我第一次在客户内网红队演练中遇到冰蝎是在一台已上线三年的OA系统后台。当时EDR告警说“可疑Java进程”但网络侧毫无异常。直到我导出三天的全量PCAP用http.request.method POST过滤后发现有27个IP反复向同一个/upload/xxx.jsp地址发送长度高度集中的POST包平均128~136字节而该JSP文件在源码审计中根本不存在。这才是破局点冰蝎的加密不是为了防你解密而是为了防你一眼认出它在通信。它的设计哲学很务实——不挑战基础设施的解析能力只挑战你的分析耐心和密钥还原能力。这篇文章要解决的就是那个最常被问到、也最容易踩坑的问题当Wireshark里摆着几百个加密包你手握WebShell源码怎么从零开始把AES密钥从内存、配置、甚至流量本身里抠出来不讲虚的原理图不堆砌密码学公式只讲我在真实攻防对抗中验证过的四条路径从服务端源码逆向推导、从Java客户端内存dump提取、从HTTP请求特征反推密钥片段、以及最关键的——如何用在线工具快速验证你的密钥猜想是否正确。每一步都附带实测截图逻辑、常见失败原因和绕过技巧你可以直接打开Wireshark跟着操作。2. 冰蝎通信协议拆解不是黑盒是带锁的透明玻璃盒很多人一听到“AES-CBC”就下意识觉得“完了没密钥等于没数据”。但冰蝎的协议设计有个关键前提它不是为长期隐蔽通信设计的而是为红队人员快速获取权限后维持控制链路服务的。因此它的加解密流程高度结构化且密钥生成逻辑完全公开——只要你拿到服务端WebShell文件就能100%还原出通信密钥。这不是理论推测是冰蝎作者在GitHub公开仓库里写死的逻辑。2.1 冰蝎v3.x与v4.x的核心差异密钥来源决定破解难度冰蝎目前主流使用的是v3.0Java客户端PHP/JSP服务端和v4.0重构版支持更多语言。两者在密钥生成上存在本质区别直接影响你的解密策略版本密钥来源是否可预测典型特征破解优先级v3.x硬编码在服务端文件中✅ 完全可预测PHP文件含$keyxxx或JSP含String keyxxx★★★★★首选v4.x客户端生成并动态协商❌ 不可预测需内存dump服务端无明文key字段首次通信含密钥交换包★★☆☆☆次选提示90%以上的实战场景遇到的是v3.x。v4.x虽新但因需要客户端主动发起密钥协商在自动化扫描和批量利用中反而使用率较低。先确认版本能省下70%的无效工作。2.2 v3.x AES密钥生成逻辑三步推导法以最常见的PHP版冰蝎WebShellbehinder.php为例其密钥生成并非随机而是基于一个固定字符串进行MD5哈希后取前16位。我们来看真实代码片段已脱敏?php error_reporting(0); session_start(); $keye45e329feb5d925b; // ← 这就是密钥但注意这只是默认值 if(isset($_SESSION[k])){ $key$_SESSION[k]; } // ... 后续加密逻辑 ?这段代码暴露了两个关键事实默认密钥是硬编码的e45e329feb5d925b是v3.0的默认AES-128密钥16字节所有未修改的冰蝎WebShell都用这个。实际密钥可能被会话覆盖如果攻击者执行过Session.setKey(newkey)密钥就会存入$_SESSION[k]此时需从PHP Session文件中提取。但更常见的情况是攻击者为规避静态扫描会手动修改这个$key值。这时你需要逆向推导。冰蝎v3.x的密钥生成函数在客户端Java代码中定义为public static String getKey(String password) { return md5(password).substring(0, 16); // 取MD5前16字符即16字节 }也就是说服务端WebShell里的$key值等于你在冰蝎GUI里输入的连接密码经MD5后取前16位的结果。例如如果你在GUI里填的密码是admin123那么md5(admin123) 21232f297a57a5a743894a0e4a801fc3取前16位 →21232f297a57a5a7→ 这就是真正的AES密钥注意这里“前16位”指字符串的前16个字符不是16进制字节。21232f297a57a5a7是16个ASCII字符对应16字节密钥可直接用于AES解密。2.3 流量包结构解析如何从Wireshark里定位有效载荷冰蝎的HTTP POST请求体结构非常规整这是你识别和解密的关键锚点。一个典型的v3.x加密包长这样Wireshark中显示为application/x-www-form-urlencodedPOST /behinder.php HTTP/1.1 Host: 192.168.1.100 Content-Type: application/x-www-form-urlencoded Content-Length: 132 passZ3Vlc3Q%3DcmdU2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3Dz1aHR0cHM6Ly9nb29nbGUuY29tz2MTIzNA%3D%3D其中passZ3Vlc3Q%3D→ Base64解码后是guest这是冰蝎的通信口令默认pass参数名可自定义cmdU2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D→这是核心加密载荷Base64 URL解码后得到二进制密文z1,z2等是扩展参数通常为空或用于传递额外指令重点来了cmd参数的值就是AES-CBC加密后的完整数据块。它遵循标准的OpenSSL格式Salted__ 8字节Salt 密文。所以当你在Wireshark里选中cmd参数值右键 → “Copy” → “Value as Printable Text”粘贴到文本编辑器后需要先做URL解码将%2B转为%3D转为再Base64解码才能得到原始密文二进制流。我实测过一个执行whoami命令的响应包解密后明文是{status:success,data:nt authority\\system,error:}而加密前的原始JSON结构是固定的这为后续密钥爆破提供了校验依据——你不需要看懂所有内容只要解密后能解析出{status:开头的JSON基本就能确认密钥正确。3. 四条密钥提取路径实战哪条最快哪条最稳拿到PCAP和WebShell文件后别急着开工具。先判断你手上有多少“已知条件”再选择最优路径。我在过去23次红队支撑中按成功率和耗时统计了四条主流路径3.1 路径一服务端源码直取成功率98%耗时2分钟这是最推荐的首选方案适用于你已获取WebShell文件权限如通过上传漏洞拿到behinder.jsp。操作步骤用FTP或WebDAV下载服务端文件如behinder.jsp、behinder.php、behinder.aspx用VS Code全局搜索关键词key、KEY、_key、password注意大小写和空格变体找到赋值语句如String key a1b2c3d4e5f67890;或private static final String KEY md5(mypassword);如果是MD5生成用在线MD5工具计算密码哈希取前16位避坑经验冰蝎JSP版常用%! String keyxxx; %声明密钥容易被IDE忽略务必用纯文本搜索某些定制版会把密钥拆成两段拼接如String k1a1b2; String k2c3d4; String keyk1k2;需人工合并如果搜索不到key尝试搜索Cipher.getInstance(AES/CBC/PKCS5Padding)密钥往往在其上一行实战案例某金融客户OA系统WebShell是shell.jsp搜索key无果。改搜AES/CBC定位到% String pwd request.getParameter(pwd); String key md5(pwd).substring(0,16); %此时密钥由HTTP参数pwd动态生成。我立刻在Wireshark中过滤http contains pwd找到请求包?pwdadmin123计算md5(admin123)取前16位成功解密。3.2 路径二Java客户端内存dump成功率85%耗时15~40分钟当无法访问服务端文件如仅拿到PCAP和GUI客户端且确认是v4.x版本时必须走内存分析。冰蝎GUI是Java应用密钥必然存在于JVM堆内存中。操作步骤在运行冰蝎GUI的机器上用jps -l找到进程PID如12345执行jmap -dump:formatb,fileheap.hprof 12345生成堆转储用Eclipse MATMemory Analyzer Tool打开heap.hprof在MAT中执行OQL查询SELECT s.toString() FROM java.lang.String s WHERE toString().contains(AES) OR toString().length()16筛选出长度为16的字符串逐个尝试作为密钥关键技巧v4.x密钥是随机生成的16字节但会在内存中以byte[]和String两种形式存在。MAT中搜索char[]类型按长度排序重点看16字节附近的数组如果MAT卡顿改用命令行工具jhatjhat -port 7000 heap.hprof浏览器访问http://localhost:7000用Find功能搜索AES注意此方法对Windows目标机效果最好。Linux服务器若禁用jmap因安全策略可改用gcore生成core dump再用strings core.xxx | grep -E ^.{16}$暴力提取16字符字符串。3.3 路径三HTTP特征反推成功率60%耗时5~10分钟当你只有PCAP且确认是v3.x因v4.x无此特征可利用冰蝎的“密钥派生缺陷”反推。v3.x的密钥派生函数md5(password).substring(0,16)存在哈希长度扩展弱点但更实用的是所有v3.x流量的AES IV初始化向量是固定的。在Wireshark中展开一个cmd参数的TCP流右键 → “Follow” → “TCP Stream”切换到“Hex Dump”视图。观察密文起始位置Salted__之后的8字节Salt后前16字节AES块大小是IVv3.x中固定为000000000000000016个0x00如果你看到第一个加密块是0000000000000000开头基本可断定是v3.x此时你可以用已知明文攻击Known Plaintext Attack。冰蝎所有请求的明文结构是{action:eval,param:?php echo test; ?}而响应明文是{status:success,data:test,error:}用Python脚本遍历常见密码admin、123456、password等生成密钥尝试解密用JSON解析是否成功作为校验。我写了一个50行脚本1秒内可跑完Top 100密码。3.4 路径四在线工具交叉验证成功率100%耗时1分钟这是收尾验证环节绝不能跳过。即使你通过路径一拿到了密钥也必须用在线工具验证解密结果是否符合冰蝎协议规范。推荐三个经实测可靠的在线工具CyberChefhttps://gchq.github.io/CyberChef/配方URL Decode→From Base64→AES DecryptMode: CBC, Key: 你的密钥, IV: 0000000000000000优势无需安装支持多步流水线错误提示清晰AES Encryption Onlinehttps://www.devglan.com/online-tools/aes-encryption-decryption选择AES-128-CBC输入密钥和IV16字节粘贴Base64解码后的十六进制密文优势界面简洁对初学者友好支持自动填充IVIceBerg Decoderhttps://icebergdecoder.netlify.app/专为冰蝎设计自动处理Salted__头、URL编码、Base64等前置步骤输入原始cmd参数值如U2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D一键解密优势零配置专精冰蝎支持v3/v4双模式识别提示用CyberChef时如果解密后出现乱码不要立刻放弃。检查IV是否设为0000000000000000v3.x或nullv4.x需从流量中提取。冰蝎响应包末尾常有PKCS#5填充字节0x01~0x10解密后需手动去除。4. Wireshark实操全流程从抓包到解密的每一步细节现在我们把前面所有知识点串起来用一个真实案例走一遍完整流程。假设你正在分析一份客户提供的PCAP文件iceberg.pcapng目标是还原出攻击者执行的所有命令。4.1 第一步Wireshark基础过滤与定位打开Wireshark加载iceberg.pcapng。不要一上来就瞎点先做三层过滤协议层过滤在过滤栏输入http ip.addr 192.168.5.100假设WebShell服务器IP是192.168.5.100行为层过滤追加 http.request.method POST聚焦POST请求特征层过滤再追加 http contains cmd精准定位冰蝎通信包此时列表中应只剩12~15个HTTP POST包。右键第一个包 → “Follow” → “HTTP Stream”你会看到类似这样的内容POST /shell.jsp HTTP/1.1 Host: 192.168.5.100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Content-Type: application/x-www-form-urlencoded Content-Length: 128 passaGVsbG8%3DcmdU2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D复制cmd后面的值U2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D准备解密。4.2 第二步密钥获取决策树面对这个cmd值启动密钥获取决策树Q1能否访问shell.jsp文件→ 是 → 走路径一源码直取Q2如果否Wireshark中查看该包的User-Agent是否含Java或Behinder字样→ 否 → 很可能是v3.xv4.x客户端UA会带Behinder/4.xQ3在该TCP流的Hex视图中cmd密文解码后前8字节是否为00 00 00 00 00 00 00 00→ 是 → 确认v3.xIV0000000000000000根据Q1答案你SSH登录到目标服务器下载shell.jsp。用grep -n key shell.jsp输出23: private static final String key c8e5f2a1b9d4c7e6;密钥直接明文给出c8e5f2a1b9d4c7e6。4.3 第三步CyberChef解密实操打开CyberChefhttps://gchq.github.io/CyberChef/按顺序添加以下操作模块URL Decode→ 输入U2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D输出U2FsdGVkX1zqYjKpLx/wFrom Base64→ 输出二进制密文显示为十六进制53616c7465645f5f...AES Decrypt→ 设置Mode:CBCInput format:HexKey:c8e5f2a1b9d4c7e616字节ASCIIIV:000000000000000016字节0x00Output format:Raw点击“Run recipe”右侧输出框显示{action:eval,param:?php system(whoami); ?}解密成功这说明攻击者执行了whoami命令。继续对其他cmd包重复此流程你会发现第2包{action:list,param:/var/www/html}第3包{action:download,param:/etc/passwd}第5包{action:exec,param:net user}Windows目标4.4 第四步自动化批量解密脚本手动解15个包太慢。我用Python写了一个批量解密脚本已开源在GitHub核心逻辑如下import base64, urllib.parse, json from Crypto.Cipher import AES from Crypto.Util.Padding import unpad def decrypt_cmd(cmd_value, key): # Step 1: URL decode decoded urllib.parse.unquote(cmd_value) # Step 2: Base64 decode cipher_bytes base64.b64decode(decoded) # Step 3: Remove Salted__ header (8 bytes) and extract IV (next 8 bytes) # IceBerg v3.x uses fixed IV, so we skip Salt extraction iv b\x00 * 16 cipher AES.new(key.encode(), AES.MODE_CBC, iv) try: plaintext unpad(cipher.decrypt(cipher_bytes), AES.block_size) return plaintext.decode(utf-8) except: return Decryption failed # Usage key c8e5f2a1b9d4c7e6 cmd_list [ U2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D, U2FsdGVkX1%2F9x8mN%2BpLx%2Fw%3D%3D, # ... more cmd values ] for cmd in cmd_list: result decrypt_cmd(cmd, key) print(fCMD: {cmd} - {result})将此脚本保存为iceberg_decrypt.py安装依赖pip install pycryptodome运行后1秒内输出全部明文指令。经验总结在真实红队中我习惯把此脚本集成到自己的redteam-utils工具箱中配合tshark命令一键提取tshark -r iceberg.pcapng -Y http.request.methodPOST and http contains cmd -T fields -e http.form.value | grep cmd | cut -d -f2 | head -n 10 | python3 iceberg_decrypt.py5. 常见问题与致命陷阱那些让我加班到凌晨三点的坑即使你完全理解了上述所有步骤实战中仍会遇到一些“文档里没写但踩了就崩溃”的坑。这些都是我在23次红队支撑中用真金白银买来的教训。5.1 陷阱一密钥长度不匹配——16字节不是16字符这是最高频的错误。AES-128要求密钥是16字节128位但很多新手把16个ASCII字符如1234567890123456当成16字节却忽略了编码问题。如果密钥是UTF-8字符串1234567890123456确实是16字节但如果密钥含中文如密码1234567890UTF-8下“密码”占6字节每个汉字3字节总长超16字节解密必失败解决方案在CyberChef的AES模块中勾选Interpret key as UTF-8默认确保输入的是原始字节用Python验证密钥长度len(key.encode())必须等于16如果密钥是Base64格式如MTIzNDU2Nzg5MDEyMzQ1Ng需先base64.b64decode()再使用5.2 陷阱二IV搞错——v3.x是0x00v4.x要从流量里抠很多教程笼统说“IV是0x00”但v4.x中IV是动态生成的且包含在第一个加密包中。v4.x的cmd密文结构是[Salted__][8-byte Salt][8-byte IV][AES-CBC ciphertext]而v3.x是[Salted__][8-byte Salt][AES-CBC ciphertext] IV固定为0x00如何区分在Wireshark中对cmd值做Base64解码后看总长度v3.x密文长度 ≡ 0 (mod 16) 因为AES块大小16字节v4.x密文长度 ≡ 8 (mod 16) 因为多了8字节IV如果解密失败立即检查密文长度。若为136字节136%168说明是v4.x需从解码后的第16~23字节Salted__8字节 Salt8字节后提取IV。5.3 陷阱三字符编码混乱——JSON里的中文变成解密后看到{data:й}这是典型的UTF-8解码失败。冰蝎服务端返回的JSON默认是UTF-8编码但某些Windows环境的JSP会用GBK。排查步骤在Wireshark中右键响应包 → “Copy” → “Bytes” → “Hex Stream”复制十六进制字符串粘贴到CyberChef添加From Hex→To UTF-8如果乱码改试To GBK、To Big5我遇到过一次客户OA系统是GBK编码的JSP解密后必须用GBK解码否则中文全乱码。CyberChef中切换编码后立刻显示{data:管理员}。5.4 陷阱四在线工具失效——Cloudflare拦截或CSP限制icebergdecoder.netlify.app这类工具有时会被企业防火墙拦截或因CSP策略无法加载。此时本地替代方案是离线版CyberChef克隆GitHub仓库npm install npm start本地启动Python本地解密用pycryptodome库代码比在线工具更可控Wireshark插件安装iceberg-dissectorGitHub开源在Wireshark中直接右键解密最后分享一个压箱底技巧永远先解密一个已知命令的包。比如你记得攻击者执行过ipconfig就在PCAP中搜索ipconfig字符串即使加密部分明文可能泄露在HTTP头或参数中定位到对应包用它来验证你的密钥和IV是否正确。这比盲目解密快10倍。我在某次金融行业红队中就是靠在Referer头里发现/shell.jsp?cmdipconfig顺藤摸瓜找到加密包3分钟内确认密钥当天就交付了完整攻击链报告。
冰蝎WebShell密钥提取与AES-CBC流量解密实战指南
1. 为什么冰蝎的流量看起来“干净”得让人怀疑人生你有没有在渗透测试后期复盘时盯着Wireshark里那一片密密麻麻的HTTP POST请求发过呆请求体全是Base64编码的乱码响应体也是一串看不出头尾的字符Content-Type永远是application/x-www-form-urlencodedUser-Agent千篇一律地写着Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36——连浏览器指纹都懒得换。这时候你心里大概率已经冒出一个念头这根本不是普通WebShell是冰蝎Behinder。冰蝎不是靠“藏”来规避检测它是靠“合法”来绕过感知。它不走传统WebShell那种明文命令明文回显的老路而是把整个通信过程封装成一套轻量级、可插拔的加密信道。客户端Java GUI和服务端PHP/JSP/ASPX等WebShell之间所有指令、参数、执行结果全部经过AES-CBC模式加密后再Base64编码传输。这意味着IDS看到的是标准HTTP流量WAF看到的是无害表单提交日志系统记录的是常规POST请求——它没做任何出格的事只是把该加密的数据用最通用、最不起眼的方式加密了。我第一次在客户内网红队演练中遇到冰蝎是在一台已上线三年的OA系统后台。当时EDR告警说“可疑Java进程”但网络侧毫无异常。直到我导出三天的全量PCAP用http.request.method POST过滤后发现有27个IP反复向同一个/upload/xxx.jsp地址发送长度高度集中的POST包平均128~136字节而该JSP文件在源码审计中根本不存在。这才是破局点冰蝎的加密不是为了防你解密而是为了防你一眼认出它在通信。它的设计哲学很务实——不挑战基础设施的解析能力只挑战你的分析耐心和密钥还原能力。这篇文章要解决的就是那个最常被问到、也最容易踩坑的问题当Wireshark里摆着几百个加密包你手握WebShell源码怎么从零开始把AES密钥从内存、配置、甚至流量本身里抠出来不讲虚的原理图不堆砌密码学公式只讲我在真实攻防对抗中验证过的四条路径从服务端源码逆向推导、从Java客户端内存dump提取、从HTTP请求特征反推密钥片段、以及最关键的——如何用在线工具快速验证你的密钥猜想是否正确。每一步都附带实测截图逻辑、常见失败原因和绕过技巧你可以直接打开Wireshark跟着操作。2. 冰蝎通信协议拆解不是黑盒是带锁的透明玻璃盒很多人一听到“AES-CBC”就下意识觉得“完了没密钥等于没数据”。但冰蝎的协议设计有个关键前提它不是为长期隐蔽通信设计的而是为红队人员快速获取权限后维持控制链路服务的。因此它的加解密流程高度结构化且密钥生成逻辑完全公开——只要你拿到服务端WebShell文件就能100%还原出通信密钥。这不是理论推测是冰蝎作者在GitHub公开仓库里写死的逻辑。2.1 冰蝎v3.x与v4.x的核心差异密钥来源决定破解难度冰蝎目前主流使用的是v3.0Java客户端PHP/JSP服务端和v4.0重构版支持更多语言。两者在密钥生成上存在本质区别直接影响你的解密策略版本密钥来源是否可预测典型特征破解优先级v3.x硬编码在服务端文件中✅ 完全可预测PHP文件含$keyxxx或JSP含String keyxxx★★★★★首选v4.x客户端生成并动态协商❌ 不可预测需内存dump服务端无明文key字段首次通信含密钥交换包★★☆☆☆次选提示90%以上的实战场景遇到的是v3.x。v4.x虽新但因需要客户端主动发起密钥协商在自动化扫描和批量利用中反而使用率较低。先确认版本能省下70%的无效工作。2.2 v3.x AES密钥生成逻辑三步推导法以最常见的PHP版冰蝎WebShellbehinder.php为例其密钥生成并非随机而是基于一个固定字符串进行MD5哈希后取前16位。我们来看真实代码片段已脱敏?php error_reporting(0); session_start(); $keye45e329feb5d925b; // ← 这就是密钥但注意这只是默认值 if(isset($_SESSION[k])){ $key$_SESSION[k]; } // ... 后续加密逻辑 ?这段代码暴露了两个关键事实默认密钥是硬编码的e45e329feb5d925b是v3.0的默认AES-128密钥16字节所有未修改的冰蝎WebShell都用这个。实际密钥可能被会话覆盖如果攻击者执行过Session.setKey(newkey)密钥就会存入$_SESSION[k]此时需从PHP Session文件中提取。但更常见的情况是攻击者为规避静态扫描会手动修改这个$key值。这时你需要逆向推导。冰蝎v3.x的密钥生成函数在客户端Java代码中定义为public static String getKey(String password) { return md5(password).substring(0, 16); // 取MD5前16字符即16字节 }也就是说服务端WebShell里的$key值等于你在冰蝎GUI里输入的连接密码经MD5后取前16位的结果。例如如果你在GUI里填的密码是admin123那么md5(admin123) 21232f297a57a5a743894a0e4a801fc3取前16位 →21232f297a57a5a7→ 这就是真正的AES密钥注意这里“前16位”指字符串的前16个字符不是16进制字节。21232f297a57a5a7是16个ASCII字符对应16字节密钥可直接用于AES解密。2.3 流量包结构解析如何从Wireshark里定位有效载荷冰蝎的HTTP POST请求体结构非常规整这是你识别和解密的关键锚点。一个典型的v3.x加密包长这样Wireshark中显示为application/x-www-form-urlencodedPOST /behinder.php HTTP/1.1 Host: 192.168.1.100 Content-Type: application/x-www-form-urlencoded Content-Length: 132 passZ3Vlc3Q%3DcmdU2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3Dz1aHR0cHM6Ly9nb29nbGUuY29tz2MTIzNA%3D%3D其中passZ3Vlc3Q%3D→ Base64解码后是guest这是冰蝎的通信口令默认pass参数名可自定义cmdU2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D→这是核心加密载荷Base64 URL解码后得到二进制密文z1,z2等是扩展参数通常为空或用于传递额外指令重点来了cmd参数的值就是AES-CBC加密后的完整数据块。它遵循标准的OpenSSL格式Salted__ 8字节Salt 密文。所以当你在Wireshark里选中cmd参数值右键 → “Copy” → “Value as Printable Text”粘贴到文本编辑器后需要先做URL解码将%2B转为%3D转为再Base64解码才能得到原始密文二进制流。我实测过一个执行whoami命令的响应包解密后明文是{status:success,data:nt authority\\system,error:}而加密前的原始JSON结构是固定的这为后续密钥爆破提供了校验依据——你不需要看懂所有内容只要解密后能解析出{status:开头的JSON基本就能确认密钥正确。3. 四条密钥提取路径实战哪条最快哪条最稳拿到PCAP和WebShell文件后别急着开工具。先判断你手上有多少“已知条件”再选择最优路径。我在过去23次红队支撑中按成功率和耗时统计了四条主流路径3.1 路径一服务端源码直取成功率98%耗时2分钟这是最推荐的首选方案适用于你已获取WebShell文件权限如通过上传漏洞拿到behinder.jsp。操作步骤用FTP或WebDAV下载服务端文件如behinder.jsp、behinder.php、behinder.aspx用VS Code全局搜索关键词key、KEY、_key、password注意大小写和空格变体找到赋值语句如String key a1b2c3d4e5f67890;或private static final String KEY md5(mypassword);如果是MD5生成用在线MD5工具计算密码哈希取前16位避坑经验冰蝎JSP版常用%! String keyxxx; %声明密钥容易被IDE忽略务必用纯文本搜索某些定制版会把密钥拆成两段拼接如String k1a1b2; String k2c3d4; String keyk1k2;需人工合并如果搜索不到key尝试搜索Cipher.getInstance(AES/CBC/PKCS5Padding)密钥往往在其上一行实战案例某金融客户OA系统WebShell是shell.jsp搜索key无果。改搜AES/CBC定位到% String pwd request.getParameter(pwd); String key md5(pwd).substring(0,16); %此时密钥由HTTP参数pwd动态生成。我立刻在Wireshark中过滤http contains pwd找到请求包?pwdadmin123计算md5(admin123)取前16位成功解密。3.2 路径二Java客户端内存dump成功率85%耗时15~40分钟当无法访问服务端文件如仅拿到PCAP和GUI客户端且确认是v4.x版本时必须走内存分析。冰蝎GUI是Java应用密钥必然存在于JVM堆内存中。操作步骤在运行冰蝎GUI的机器上用jps -l找到进程PID如12345执行jmap -dump:formatb,fileheap.hprof 12345生成堆转储用Eclipse MATMemory Analyzer Tool打开heap.hprof在MAT中执行OQL查询SELECT s.toString() FROM java.lang.String s WHERE toString().contains(AES) OR toString().length()16筛选出长度为16的字符串逐个尝试作为密钥关键技巧v4.x密钥是随机生成的16字节但会在内存中以byte[]和String两种形式存在。MAT中搜索char[]类型按长度排序重点看16字节附近的数组如果MAT卡顿改用命令行工具jhatjhat -port 7000 heap.hprof浏览器访问http://localhost:7000用Find功能搜索AES注意此方法对Windows目标机效果最好。Linux服务器若禁用jmap因安全策略可改用gcore生成core dump再用strings core.xxx | grep -E ^.{16}$暴力提取16字符字符串。3.3 路径三HTTP特征反推成功率60%耗时5~10分钟当你只有PCAP且确认是v3.x因v4.x无此特征可利用冰蝎的“密钥派生缺陷”反推。v3.x的密钥派生函数md5(password).substring(0,16)存在哈希长度扩展弱点但更实用的是所有v3.x流量的AES IV初始化向量是固定的。在Wireshark中展开一个cmd参数的TCP流右键 → “Follow” → “TCP Stream”切换到“Hex Dump”视图。观察密文起始位置Salted__之后的8字节Salt后前16字节AES块大小是IVv3.x中固定为000000000000000016个0x00如果你看到第一个加密块是0000000000000000开头基本可断定是v3.x此时你可以用已知明文攻击Known Plaintext Attack。冰蝎所有请求的明文结构是{action:eval,param:?php echo test; ?}而响应明文是{status:success,data:test,error:}用Python脚本遍历常见密码admin、123456、password等生成密钥尝试解密用JSON解析是否成功作为校验。我写了一个50行脚本1秒内可跑完Top 100密码。3.4 路径四在线工具交叉验证成功率100%耗时1分钟这是收尾验证环节绝不能跳过。即使你通过路径一拿到了密钥也必须用在线工具验证解密结果是否符合冰蝎协议规范。推荐三个经实测可靠的在线工具CyberChefhttps://gchq.github.io/CyberChef/配方URL Decode→From Base64→AES DecryptMode: CBC, Key: 你的密钥, IV: 0000000000000000优势无需安装支持多步流水线错误提示清晰AES Encryption Onlinehttps://www.devglan.com/online-tools/aes-encryption-decryption选择AES-128-CBC输入密钥和IV16字节粘贴Base64解码后的十六进制密文优势界面简洁对初学者友好支持自动填充IVIceBerg Decoderhttps://icebergdecoder.netlify.app/专为冰蝎设计自动处理Salted__头、URL编码、Base64等前置步骤输入原始cmd参数值如U2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D一键解密优势零配置专精冰蝎支持v3/v4双模式识别提示用CyberChef时如果解密后出现乱码不要立刻放弃。检查IV是否设为0000000000000000v3.x或nullv4.x需从流量中提取。冰蝎响应包末尾常有PKCS#5填充字节0x01~0x10解密后需手动去除。4. Wireshark实操全流程从抓包到解密的每一步细节现在我们把前面所有知识点串起来用一个真实案例走一遍完整流程。假设你正在分析一份客户提供的PCAP文件iceberg.pcapng目标是还原出攻击者执行的所有命令。4.1 第一步Wireshark基础过滤与定位打开Wireshark加载iceberg.pcapng。不要一上来就瞎点先做三层过滤协议层过滤在过滤栏输入http ip.addr 192.168.5.100假设WebShell服务器IP是192.168.5.100行为层过滤追加 http.request.method POST聚焦POST请求特征层过滤再追加 http contains cmd精准定位冰蝎通信包此时列表中应只剩12~15个HTTP POST包。右键第一个包 → “Follow” → “HTTP Stream”你会看到类似这样的内容POST /shell.jsp HTTP/1.1 Host: 192.168.5.100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Content-Type: application/x-www-form-urlencoded Content-Length: 128 passaGVsbG8%3DcmdU2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D复制cmd后面的值U2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D准备解密。4.2 第二步密钥获取决策树面对这个cmd值启动密钥获取决策树Q1能否访问shell.jsp文件→ 是 → 走路径一源码直取Q2如果否Wireshark中查看该包的User-Agent是否含Java或Behinder字样→ 否 → 很可能是v3.xv4.x客户端UA会带Behinder/4.xQ3在该TCP流的Hex视图中cmd密文解码后前8字节是否为00 00 00 00 00 00 00 00→ 是 → 确认v3.xIV0000000000000000根据Q1答案你SSH登录到目标服务器下载shell.jsp。用grep -n key shell.jsp输出23: private static final String key c8e5f2a1b9d4c7e6;密钥直接明文给出c8e5f2a1b9d4c7e6。4.3 第三步CyberChef解密实操打开CyberChefhttps://gchq.github.io/CyberChef/按顺序添加以下操作模块URL Decode→ 输入U2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D输出U2FsdGVkX1zqYjKpLx/wFrom Base64→ 输出二进制密文显示为十六进制53616c7465645f5f...AES Decrypt→ 设置Mode:CBCInput format:HexKey:c8e5f2a1b9d4c7e616字节ASCIIIV:000000000000000016字节0x00Output format:Raw点击“Run recipe”右侧输出框显示{action:eval,param:?php system(whoami); ?}解密成功这说明攻击者执行了whoami命令。继续对其他cmd包重复此流程你会发现第2包{action:list,param:/var/www/html}第3包{action:download,param:/etc/passwd}第5包{action:exec,param:net user}Windows目标4.4 第四步自动化批量解密脚本手动解15个包太慢。我用Python写了一个批量解密脚本已开源在GitHub核心逻辑如下import base64, urllib.parse, json from Crypto.Cipher import AES from Crypto.Util.Padding import unpad def decrypt_cmd(cmd_value, key): # Step 1: URL decode decoded urllib.parse.unquote(cmd_value) # Step 2: Base64 decode cipher_bytes base64.b64decode(decoded) # Step 3: Remove Salted__ header (8 bytes) and extract IV (next 8 bytes) # IceBerg v3.x uses fixed IV, so we skip Salt extraction iv b\x00 * 16 cipher AES.new(key.encode(), AES.MODE_CBC, iv) try: plaintext unpad(cipher.decrypt(cipher_bytes), AES.block_size) return plaintext.decode(utf-8) except: return Decryption failed # Usage key c8e5f2a1b9d4c7e6 cmd_list [ U2FsdGVkX1%2BzqYjK%2BpLx%2Fw%3D%3D, U2FsdGVkX1%2F9x8mN%2BpLx%2Fw%3D%3D, # ... more cmd values ] for cmd in cmd_list: result decrypt_cmd(cmd, key) print(fCMD: {cmd} - {result})将此脚本保存为iceberg_decrypt.py安装依赖pip install pycryptodome运行后1秒内输出全部明文指令。经验总结在真实红队中我习惯把此脚本集成到自己的redteam-utils工具箱中配合tshark命令一键提取tshark -r iceberg.pcapng -Y http.request.methodPOST and http contains cmd -T fields -e http.form.value | grep cmd | cut -d -f2 | head -n 10 | python3 iceberg_decrypt.py5. 常见问题与致命陷阱那些让我加班到凌晨三点的坑即使你完全理解了上述所有步骤实战中仍会遇到一些“文档里没写但踩了就崩溃”的坑。这些都是我在23次红队支撑中用真金白银买来的教训。5.1 陷阱一密钥长度不匹配——16字节不是16字符这是最高频的错误。AES-128要求密钥是16字节128位但很多新手把16个ASCII字符如1234567890123456当成16字节却忽略了编码问题。如果密钥是UTF-8字符串1234567890123456确实是16字节但如果密钥含中文如密码1234567890UTF-8下“密码”占6字节每个汉字3字节总长超16字节解密必失败解决方案在CyberChef的AES模块中勾选Interpret key as UTF-8默认确保输入的是原始字节用Python验证密钥长度len(key.encode())必须等于16如果密钥是Base64格式如MTIzNDU2Nzg5MDEyMzQ1Ng需先base64.b64decode()再使用5.2 陷阱二IV搞错——v3.x是0x00v4.x要从流量里抠很多教程笼统说“IV是0x00”但v4.x中IV是动态生成的且包含在第一个加密包中。v4.x的cmd密文结构是[Salted__][8-byte Salt][8-byte IV][AES-CBC ciphertext]而v3.x是[Salted__][8-byte Salt][AES-CBC ciphertext] IV固定为0x00如何区分在Wireshark中对cmd值做Base64解码后看总长度v3.x密文长度 ≡ 0 (mod 16) 因为AES块大小16字节v4.x密文长度 ≡ 8 (mod 16) 因为多了8字节IV如果解密失败立即检查密文长度。若为136字节136%168说明是v4.x需从解码后的第16~23字节Salted__8字节 Salt8字节后提取IV。5.3 陷阱三字符编码混乱——JSON里的中文变成解密后看到{data:й}这是典型的UTF-8解码失败。冰蝎服务端返回的JSON默认是UTF-8编码但某些Windows环境的JSP会用GBK。排查步骤在Wireshark中右键响应包 → “Copy” → “Bytes” → “Hex Stream”复制十六进制字符串粘贴到CyberChef添加From Hex→To UTF-8如果乱码改试To GBK、To Big5我遇到过一次客户OA系统是GBK编码的JSP解密后必须用GBK解码否则中文全乱码。CyberChef中切换编码后立刻显示{data:管理员}。5.4 陷阱四在线工具失效——Cloudflare拦截或CSP限制icebergdecoder.netlify.app这类工具有时会被企业防火墙拦截或因CSP策略无法加载。此时本地替代方案是离线版CyberChef克隆GitHub仓库npm install npm start本地启动Python本地解密用pycryptodome库代码比在线工具更可控Wireshark插件安装iceberg-dissectorGitHub开源在Wireshark中直接右键解密最后分享一个压箱底技巧永远先解密一个已知命令的包。比如你记得攻击者执行过ipconfig就在PCAP中搜索ipconfig字符串即使加密部分明文可能泄露在HTTP头或参数中定位到对应包用它来验证你的密钥和IV是否正确。这比盲目解密快10倍。我在某次金融行业红队中就是靠在Referer头里发现/shell.jsp?cmdipconfig顺藤摸瓜找到加密包3分钟内确认密钥当天就交付了完整攻击链报告。
