文章总结： 本文记录了一次完整的渗透测试过程，从发现SpringBootActuator未授权访问漏洞开始，通过分析JS文件获取API路径前缀，绕过Cookie校验下载HeapDump内存快照，解析出云服务AK/SK密钥，最终接管百余台云主机。关键发现包括：API路径前缀隐藏在JS文件中、HeapDump可绕过认证下载、内存快照包含未脱敏密钥。建议关闭Actuator端点、禁用heapdump、使用KMS管理密钥、遵循最小权限原则。 综合评分： 85 文章分类： 渗透测试,漏洞分析,WEB安全,红队,云安全
字典跑不出Actuator？从JS前缀到绕过Cookie下载HeapDump
进击的HACK
2026年5月12日 18:16 江苏
在小说阅读器读本章
去阅读
以下文章来源于临夏川 ，作者临夏川
临夏川 .
专注大模型应用、数据挖掘与网络安全。 记录学习过程，拆解技术原理，也尝试用技术视角解读科技世界。
〇、起因
前段时间对某目标进行测试，前期信息收集阶段没什么特别的发现，索性先把小程序端过了一遍。
小程序的逻辑比较简单，抓包分析了一圈，登录、鉴权、数据接口都看了看，没有找到可利用的点。常规的越权测试、参数篡改都试了一遍，收效甚微。
小程序端暂时没有突破，换个方向看看。
一、转向Web端
既然小程序背后肯定有服务端支撑，那直接从Web端入手或许效率更高。通过子域名收集和端口扫描，很快定位到了一个后台管理系统的登录页面。
看到登录框，老规矩，先走一遍常规流程：
弱口令爆破：Top密码跑了一轮，没有命中逻辑绕过：万能密码、验证码重置、短信轰炸接口，都没有明显缺陷接口测试：对登录相关的几个API做了参数注入和越权尝试
测试过程中，某个接口返回了经典的 Spring Boot 白页报错信息——Whitelabel Error Page。
看到这个页面心里就有底了：
Spring Boot 框架，大概率存在 Actuator 端点，值得深入。
二、从JS文件中找到突破口
确认是 Spring 之后，第一反应就是拿目录字典去 Fuzz Actuator 相关路径。/actuator、/env、/heapdump 这些常见端点都试了一遍，结果全部 404。
字典跑完了，什么都没找到。
这时候没有继续盲目扩大字典范围，而是冷静下来想了一下——很多系统的 API 路径并不是直接挂在根路径下的，可能会有一层前缀路由。于是回到浏览器，把前端加载的 JS 文件全都扒下来看了一遍。
果然，在其中一个打包后的 JS 文件里发现了关键线索：
/cloud/apis/rms/xxx/cloud/apis/rms/yyy
系统所有的 API 接口都统一挂载在 /cloud/apis/rms 这个路径前缀下面。
这个发现直接改变了后续的测试方向。
三、确认Spring Actuator未授权访问
拿到前缀之后，重新组织 Fuzz 策略，将路径拼接上前缀：
/cloud/apis/rms/actuator/env/cloud/apis/rms/actuator/heapdump/cloud/apis/rms/actuator/mappings...
这次终于有了收获——/cloud/apis/rms/actuator/env 接口直接返回了应用的配置信息，无需任何认证。
这意味着该系统的 Spring Actuator 端点存在未授权访问。
四、HeapDump下载遇阻与绕过
确认未授权之后，目标很明确——下载 HeapDump 文件。因为 /env 接口虽然能泄露部分配置，但密码等敏感字段通常会被 ****** 脱敏处理。而 HeapDump 是 JVM 内存快照，里面包含了运行时的所有对象数据，脱敏对它无效。
直接访问：
https://xxxx.com/cloud/apis/rms/actuator/heapdump
浏览器没有任何反应，页面一直在转圈。
抓包看一下请求和响应：
仔细分析后发现，服务端对请求做了 Cookie 校验，没有携带有效 Cookie 的请求会被直接丢弃，但也不会返回明确的错误提示——这就是为什么浏览器看起来”没反应”。
那问题就变成了：怎么获取一个合法的 Cookie？
答案其实很简单——小程序端是有注册和登录功能的。回到小程序，注册一个普通账号，抓取登录成功后返回的 Cookie，然后把它带到 HeapDump 的请求包里：
GET /cloud/apis/rms/actuator/heapdump HTTP/1.1Host: xxxx.comCookie: SESSION=xxxxxx
这一次，服务端开始返回数据——HeapDump 文件成功下载。
文件比较大，几百MB的内存快照，需要用专门的工具来解析。
五、从HeapDump中提取AK/SK
解析 HeapDump 文件用的是开源工具 heapdump_tool，项目地址：
https://github.com/wyzxxz/heapdump_tool
这个工具基于 jhat 解析内存快照，支持关键词搜索、正则匹配、按 class 模糊查询等多种方式，非常方便。使用过程大致如下：
#启动工具加载 heapdump 文件java -jar heapdump_tool.jar heapdump
成功从内存快照中提取出了云厂商的 AccessKey ID 和 AccessKey Secret。
到这里，信息泄露的链路已经完整了：
Spring Actuator 未授权 → HeapDump 下载 → 内存快照解析 → AK/SK 泄露
六、接管云存储桶
拿到 AK/SK 之后，事情就变得相对”流程化”了。使用云环境利用工具 CF 进行存储桶枚举：
https://github.com/teamssix/cf
工具很快识别出该 AK 对应的云厂商，并列出了其有权限访问的所有存储桶：
存储桶中存放了大量业务数据，包括用户上传的文件、系统配置文件、日志文件等。随后又使用 cloudTools 进行了进一步的管理操作：
https://github.com/dark-kingA/cloudTools
该工具支持多家云厂商，功能覆盖存储桶的增删改查、文件上传下载、远程命令执行等。
七、获取控制台权限
利用泄露的 AK/SK，通过 STS 临时凭证或其他方式成功获取了云控制台的登录权限。
进入控制台后，完整的云资源编排呈现在眼前——该账号关联了大量云主机实例。
八、接管云主机
最后一步，利用云控制台的权限，对关联的云主机执行远程命令。
最终确认可控制的云主机数量：一百余台。
至此，整条攻击链完整走通。
九、攻击链总结
回顾整个过程，关键节点如下：
信息收集 → Web端后台管理系统 ↓Spring Boot 报错页面识别 ↓JS文件分析 → 发现API前缀 /cloud/apis/rms ↓Spring Actuator 未授权访问确认 ↓HeapDump 下载（Cookie绕过） ↓内存快照解析 → AK/SK 泄露 ↓云存储桶接管 ↓云控制台权限获取 ↓百台云主机接管
几个值得记录的点：
Fuzz 不通时不要死磕字典，回归源码和前端代码往往能找到关键线索。这次就是从 JS 里提取到了 API 路径前缀，才打开了突破口。
HeapDump 的”没反应”不等于不存在，需要抓包仔细分析请求和响应，可能是缺少必要的请求头或 Cookie。
从信息泄露到云环境接管，中间缺少的只是一个可用的凭证。HeapDump 中能提取的信息远比 /actuator/env 丰富得多。
十、修复建议
针对本次渗透中涉及的漏洞，建议从以下几个维度进行修复：
| | | | — | — | | 风险点 | 修复方案 | | Spring Actuator 未授权 | 生产环境关闭 Actuator 端点，或通过 Spring Security 配置严格的访问控制 | | HeapDump 可下载 | 禁用 /actuator/heapdump 端点，或限制为内网访问 | | AK/SK 硬编码在代码/配置中 | 使用云厂商的 KMS 服务或配置中心管理密钥，避免明文存储 | | AK/SK 权限过大 | 遵循最小权限原则，为不同服务分配独立的子账号和精细化策略 | | Cookie 校验可被绕过 | 完善身份认证机制，结合 Token 鉴权和请求签名 |
工具参考链接：
#heapdump_tool - HeapDump敏感信息提取工具https://github.com/wyzxxz/heapdump_tool# CF - 云环境利用框架https://github.com/teamssix/cf# 云资产管理工具https://github.com/dark-kingA/cloudTools
声明： 本文所涉及的技术仅用于安全研究和授权测试，相关漏洞均已修复，请严格遵守相关法律法规，切勿用于非法用途。
— END —
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：进击的HACK 《字典跑不出Actuator？从JS前缀到绕过Cookie下载HeapDump》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论