文章总结： 文章讲述一次内网渗透测试经历，通过Redis未授权访问漏洞获取服务器权限，意外发现生产数据库备份文件，暴露用户表、订单表及支付密钥等敏感数据。问题根源在于测试环境直接升级为生产环境，安全配置未更新，且资产归属不清导致无人管理。建议加强资产清单管理和安全配置审查，避免类似风险。 综合评分： 86 文章分类： 渗透测试,内网渗透,漏洞分析,安全建设

一次有趣的挖洞经历：漏洞窟窿有大！安全团队说这资产归测试管，测试说这资产归安全团队管，这事闹的……

原创

是老A 是老A

老A搞安全

2026年7月2日 07:57 贵州

在小说阅读器读本章

去阅读

一位深耕网络安全的老兵，目前是一家安全公司的技术分管，擅长渗透测试及安全培训方向，老A的愿望是大家没烦恼，一切顺心！

讲个真事儿

有一次做内网渗透测试，客户给了一个网段，让我们模拟攻击者从内部横向移动。

目标很明确：能拿到多少敏感数据，就算多少成果。

搭好隧道，扫了一圈内网资产，发现了一台Redis。

Redis？你知道的

它是一个数据库，一般用来存缓存数据。很多网站登录状态、临时数据都会放里面。

但这台Redis有几个问题：

端口是敞开的（6379，Redis默认端口）

没有密码

用root权限跑的

什么意思呢？

打个比方：你家大门没锁，钥匙挂在门把手上，而且整个房子的管理员权限谁都能拿。

这基本等于把家底亮给所有人看。

常规操作：先拿权限

Redis未授权访问，在渗透测试里算是个“经典漏洞”。

怎么利用呢？思路是这样的：

Redis有个功能，可以把数据“备份”到指定文件。如果能控制备份路径和文件名，就能在服务器上写文件。

具体操作不展开说技术细节，你就理解为：

利用Redis的备份功能，往服务器里写入一个定时任务，让服务器主动连接我的机器。

这样我就拿到了这台服务器的控制权。

整个过程，不到十分钟。

拿下来的时候我想：“今天的任务可能提前完成了。”

拿下服务器之后，我习惯性地翻了翻目录，看看有什么“意外收获”。

结果在 /data/backup/ 目录下，发现了一堆备份文件。

看清楚文件名之后，我头皮发麻：

• mysql_backup_2024-09-15.sql.gz
• mongodb_backup_2024-09-15.tar.gz
• redis_dump_2024-09-15.rdb
• k8s_config_backup.yaml

这是整个公司的生产数据库备份！

每天凌晨自动打包，存了近30天的。包含了：

• 用户表：手机号、邮箱、加密密码

• 订单表：交易记录、金额、支付状态

• 支付回调密钥：明文存储

生产环境的K8s配置文件：包含所有服务地址和认证凭证

我当时第一反应不是“能交差了”，而是：

“客户知不知道这事儿？”

问题的根源在哪里

后来复盘的时候，找到了原因。

这台Redis，最初是测试环境用的。

测试环境嘛，怎么方便怎么来：

• 不设密码（方便调试）

• 用root权限跑（省事）

• 端口随便开放（懒得配置防火墙）

后来这个测试环境，直接升成了生产环境。

怎么升的？

运维说：“这台机器测了几个月挺稳定的，直接切流量上去吧。”

然后它就变成生产服务器了。但安全配置还是测试环境的配置

• 测试时方便的方式，到了生产环境变成了“未授权访问”

• 测试时存备份的习惯，到了生产环境变成了“所有数据打包放在那”

• 测试时用的弱口令，到了生产环境变成了“通用密码”

更关键的是：这台服务器不在客户的安全资产清单里

安全团队以为“测试环境归测试管”

运维觉得“这台已经转生产了，应该安全团队管”

两头没人管，就挂在网上没人知道

⚠️ 法律声明：以上内容仅供安全学习和授权测试使用。未经授权的漏洞利用属于违法行为，请勿对未经授权的目标进行测试。

免责声明：

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

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

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

本文转载自：老A搞安全 是老A 是老A《一次有趣的挖洞经历：漏洞窟窿有大！安全团队说这资产归测试管，测试说这资产归安全团队管，这事闹的……》