文章总结： 本文详细讲解了SpringBootActuatorHeapdump漏洞的实战利用。内容涵盖密码驻留内存的原理剖析、利用路径解析差异绕过403拦截获取内存文件的方法、敏感信息提取工具的使用，以及最终通过泄露的云AK/SK成功接管40GB核心数据的完整攻击链，具有较高的实战参考价值。 综合评分： 88 文章分类： 渗透测试,WEB安全,SRC活动,云安全,实战经验

【SRC实战】/./绕过到 40GB云端接管？

原创

隐雾安全 隐雾安全

隐雾安全

2026年3月2日 09:01 四川

📝 编者语

在日常挖洞的时候，Spring Boot Actuator的未授权访问算是大家的“老熟人”了。很多人碰到/actuator/heapdump，习惯性地拿工具跑一下，找找数据库密码，交个洞就完事了。

但只会挖洞的白帽子不是好保安：为什么配置文件里的密码会明文躺在内存里？平时碰到加了防护、返回 403 的端点，该怎么绕？以及拿到云厂商的 AK/SK 后，怎么把一个普通的信息泄露搓成一个高危的云接管？

今天就拿最近打的一个真实众测项目来盘一盘，聊聊 HeapDump 泄露背后的原理，以及实战中我是怎么靠一个/./符号成功捡漏的。

1

为什么密码全在内存里躺着？

HeapDump其实就是Java服务端在某个特定时间的“内存快照”。

经常有开发老哥会纳闷：“密码明明在代码里加密了，或者只在启动的时候用了一下，怎么会被人全盘扒出来？”

其实这跟Java内存模型和Spring的加载机制有关。咱们直接看下面这张图：

其实就三步：

1. 配置被吃进内存：Spring启动时，会把 application.yml 里的密码读出来，放进 JVM的“字符串常量池”里。在Java里，字符串这东西是不可变的，一旦建好了就稳如泰山。
2. GC根本清不掉：这些密码被Spring的各种配置类死死引用着。而Spring默认的Bean都是单例模式，也就是说，只要这个Java进程不死，这些 Bean就一直活着。因为有“强引用”在，垃圾回收器路过的时候只能干瞪眼，根本不敢清掉这些密码。
3. 被咱们连锅端：当我们通过/heapdump端点触发堆转储时，其实就是把图里虚线框着的整个“JVM堆内存”原封不动地打包下载了。所以，那些明文密码和云服务AK/SK，自然就全落在咱们手里了。

所以，只要我们能把运行时的内存Dump下来，这台服务器对我们来说基本就没啥秘密可言了。

案例一

http://x.x.x.x/sys/rad/.;/actuator/

/sys/.;/actuator/ → /sys/actuator/

下载到heapdump文件，发现账号密码和shirokey

2

遇到 403 拦截怎么破？

案例二

对于无法直接访问的，我们就要考虑如何绕过。

在这个众测项目里，我先是锁定了目标的一个API 接口：

https://target.com/api/m/

直接去访问 /actuator/heapdump时，无一例外全弹了403 Forbidden。

目标显然加了防护或者网关拦截。 这时候爆破目录基本没戏了，得换个思路，找找解析差异。

前期搜集信息时，注意到目标开着Swagger的接口文档。于是我尝试了一个经典的Spring路径绕过姿势，顺手构造了这样一个 Payload：

https://target.com/api/m/swagger-ui.html/./heapdump

原本被死死拦截的请求，直接弹了下载框！17MB 的heapdump文件顺利到手。

👉 简单说下这个绕过的原理： 这招主打一个“信息差”。

1. 前置代理（比如Nginx/WAF）看这个请求：发现路径是以/swagger-ui.html开头的。它心想“哦，这是个正常的 API 文档静态页面”，直接放行。
2. 后端的Spring Boot看这个请求：Spring底层的路由解析器（像 AntPathMatcher）是个勤快人，它会对路径进行整理。它把/./当成当前目录给折叠掉了，最后实际去执行的路由，就变成了我们要找的/heapdump。

3

扒开内存看底裤

拿到了.hprof后缀的内存文件，用文本编辑器打开全是乱码。怎么在几百兆的垃圾数据里挑我们要的密码？这里推荐两个我平时爱用的轮子。

玩家选择一：纯命令行工具——heapdump_tool

如果是在跳板机上操作，或者没有图形界面，这个基 JDK 原生jhat魔改的开源工具极其好用。

不用瞎搜，它的命令很有针对性：

• 找密码：直接输入password。
• 找云凭证：正则匹配re=^[A-Z0-9]{10}$，或者直接搜AccessKey。
• 一把梭：输入shirokey 直接去扒Shiro的密钥；输入geturl提取内存里跑过的所有接口路径。

玩家选择二：点点点党的最爱——JDumpSpiderGUI

这次实战我图省事，直接用了这款带界面的自动化提取工具。把那 17MB 的文件往里一拖，喝口水的功夫，关键信息全列出来了：

1. 数据库密码直接爆出： 工具从Spring的环境变量池里，准确提取到了 spring.datasource.password 的明文密码。

2. 捞到大鱼（云服务 AK/SK）： 在翻看内存碎片时，一条眼熟的字符串引起了我的注意——LTAIxxxxxxxxxxx（标准的阿里云 AccessKey ID 开头），并且它的 SecretKey 就在旁边。

Aksk信息

xxxxxxxxxxxxxxxxxxxxrDxxxxx

LTAIxxxxxxxxxxxxxxxxxxxxxx

看到这个，我知道今天的赏金稳了。

4

从 Web 漏洞到云上接管

在云原生时代，打内网有时候已经不是唯一解了。拿到 AK/SK，往往意味着直接拿到了云端资产的钥匙。

为了验证这个凭证能干嘛，我掏出了常用的云环境利用工具（比如 CF 框架 cf.exe），把刚才拿到的 AccessKey 和 Secret 填进去跑了一下。

好家伙，权限不小！ 这不是一个只有只读权限的废钥，而是拥有全局读写权限的凭证。利用它，我直接接管了目标企业名下一个高达 42.16GB 的核心 OSS 存储桶！

里面存了啥？有用户的实名认证信息、企业合同扫描件、甚至还有部分业务的备份源码。

到这里，一个起初连访问都报403的小端点，被我们搓到了一个高危的云安全接管漏洞。

🎁 文末福利

联系客服获取获取工具包

!

微信号丨Hiddenfog001

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：隐雾安全 隐雾安全 隐雾安全《【SRC实战】/./绕过到 40GB云端接管？》