Snake Oilers：watchTowr、XBOW 与 CoreView
这一期 Snake Oilers 由三家安全厂商付费赞助。主持人 Patrick Gray 依次请 watchTowr、XBOW 和 CoreView 介绍产品，话题从刚披露的漏洞如何临时缓解，延伸到 AI 代理如何验证应用漏洞，最后落在 Microsoft 365 租户里持续累积的配置与权限问题。节目是厂商陈述，不是横向评测；不过三段对话都指向同一种时间压力：风险出现后，团队何时才能拿到足够的证据并采取动作。
确认外部暴露、观察设备被利用后的痕迹，并在补丁前复用既有边界控制。
以运行时黑盒测试处理自定义应用，重点放在把线索验证成可证明的利用。
集中 Microsoft 365 的配置、应用和权限信息，处理漂移与遗留状态。
watchTowr：补丁流程之外的第一道缓解
watchTowr 创始人 Ben Harris 把公司的工作拆成几层：先从全球蜜罐网络里观察攻击者正在做什么，再检查客户面向互联网的资产是否暴露，最后把这些信息接入快速反应流程。按他的说法，团队希望从漏洞披露或早期威胁信号出现，到确认某个组织是否受影响，控制在数小时内。
这套流程回应的现实限制很直接：打补丁不是一键操作。大型或受监管组织还要考虑稳定性、业务可用性和变更控制。Harris 认为，若能先让某个漏洞更难被利用，运维团队就能按自己的节奏测试和部署正式修复。这里的临时缓解不能替代补丁，它只是缩短暴露窗口的一种方式。
Harris 介绍，watchTowr 会把漏洞复现结果转成 WAF、IDS 或 IPS 规则，接入客户已有的 Akamai、Cloudflare、Imperva 等企业级 WAF。他把规则生成和下发的速度视为核心价值：目标是在漏洞被知晓后的 30 分钟内完成；两天后才出现同样规则，对最初一波利用的拦截价值会小得多。
蜜罐是其中较有技术含量的一环。为了复现某个漏洞，研究人员需要取得同一产品的不同固件版本，并比较已修补和未修补版本的差异。Harris 说，他们为此开发了 Stab：一个通过 hypervisor 注入虚拟设备、能取得 shell 的内存驻留组件。之后，团队把这类设备做成可被攻击的蜜罐，并在上面部署自己的可观测能力。
这样做是为了补足网络设备常见的遥测缺口。Harris 描述的风险是：攻击者先攻破设备并留后门，管理员随后迅速打上补丁；漏洞本身可能消失，后门却还在。蜜罐上收集到的 web shell、命令与其他利用痕迹，可以反过来变成客户环境的远程检测线索。
他还认为，LLM 降低了复现漏洞和开发利用所需的专业门槛，攻击面已不再局限于 VPN、远程访问系统、数据管理产品和邮件服务器等传统边界设备。watchTowr 的应对是让研究人员为内部 harness 提供方法，再围绕客户实际使用的技术规模化复现漏洞。这是 Harris 对攻击速度加快的一种产品化回应。
XBOW：漏洞线索还要经得起利用验证
XBOW 安全实验室负责人 Fede Kirschbaum 介绍的产品，是面向应用安全的自主 AI 渗透测试系统。目前的重点是企业自行开发、对外暴露的应用。与生成一张很长的问题清单相比，他更在意系统能否把一个发现放回应用上下文，继续确认它是否真的能造成影响。
他用 SQL 注入说明这个差别。一个时间延迟可能只表明输入影响了后端；后续测试仍要判断能否读取数据、取到令牌，或构造可用的会话状态。XBOW 的产品目标，是在发现问题后继续沿着这些路径验证，而不是停在初步信号上。
| 阶段 | XBOW 在访谈中描述的任务 | 读者需要区分的结果 |
|---|---|---|
| 发现 | 寻找应用中的异常与可疑输入输出 | 只是线索，不等于已经造成影响 |
| 解释 | 结合应用状态、已有发现与相关策略判断价值 | 线索是否能在该应用里发挥作用 |
| 验证 | 继续尝试形成利用并证明后果 | 能否给出可验证的影响 |
Kirschbaum 将系统分成身体和大脑。身体是 harness，负责调用工具并解释输出；大脑则是混合模型。不同模型在他的描述里有不同倾向：有的更激进，有的更谨慎，有的擅长读取源码，却不擅长与正在运行的网站交互。产品默认采用运行时黑盒方式，输入一个 URL 即可启动；凭据和源码可以提供，但不是前提。
协调器负责管理多个专项求解器。每个求解器只盯住一种任务或漏洞类型，输出会进入较大的共享上下文；若新发现对其他求解器有用，系统会把相关输出放入同一上下文，继续尝试验证利用。Kirschbaum 用人类渗透团队的分工来类比这种结构：有人专门处理一类技术难题，其他人再接手相关线索。
两位嘉宾没有把自动化描述成对人类工作的终结。主持人认为，测试商品化会让更多组织负担得起基础检查，但人仍需要确定范围、处理偏离脚本的情况，也要在模型过早放弃时提供方向。Kirschbaum 也把模型的特点归为持续和穷尽式尝试，而不是简单地比人更聪明。他预期渗透测试、漏洞扫描和黑盒应用测试会逐渐汇入一层更强调验证的工作。
CoreView：Microsoft 365 的配置状态也需要被保存
CoreView 的 Andrew McAllister 把 Microsoft 365 看作一套需要持续治理的平台，而不只是云端办公套件。他介绍，CoreView 接入租户后，通过 Graph API、其他 API 和自有脚本收集服务使用的元数据，也读取工作负载的配置、设置和策略。目标是把原本散落在大约 30 个 Microsoft 365 管理控制台中的信息放进同一处。
他特别区分了数据和配置。许多组织会备份邮件、文档等内容，却没有留存条件访问、应用权限、邮件转发和其他关键设置的可恢复基线。McAllister 说，CoreView 每天保存不可变的配置备份，并近乎实时地发现关键设置的变化；运营或安全团队可把有问题的设置恢复到已知健康的状态。这是他所说的配置层业务连续性与灾难恢复。
第三方 Entra 应用是另一处风险来源。McAllister 认为，旧的自建应用可能使用较弱的权限模型，却保有读写权限；攻击者不必先攻破租户管理员账号，也可能从应用本身进入环境。CoreView 的主张是盘点这些应用，指出读写权限和没有更新的证书，为应用建立治理生命周期，并将常用修复做成可排程的策略。
访谈中的配置漂移例子都很日常：管理员临时启用不安全的邮件取信协议；Exchange Online 邮箱留下自动转发规则；项目结束后，SharePoint 或 OneDrive 的外部共享没有关闭；用户或管理员没有默认启用多重身份验证。McAllister 说，平台既要让这些状态可见，也要支持用自动化与排程的修复动作处理偏离。
从方便的授权，到长期遗留的风险
McAllister 讲了几类未具名的客户评估结果。一处大型公共部门租户有 33 名全局管理员，原因是直接赋予高权限比建立细分管理角色更方便；他表示，Microsoft 建议一个租户只保留三到四名全局管理员。另一些重要租户把邮箱分配给全局管理员账号，使高权限账号同时具备更大的钓鱼暴露面。
他还提到一名客户发现有管理员从海外地点登录，而对应的基于地理位置的条件访问策略没有正确配置。大学环境则可能积累出 6 万至 7 万个为项目创建的 SharePoint 站点；有的外部共享仍然开放，有的已经没有管理员，站点内却还保留个人可识别信息。案例的名称和技术细节没有在节目中公开，它们在这里仅用于说明 McAllister 所说的权限和配置会随着日常操作逐步堆积。
安全处置的三个时间窗口
三家厂商处理的是不同层面的工作流。watchTowr 想缩短漏洞信号与正式补丁之间的暴露时间；XBOW 想缩短发现可疑行为与证明其影响之间的距离；CoreView 想缩短配置改变与下一次人工审计之间的间隔。作者概括：这三个时间窗口说明了节目中反复出现的运营难题，安全团队还需要把告警变成可核实、可处置的状态。