行业
金融科技 · 开放金融
攻击路径
API 配置错误 + IDOR
修复耗时
72 小时
case/01
通过未鉴权的内部 API 取得生产环境完全访问权
API 网关配置错误使管理接口暴露在外，叠加转账路径上的 IDOR，可横向操作任意账户。项目第 2 天发现。
避免的损失：拦截 R$ 4,800 万潜在资金流动
[cases_index]真实项目 · 已脱敏
在它成为新闻之前， 它已经被修好了。
以下案例均在保密协议下作脱敏处理。数字、行业与攻击路径是真实的——客户名称不是。
200+
已交付项目
4,500+
已报告的可利用缺陷
R$ 180M+
避免的潜在损失
行业
健康科技 · SaaS
攻击路径
云配置错误
修复耗时
24 小时
case/02
预发布 S3 存储桶导致 120 万份健康档案暴露
预发布存储桶复制了生产数据，既未加密也无访问控制。在外部 ISO 审计前完成修复。
避免的损失：避免监管罚款 · 未构成须上报事件
行业
工业 · OT
攻击路径
网络隔离缺陷 + 遗留凭据
修复耗时
2 周
case/03
经由老旧 VPN 从办公网横向移动至工业生产网
红队项目，从钓鱼切入。由工程师工作站经使用默认凭据的 VPN 跳入 OT 网络。通过网络隔离、跳板机与多因素认证完成整改。
避免的损失：避免了预计 8 天的产线停工
行业
电商 · B2C
攻击路径
XSS + 会话未轮换
修复耗时
96 小时
case/04
利用链：XSS → 管理员账户接管 → 账户余额
搜索页的反射型 XSS 叠加过于宽松的 Cookie 策略，可窃取管理员会话。在常规渗透测试中发现。
避免的损失：拦截欺诈，估算每月 R$ 230 万
为什么这里每个案例都做了脱敏
把客户的名字和他们曾有的漏洞一起公开，等于让他们被暴露两次：事发时一次，此后长久一次。讲清攻击路径与影响是有教益的；点出受害者只是橱窗，而且会扭曲激励——愿意授权公开的，往往是损失最小的那一个。
- 名称、品牌，以及任何可能指向该公司的细节，一律不写。
- 保留技术攻击路径，因为那才是对读者有价值的部分。
- 在修复完成并经复测确认之前，不予公开。
- 所有材料都要先经客户授权，才会成为公开文字。
反复出现的模式
行业不同、架构不同，可真正走得通的路径却很相似。以下是出现频率最高的几类，值得在启动任何测试之前先看一遍。
// 一个本不该存在的环境
带着生产数据副本的预发布环境、一个旧后台、为演示搭起来却从没关掉的服务。它们通常不在资产清单里，因此也就落在了其他系统都有的防护之外。
// 对象级授权缺失
系统只确认你已登录，却不确认这条记录是不是你的。这是自动化工具最容易漏掉的问题，因为请求看上去完全合规。
// 长期存在的临时权限
为了赶上线而放开的大权限，说好之后收紧。几个月过去它还在，而且已经被继承给了压根不知道自己有这权限的人。
// 放错地方的密钥
暴露在环境变量里的密钥、留在仓库历史中的凭据、被提交进版本库的配置文件里的令牌。这是进入系统最短的路，也是最容易堵上的那条。
// 系统之间的信任
两套应用靠网络位置或共享密钥彼此认证。拿下防护较弱的那一个，就等于拿到了防护更好的那一个；而本该起遏制作用的网络隔离，往往从未被真正测过。
// 没人看得到的告警
事件记下了，告警也发了——却落进了没人查看的队列。技术上已检测到，实际上等于没看见：这个差距只有在不打招呼的演练中才会暴露。
常见问题
01为什么这里没有客户名称？
因为愿意授权公开的，会是损失最小的那一方，而不是案例最有参考价值的那一方。所有材料都在保密协议下脱敏，而技术攻击路径——真正有用的部分——被保留了下来。
02你们能在我们的采购流程中出具推荐吗？
可以，前提是相关方均同意。不过对多数流程而言，真正起决定作用的是您自己项目在复测后出具的结项函：那是直接证据，而不是第三方对别人工作的评价。
03案例和我们相似，是否意味着我们的测试结果也一样？
不会。路径取决于架构、系统集成，以及只有在您自己环境里才会浮现的决策。案例展示的是通常会发现什么，而不是一份会重演的剧本。
04你们会在漏洞修好之前公开它吗？
从不。在修复完成并经复测确认之前，任何内容都不会成为公开文字；即便到那时，也要取得授权。我们对自己的研究采用同一标准，写在漏洞披露政策里。