扫描一款移动应用本应很简单：获取应用、提供访问权限、运行扫描、修复发现的问题。
但在大型企业中，事情很少如此。每一步都可能依赖不同的团队。访问权限、审批和修复很快就会把一次扫描变成一项协调难题。
本周，我们来看看技术和可重复的工作流程如何在测试与修复环节减少这些依赖。
本期还有：Claude 模型触及企业系统、自主 AI 漏洞利用、一个跨租户的 Azure 风险、XCSSET 供应链攻击、明尼苏达州供水系统遭受的网络攻击、用于检查 Android 应用流量的 PCAPdroid、一条可疑的 IT 服务台消息，以及更多内容。
本期内容
🌡️ 威胁等级：高度警戒
⚡ 新闻：五条值得关注的安全新闻
🔎 深度解析：企业安全扫描背后的组织难题
🎣 这是钓鱼吗？
🔬 技术研究：GoPhish 的创建端点如何转移资源所有权
🛠️ 本周工具：PCAPdroid
👤 本周人物：Emanuele Faranda
📅 本周活动：next.app devCon 2026
📚 本周书籍：Practical Reverse Engineering
😅 本周梗图
❓ 离开前的一个问题
让我们开始吧。
在进入本周的新闻之前，先来看看当前的威胁等级。
🌡️威胁等级
⚡ 新闻
Anthropic 的 AI 模型在内部测试期间访问了真实的企业系统
Anthropic 披露，在内部网络安全评估期间，由于一次操作失误意外开放了互联网访问，三个 Claude 模型访问了真实的企业系统。这些模型依靠的是常见技术，包括弱凭据、暴露的端点以及可公开访问的服务，而非新型漏洞利用。该公司在调查此事件期间暂停了网络安全评估，这凸显了将 AI 测试环境与生产基础设施隔离的重要性。
Anthropic：三个 AI 模型借助意外开放的互联网访问，从内部测试环境转向企业系统。
自主 AI 从漏洞发现走到了已确认的漏洞利用
Unit 42 记录了一个讲中文的威胁行为者通过 Hermes Agent 框架使用 DeepSeek 枚举目标、查找公开的漏洞利用代码，并在有限的人工参与下发起攻击。研究人员确认了 三个 Citrix NetScaler 目标遭到数据窃取，以及 11 个 Marimo notebook 端点遭到命令执行。防御方必须为互联网暴露基础设施上已知漏洞被更快、自动化利用的情况做好准备。
自主 AI 漏洞利用：一个 AI 智能体发现目标、找到公开的漏洞利用代码，并攻击了 三个 NetScaler 目标和 11 个 Marimo 端点。
一条 Azure 查询链本可解锁跨客户租户的数据库
Wiz 披露了 CosmosEscape，这是 Azure Cosmos DB Gremlin API 中一条现已修复的漏洞链。据报道，逃逸查询沙箱后会暴露一个平台级密钥，该密钥能够获取客户账户密钥，可能实现跨租户的完全读写访问。Microsoft 表示未发现客户受影响的证据。此案例说明了为什么共享的云网关和控制平面密钥需要特别强的隔离。
CosmosEscape：一条 Gremlin API 查询逃逸出沙箱，暴露了一个可能提供跨客户租户访问权限的平台密钥。
XCSSET 把被投毒的 Xcode 项目变成一条 macOS 供应链路径
Unit 42 分析了 XCSSET v40，这是一个更新后的 macOS 恶意软件变种，通过被入侵的 Xcode 项目针对开发人员。该模块化框架大部分可在内存中执行，通过 macOS 偏好设置实现持久化，干扰安全控制，并投放浏览器劫持组件。由于开发人员工作站通常存有签名资产和生产凭据，可疑的项目构建应被视为潜在的供应链事件，而不是孤立的终端感染。
XCSSET：恶意软件从被入侵的 Xcode 项目出发，经由开发人员工作站，进而触及签名资产和生产构建。
明尼苏达州 30 多个供水系统遭受协同网络攻击
当局正在调查影响明尼苏达州 30 多个供水系统的攻击，其中一起事件曾暂时干扰了某一设施的运行控制。目前未报告对水质造成重大影响，尽管外界担忧可能有伊朗参与，但归因仍未得到确认。这些事件凸显了拥有联网运营技术的小型公用事业单位所面临的暴露风险。移除不必要的外部访问并保持经过测试的手动操作能力，仍然是必不可少的防护措施。
明尼苏达州供水系统：外部攻击触及 30 多个供水系统，导致一次控制中断，而手动操作仍然可用。
🔎 深度解析：
企业安全扫描背后的组织难题
一个安全团队想要扫描一款移动应用。
从纸面上看，扫描一款移动应用很简单：
获取应用。
提供所需的访问权限。
启动扫描。
修复发现的问题。
在较小的组织中，事情确实可以这么简单。请求扫描的人通常能够联系到合适的人，获得所需的东西，完成测试，并把发现的问题交给能够修复的人。
这很容易让人以为，扩展安全测试规模只不过是在更多应用上重复同样的流程。
但在大型企业中，这一假设就站不住了。
企业要在不同的环境和发布周期中测试数百款应用。每款应用都可能有自己的要求，例如：
来自身份团队的测试凭据。
来自网络团队的 VPN 访问权限。
来自基础设施或安全团队的 IP 允许列表配置。
WAF 配置变更。
对加固等移动应用保护措施的支持。
运行扫描和修复其发现所需的东西，往往分散在多个团队中。安全团队必须在每个团队中找到合适的人，并与之协作，扫描才能推进。一旦发现漏洞，负责的团队又必须再次参与，审查并修复它们。
看似简单的四个步骤，很快就变成了一项协调难题。
所以真正的问题是：
当每一次扫描都依赖多个团队时，您该如何扩展安全测试的规模？
适配企业环境的技术
自动化似乎是显而易见的答案。如果扫描可以自动运行，安全测试应该更容易扩展。
但如果每次扫描都需要多个团队提前铺路，或者每个发现都带来更多需要理解、分派和验证的手动工作，那么测试就并非真正可扩展。
仍然可能有人需要提供凭据、开放网络访问、将某个 IP 加入允许列表、修改 WAF 规则，或移除应用加固。扫描器是自动化的，但围绕它的流程却不是。
扫描之后，应用团队还需要清晰的证据、上下文和指导，才能修复发现的问题。
视应用而定，技术可能需要处理带身份验证的测试、连接私有环境、在网络限制下工作，或绕过应用加固和防篡改控制等保护措施。
一旦产生发现，技术应通过提供证据和修复指导让这些发现更易于处理，并在应用修复后支持重新测试。
有些访问权限和人工决策可能仍然必不可少。但技术应当适应企业环境，使每一次扫描和修复周期都不会给其他团队带来同样的工作。
减少组织间的依赖
更好的技术可以减少每次扫描中其他团队所需承担的工作，但无法完全消除他们的参与。
在大型企业中，这些依赖还受到团队政治的影响。每个团队都有自己的优先事项、截止日期和审批流程。对安全团队来说紧急的请求，在其他地方未必会得到同样的重视。
当流程依赖私人关系或反复升级时，进展就可能取决于谁认识谁、谁能推动请求向前。
一个可扩展的工作流程应当：
明确每款应用由谁提供访问权限和审批。
建立一致的流程，在扫描前和扫描期间处理和升级请求。
将发现分派给负责修复的团队。
提供清晰的证据和修复指导。
无需反复手动跟进即可追踪进度。
各团队仍对自己的职责负责，但流程不再依赖私人关系，也不再需要安全团队为每次扫描重新搭建同样的协调流程。
通往可扩展安全测试之路
扩展安全测试规模，并不是要剥夺团队的职责归属。
而是要消除团队之间不必要的摩擦。
这需要能够适配企业环境中访问控制和保护措施的技术，以及让测试、修复和验证职责清晰且可重复的工作流程。
运行一次扫描并修复其发现，或许还能应付。真正的规模考验在于：同样的流程能否在接下来的一百款应用上运转，而无需每次都重新搭建。
🎣 这是钓鱼吗？
您在 Teams 中收到了这条来自 IT 服务台的消息。接下来您会怎么做？
🔬 技术研究
GoPhish 的创建端点如何转移资源所有权
GoPhish 是一个开源平台，安全团队用它来开展钓鱼模拟演练。它管理收件人组、电子邮件模板、落地页、发送配置文件和活动结果。
在我们 2026 年 7 月的源代码评估所审查的 GoPhish 版本中，某些创建端点可以更新已有资源，并将其所有权转移给另一名用户。
这个问题并非由某个明显缺失的授权检查导致。它出现在三种看似正常的行为结合在一起时：
端点接受来自请求的 id。
服务器将当前用户指定为所有者。
数据库操作将已存在的 id 视为更新。
资源接管是如何发生的
相关代码遵循以下模式：
resource.UserId = currentUserID
db.Save(&resource)关键在于 Save。
当资源没有现有 ID 时，数据库会创建一条新记录。但当请求中包含一个已存在的 ID 时，同一操作可能会改为更新那条记录。
假设有两名 GoPhish 用户，他们本不应能访问彼此的资源。
用户 A 创建了一个收件人组。随后用户 B 发送一个包含用户 A 所建组 ID 的创建请求。
应用将用户 B 指定为所有者，然后保存该对象。由于该 ID 已经存在，数据库会更新原有记录，而不是创建新记录。
请求看起来是一次创建，结果却是一次所有权转移。
该模式影响收件人组、电子邮件模板、落地页和 SMTP 配置文件。对于组而言，已有的收件人关联在转移后可能仍然保留，使新的所有者能够访问该组及其目标。
对于其他资源类型，已确认的影响是未经授权的接管和修改，而不一定能访问其原有内容。
端点说的是“创建”，但数据库看到的是一个已存在的 ID，于是执行了更新。
为什么访问检查没有阻止它
部分读取和删除操作已经同时检查了资源 ID 及其所有者。
这可能让访问控制模型看起来是安全的：用户只能获取或删除自己的资源。
但授权还必须保护资源的创建和更新方式。
如果某条写入路径接受已存在的 ID，并在保存前替换所有者，就可能绕过施加在读取和删除操作上的保护。攻击者并不会直接获取他人的资源，而是先让应用把它当作自己的资源。
这就是为什么仅仅把它描述为 IDOR 会遗漏部分问题。更深层的问题在于，应用没有清晰地区分创建与修改。
问题是如何被发现的
仅看控制器是看不出这个发现的。
审查必须沿着请求穿过多个层次：
POST request
↓
Client-controlled resource ID
↓
Current user assigned as owner
↓
Database Save operation
↓
Existing record updated Agentic Deep Scan 帮助在整个代码仓库中识别出了这一模式，但只有在完整路径经过人工审查、并使用两个合成用户在本地复现之后，该结果才被纳入。
这一区别很重要。一个可疑的数据库调用并不自动等于漏洞。真正的问题在于，用户可控的数据能否在跨越安全边界的条件下到达那里。
如何防范
创建和更新操作应当遵循不同的规则：
不要在创建请求中接受资源 ID 或所有权字段。
创建资源时使用显式的插入操作。
更新资源时同时要求资源 ID 和当前所有者。
为创建、自助更新和管理变更分别保留独立的请求结构。
使用两个不同的用户测试每一种资源类型。
一个有用的回归测试很简单：
用户 A 创建一个资源。
用户 B 提交一个包含用户 A 资源 ID 的创建请求。
应用必须拒绝该请求。
原所有者、内容和相关记录必须保持不变。
安全团队可以从中学到什么
框架和 ORM 辅助函数可能会把重要的安全决策隐藏在 Save 这类便捷函数背后。
一个路由可能叫“create”，API 文档可能把它描述为“create”，但真正决定发生什么的是数据库。
审查访问控制时，不要只问用户能否读取或删除他人的记录。
还要问：是否有任何创建路径会悄无声息地变成更新路径——以及这次更新能否改变数据的所有者。
版本说明：本研究描述的是 2026 年 7 月所审查的 GoPhish 源代码和配置。应将其视为该次评估的快照，而非对当前版本的陈述。
🛠️ 本周工具
PCAPdroid
检查 Android 应用的网络流量需要一台已 Root 的设备或一套复杂的测试环境。
并非总是如此。
PCAPdroid 让安全团队无需 Root 即可直接在 Android 上捕获这些流量。这有助于揭示用户和安全团队在屏幕上看不到的连接。
PCAPdroid 的工作原理
PCAPdroid 使用本地 VPN 观察流量，同时让流量保留在设备上。分析人员可以监控整部手机，也可以专注于某一个应用。
捕获开始后，PCAPdroid 会显示应用连接了哪些服务器、连接何时发生以及交换了多少数据。这使得未知服务、旧服务器和后台连接更容易被发现。
捕获结果还可以在 Wireshark 中打开以便更仔细地查看。经过额外配置后，PCAPdroid 有时还能显示加密流量的内容，不过这并非对每个应用都有效。
一个简单的例子
设想一家公司在其 Android 应用中加入了一个新的分析工具。
在发布更新之前，分析人员在 PCAPdroid 中选中该应用并开始捕获。他们登录、打开不同的界面，然后让应用处于闲置状态。
大多数连接都指向公司的 API 和预期的分析服务。然而，登录后出现了另一个域名，并且在应用处于后台时仍持续接收流量。
这个连接可能是合法的，但团队现在知道了它的存在、它何时开始，以及该从哪里着手调查。
它不能替代什么
PCAPdroid 只显示网络活动。它不会发现不安全的存储、薄弱的身份验证，或其他不会出现在流量中的问题。
捕获结果还可能包含敏感信息，因此应在经授权的测试设备上生成，并谨慎处理。
👏 本周人物
Emanuele Faranda
本周，我们要介绍的是 Emanuele Faranda，他是 PCAPdroid 背后的独立开发者。
从 Android 应用捕获网络流量通常需要一台已 Root 的设备或一套复杂的测试环境。Emanuele 打造了 PCAPdroid，让这一过程变得更简单，使人们无需 Root 即可直接在 Android 上监控应用的连接。
该项目帮助安全研究人员、开发人员和注重隐私的用户查看应用联系了哪些服务器、检查其流量，并导出捕获结果，以便在 Wireshark 中做进一步分析。
他的作品还包括 PCAPdroid-mitm（增加了 TLS 流量解密功能），以及 zdtun（支撑 PCAPdroid 免 Root 捕获的网络组件）。
感谢他让 Android 流量分析变得更加易用，并持续以开源项目的形式维护这些工具，Emanuele Faranda 当选本周人物。
📅 本周活动
next.app devCon 2026
如果您的工作介于移动开发与应用安全之间，next.app devCon 值得写进您的日程。
该活动汇集了八场开发者大会，包括 droidCon、flutterCon、swiftCon、reactCon 以及 masCon——后者是其专注于移动应用安全的大会。
在为期三天的活动中，技术演讲和研讨会涵盖Android、iOS、跨平台开发、智能体编程、工程领导力以及移动安全。
对于 AppSec 团队来说，这样的组合很有价值：masCon 专注于保护移动应用，而其他大会则展示了这些应用是如何构建的，以及开发人员正在采用哪些工具和框架。
📍 德国柏林 CityCube
📅 2026 年 10 月 7–9 日
📚 本周书籍
Practical Reverse Engineering
作者：Bruce Dang、Alexandre Gazet、Elias Bachaalany 和 Sébastien Josse
当您看不到软件的源代码时，如何理解它在做什么？
Practical Reverse Engineering 讲解了分析人员如何研究 x86、x64 和 ARM 平台上的已编译软件。书中还涵盖 Windows 内核、驱动程序、调试、代码混淆以及分析过程中使用的工具。
借助实用的演练和练习，本书帮助读者建立调查恶意软件、理解软件保护机制和检查陌生程序所需的底层知识。
对于希望不止于运行逆向工程工具、而是理解底层究竟发生了什么的安全研究人员和工程师来说，这是一本值得一读的书。
😅 本周梗图
如果您的安全测试流程在每次扫描前后都依赖多个团队，而自动化只能简化其中一部分工作，您会如何扩展它的规模？
The Breach Brief，Ostorlab 团队