2026-08-28 04:59:54 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： CISA红队评估显示组织A因检测工具未调优、组织孤岛和审批障碍未能发现入侵,而组织B通过快速隔离和成熟运营有效响应。核心教训包括调优告警规则、打破组织孤岛、重视云安全风险,如过度权限和缺乏凭证轮换。建议建立行为基线、实施工作负载条件访问并定期审查云凭证。 综合评分： 85 文章分类： 红队,安全运营,云安全,安全意识,实战经验

两个 SOC 的故事：两次红队评估带来的启示

原创

Groot Groot

securitainment

2026年8月26日 11:46 中国香港

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

公告概览

执行摘要

美国网络安全与基础设施安全局（CISA）同时对两个组织开展了红队评估，并观察到截然不同的防御结果。

在两个环境中，红队最终都实现了完整的域环境入侵，并访问了敏感业务系统（SBS）和云资源：

组织 A 未能发现或遏制红队活动。
组织 B 迅速发现初始入侵、隔离受影响系统，迫使红队转为“假定已入侵”（assume breach）模式继续评估。

该公告分析了红队的攻击活动和两个组织的防御响应，并总结了可帮助关键基础设施组织强化 IT、云和运营技术（OT）环境检测、响应及保护能力的经验。

核心教训

未经调优的检测工具会造成威胁漏报。缺乏明确基线和告警过滤时，大量误报及日常告警会淹没真正的威胁。
组织孤岛和繁琐的审批流程会妨碍事件响应。检测工具的效果取决于背后的人员、流程和程序。
云环境的风险经常被低估。组织普遍缺少云安全控制，以及应对云环境失陷的成熟程序。

关键行动

建立并持续维护行为、软件和网络流量基线，调优规则以降低告警噪声。
打破组织孤岛，赋予网络防御人员快速处置事件的权限。
为工作负载身份实施 Conditional Access，并监控过度或未使用的权限。
建立并定期审查云环境中 access token 和 refresh token 的检测、撤销及补救程序。

技术细节

评估背景

CISA 红队通过模拟真实恶意网络行动，评估组织发现、调查和响应攻击的能力。红队会尝试在不被发现的情况下获取并维持网络访问权，并接近可能对组织运营、财务或客户数据造成重大影响的敏感业务系统。

两次评估使用了类似的攻击手法：

组织 A 属于政府服务与设施领域。
组织 B 属于供水及污水处理系统领域。

红队还尝试访问云资源，并在不真正侵入生产 OT 系统的前提下，证明自己能够接近组织 B 的 OT 网络。

组织 A

初始入侵

红队在侦察阶段发现一个使用默认凭证的 Web 应用。多个内置账户允许红队从内部邮箱地址发送邮件。

红队利用该内部地址发送钓鱼邮件，成功控制了四台工作站。

进入工作站后，红队运行了经过修改的 BloodHound collector。该工具经过定制，可规避静态 EDR 特征，并收集以下 Active Directory（AD）信息：

用户和计算机；
域组及组织单位；
访问控制列表；
Group Policy Objects（GPO）；
用户、设备和权限之间的关系。

其中一台被控制的工作站仍使用默认的 Machine Account Quota（MAQ）值 10，意味着普通用户最多可以向域中添加十个计算机账户。

利用 ADCS 获取高权限

红队发现多个 Active Directory Certificate Services（ADCS）证书模板存在 ESC1 配置错误。

该错误允许低权限用户代表其他用户或计算机申请证书，包括高权限账户。红队随后：

利用错误配置的 MAQ 创建机器账户；
使用存在 ESC1 问题的 ADCS 模板申请该机器账户的证书；
获得为其他任意用户账户申请证书的能力；
利用这些证书进行横向移动和权限提升。

红队最终取得了域环境中的高权限。

攻破敏感业务系统

红队首先利用此前收集的 AD 数据识别与敏感业务系统相关的用户和组，然后查询 System Center Configuration Manager（SCCM），确定用户与工作站之间的关系。

攻击路径包括：

识别有权访问敏感系统的用户；
从 SCCM 服务器横向移动到目标用户的工作站；
搜索凭证和连接配置；
使用找到的凭证访问敏感业务系统；
验证管理员权限是否足以影响系统的机密性、完整性或可用性。

红队分别攻破了三个敏感业务系统：

SBS 1：在管理员工作站上发现明文数据库凭证。
SBS 2：找到 SQL Developer 工具的 connections.json 和 product-preferences.xml 文件，解密后获得数据库明文密码。
SBS 3：在用户主目录的配置文件中发现长期有效的静态 AWS IAM 凭证。组织没有设置凭证到期或轮换机制，因此这些凭证不会自动失效。

红队还攻破了 Distributed File System（DFS）的根目录。由于虚拟桌面的本地文件与 DFS 同步，这使红队无需等待用户保持活动会话，就能搜索数千名用户的云配置、数据库连接文件和凭证。

最终，红队在没有受到任何防御干预的情况下获得了所有目标敏感业务系统的管理员权限。

攻破 Microsoft 云环境

红队随后针对拥有高权限 Application permissions 的 Microsoft Entra ID 应用。这类权限允许应用在没有用户交互和同意的情况下访问数据。

传统用户 Conditional Access 通常无法约束这些应用。CISA 指出，Microsoft 的 Conditional Access for workload identities 可以把访问策略扩展到 service principal，但红队在评估中没有见到组织实际使用这项功能。

红队执行了以下步骤：

使用 AzureHound 和 ROADrecon 枚举云资源、应用、权限和所有者；
识别拥有高权限 Microsoft Graph API 权限的应用；
定位应用所有者并横向移动到其设备；
获取该用户的 Primary Refresh Token（PRT）；
使用 PRT 申请 access token 和 refresh token；
使用 access token 为目标应用添加新的 client secret；
使用新 secret 以目标应用身份申请 token；
冒充该应用，通过 Microsoft Graph API 读取目标电子邮件。

被利用的权限包括：

Mail.Read
Mail.ReadWrite
Chat.Read.All
Files.Read.All
Application.ReadWrite.All
AppRoleAssignment.ReadWrite.All

红队因此可以读取 SOC 人员的邮件，确认安全团队是否意识到系统已被入侵。

组织 A 的响应

组织 A 未能有效响应红队活动。

红队在 SOC 工作站上：

捕获屏幕截图；
部署键盘记录器；
获取 Microsoft Teams 消息；
读取 SOC 人员邮件。

SOC 实际上收到了与红队活动相关的中、低严重度 EDR 告警，但没有采取行动。正常业务操作产生的数千个误报告警——其中许多严重度甚至更高——掩盖了真正的攻击信号。

组织 A 同时存在多个 SOC 和多套 EDR，但各团队之间缺乏沟通，也无法查看彼此的检测工具。SOC 与系统所有者之间同样缺乏协作。

在一个案例中，防御人员无法确认触发告警的 SCCM 系统由谁负责、用于什么目的以及其正常行为是什么，最终将真实攻击错误地标记为误报。

CISA 认为，问题根源包括：

缺少标准化告警升级程序；
SOC 人员处置权限有限；
不同安全团队之间缺少可见性；
系统所有者和 SOC 之间缺乏沟通。

组织 B

初始入侵和快速隔离

红队从公开网站收集员工邮箱地址并发动定向钓鱼攻击。三名用户点击恶意链接，红队因此进入三台工作站。

每次 payload 执行都会触发一条中严重度告警：

“一个可执行文件加载了意外的 DLL 文件。”

SOC 分别在约 10 分钟、2 分钟和 20 分钟内完成告警分类并手动隔离三台工作站，成功终止红队与这些设备之间的 Command and Control（C2）通信。

由于初始立足点被清除，红队不得不转为“假定已入侵”模式。参与评估的组织 IT 人员在指定内部主机上执行红队 payload，以模拟红队未被发现时本应保留的普通用户访问权限。

AD 权限提升

红队发现组织 B 允许所有域用户创建机器账户，于是创建了一个名称类似合法设备的新机器账户。

这使红队能够从自己控制的 Linux 工作站运行工具，并通过已控制主机代理流量，从而绕过主机上的 EDR 限制。

虽然 BloodHound 数据没有立即暴露权限提升路径，但红队在 SCCM distribution point 上发现一个 XML 文件，其中包含域服务账户的明文凭证。

该服务账户由于所属组配置不当，对接近 1,000 个域账户拥有控制权，并对一个域控制器拥有 AllExtendedRights 权限。

红队利用这一权限执行 resource-based constrained delegation 攻击，获得 DCSync 权限，进而提取 AD 账户凭证。红队还取得了 krbtgt 账户信息；真实攻击者可以利用它伪造 Golden Ticket，并冒充域内任意用户。

攻破敏感业务系统

红队利用已收集的 BloodHound 数据，识别到一个能够通过 Kerberos 访问敏感 Web 服务器的用户账户。

由于本地 AD 已被攻破，红队能够：

使用 DCSync 获取目标用户的 AES256 密码哈希；
使用该哈希申请用户的 Kerberos Ticket-Granting Ticket（TGT）；
使用 TGT 为 Web 服务器的 Service Principal Name（SPN）申请服务票据；
将票据导入红队控制的 Windows 虚拟机；
通过受控主机上的 SOCKS proxy 将流量转发到组织 B 网络；
冒充合法用户访问敏感业务系统。

接近 OT 网络

红队在一台 IT 工作站上发现 RDP 文件，表明该用户可能拥有 OT 网络的远程访问权限。

红队确认该工作站能够访问 OT DMZ 中的 bastion host（跳板机），随后使用发现的 FTP 凭证通过 SSH 登录。

进入 bastion host 后，红队已经能够观察 OT 网络。他们尝试在服务器上执行多个 C2 payload，但该主机禁止向互联网建立出站连接，因此 callback 无法到达红队基础设施。

这些 payload 触发了告警，SOC 随即隔离该主机。

从本地 AD 转向 Entra ID

组织 B 使用混合身份环境，本地 AD 用户凭证会同步到 Entra ID。

红队找到负责同步的 Entra ID Connect 服务器，并使用 ADConnectDump 获得：

本地 Microsoft Online（MSOL）账户的明文凭证；
云端 Sync_[redacted] 账户的明文凭证。

Sync_[redacted] 本不应允许交互式登录，但该账户没有启用 MFA。红队使用它登录 Azure Portal，并为 AzureHound 和 ROADrecon 取得访问令牌，以收集租户中的 Entra ID 数据。

该异常登录触发了 Microsoft 自动告警，组织 B 的 SOC 随后封锁了该账户。

滥用 Seamless SSO

红队在本地 AD 中发现一个名称包含 AZURESSO 的计算机账户。该账户属于 Seamless SSO 实现的一部分，允许用户使用 Kerberos 票据开始 Entra ID 身份验证。

红队随后：

使用 DCSync 获取目标用户的加密凭证；
使用 Rubeus 的 asktgs 模块申请 SSO 服务票据；
将服务票据导入红队工作站；
通过组织 B 网络内的 SOCKS proxy 访问 Azure Portal；
使用合法 Kerberos 票据，使流量看起来来自受信任 IP 地址。

这种方法允许红队以任何已同步至 AD 的用户身份开始登录 Entra ID，而无需取得用户的明文密码。

如果账户启用了 MFA，红队仍需完成第二因素认证。因此，可成功登录的主要是未启用 MFA 的服务账户。

利用高权限应用读取所有用户邮件

红队发现一个应用拥有读取、写入和发送组织 B 所有用户邮件的权限。该应用的所有者是一个已在 AD 中禁用、但仍与云端同步的账户。

红队：

在本地环境中重新启用该账户；
使用 DCSync 获取其凭证；
使用 AES256 哈希申请 Kerberos 票据；
使用票据登录 Entra ID；
为高权限应用添加新的 client secret。

由此，红队能够从公共互联网读取组织 B 环境中所有用户的邮件。

组织 B 的响应

组织 B 在红队获得初始访问权限后迅速分类告警并隔离设备，体现了成熟、主动的安全运营能力。

有效措施包括：

迅速隔离三台受钓鱼攻击影响的工作站；
分析并重新部署受影响设备后才恢复上线；
阻止 OT DMZ bastion host 向互联网建立连接；
在发现恶意 payload 后迅速隔离 bastion host；
对异常 Azure Portal 登录触发自动告警；
针对“陌生登录属性”和“可疑 API 流量”配置 Entra ID 自定义检测；
识别 AzureHound user agent；
对超过 Microsoft Graph API 请求阈值的账户发出告警。

但组织 B 仍存在明显问题：

Seamless SSO 相关账户缺少 MFA；
应用权限过大；
AD 和服务账户配置错误；
域服务账户对域控制器拥有过度权限；
OT 系统凭证以明文保存在跳板机；
IT 与 OT 之间仍存在可被用于横向移动的连接路径；
云环境的响应和补救流程不够成熟。

经验教训

未调优的检测工具会导致威胁漏报

组织 A 没有调优检测工具，SOC 面临无法管理的告警量。相同的红队活动在组织 B 触发了快速处置，但在组织 A 却被大量误报和正常业务告警掩盖。

组织 B 已建立正常活动基线并调优规则，因此异常行为更加突出，防御人员可以迅速识别并响应。

没有明确基线和告警过滤时，误报会隐藏真实威胁。组织应持续调优规则，使分析人员专注于真正的安全事件。

组织孤岛和审批障碍会破坏事件响应

组织 A 的多个 SOC 互不协作，SOC 与系统所有者之间也缺少沟通。安全人员不清楚自身权限和责任，也没有明确的告警升级程序，只能采取“等等看”的方式。

组织 B 则赋予防御人员快速行动的权限。SOC 能够分类告警、调查根本原因、识别配置错误，并与工程团队协调修复。

检测工具的效果取决于支持它们的人员、流程和程序。SOC 不应孤立运作，防御人员必须具备明确且不受过度审批阻碍的处置权限。

云环境风险被低估

两个组织都向云应用授予了过度权限，并缺少成熟的云环境入侵检测与补救流程。

主要风险包括：

使用不会过期的长期静态 AWS IAM 凭证；
没有为 workload identities 部署 Conditional Access；
云应用拥有过度宽泛的权限；
缺少撤销被盗 access token 和 refresh token 的程序；
攻击者即使被逐出本地网络，仍可能利用有效云 token 重新进入环境。

主要安全问题

ADCS 配置错误

组织 A 的证书模板存在 ESC1 配置错误，允许低权限用户申请可用于冒充其他用户的证书。

Machine Account Quota 配置不当

组织 A 的 MAQ 为默认值 10。
组织 B 将所有域用户的 MAQ 设为 1,000。

这允许普通用户在域中创建机器账户，为权限提升和横向移动提供机会。

服务账户权限过大

组织 B 的一个服务账户对域控制器拥有 AllExtendedRights，允许红队执行 DCSync 并最终完全控制域环境。

明文凭证

两个组织的工作站、XML 文件、数据库连接配置和跳板机中均存在明文凭证。

端点管理系统缺少额外保护

红队利用 SCCM 横向移动到用户工作站。CISA 指出，SCCM、Jamf 和 BigFix 等端点配置管理系统拥有覆盖大量设备的高权限，应被视为 Tier 0 或高价值资产。

普通账户被授予管理员权限

组织 B 存在标准用户被错误加入高权限 AD 管理组的情况。

MITRE ATT&CK 技术

侦察与资源准备

T1589.001：收集默认凭证。
T1589.002：从公开网站收集员工邮箱。
T1588.002：使用 AzureHound、ROADrecon 等公开工具。

初始访问与执行

T1566：钓鱼和定向钓鱼。
T1204：诱导用户点击恶意 payload。

持久化与权限提升

T1136.002：创建域机器账户。
T1649：窃取或伪造身份验证证书。
T1003.006：使用 DCSync 获取域凭证。
T1558：窃取或伪造 Kerberos 票据。

凭证访问

T1552：查找不安全或明文凭证。
T1552.001：从配置文件中提取凭证。
T1003：转储操作系统和云同步账户凭证。

发现与横向移动

T1087.002：发现域账户。
T1018：发现远程系统。
T1069.002：发现域组。
T1615：发现 Group Policy。
T1033：识别系统所有者和用户。
T1526：发现云服务。
T1021.004：通过 SSH 访问远程系统。
T1090.001：使用内部代理转发流量。

收集与访问

T1550.001：使用应用 access token。
T1114：收集电子邮件。
T1113：捕获屏幕。
T1056.001：键盘记录。
T1213.005：获取 Microsoft Teams 消息。

缓解措施

建立基线并改善监控

持续维护已安装工具、软件、账户行为和网络流量的正常基线。
调整检测工具和告警机制，区分正常管理行为与潜在攻击活动。
过滤例行业务活动和误报，使异常行为更容易被识别。

消除组织孤岛和审批障碍

加强 IT、安全和业务团队之间的定期沟通。
使用联合演练、共享工具和跨职能团队。
将检测能力与事件响应工作流直接整合。
明确防御人员的职责、权限和升级路径。
允许安全人员在无需过多批准的情况下隔离系统、阻止流量和执行紧急遏制。
定期开展事件响应演练，验证团队协调和授权机制。

强化云安全控制

建立 access token 和 refresh token 的检测、撤销及补救流程。
自动撤销受影响 token，并定期进行访问审查。
根据受信任网络位置、设备合规状态和风险信号限制访问。
监控 workload identity 的登录日志和策略评估结果。
定期检查应用权限，删除不必要权限。
审计 service principal 凭证并轮换 secret 或证书。
禁用旧版和不再使用的账户。
为所有用户、管理员和高权限云账户启用抗钓鱼 MFA。
安全存储密钥和 secret，并强制执行轮换周期。
针对异常 API 调用和异常登录位置配置自动告警。
使用 User and Entity Behavior Analytics（UEBA）识别异常凭证或 token 使用。
为高权限账户实施 Just-in-Time（JIT）访问，避免长期管理员权限。

强化 Entra ID

为 workload identities 部署 Conditional Access。
监控拥有应用身份访问权的主体。
检测过度或未使用的权限。
使用 Microsoft app governance 管理高风险 service principal。
将 Entra ID 租户监控整合至本地 SOC。
定期审查 Mail.Read、Files.Read.All 等高风险权限。
尽可能使用证书认证替代 client secret。
审查现有应用中新创建的 secret 和证书。
限制 secret 的有效期。

强化 AWS IAM

识别并审计所有长期 access key。
禁用或删除未使用的密钥。
要求人类用户通过 SSO 获取临时 AWS 凭证。
定期检查环境，确保没有残留的长期凭证。

保护 Active Directory 和凭证

修复 ADCS 证书模板，禁用不必要的 CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT。
限制能够申请证书模板的账户。
移除低权限组对证书模板对象的 FullControl、WriteDacl 和写入权限。
对敏感证书申请实施管理员批准。
除非存在明确业务需求，否则将 MAQ 设置为 0。
如果普通用户确实需要创建计算机账户，应设置最低可行 MAQ，并将权限限制到特定用户或组。
扫描网络共享和工作站中的明文凭证并立即清除。
使用加密密码库保存凭证。
定期审计 AD 权限、管理组和高权限账户。
分离普通账户与管理员账户。
管理员应使用专用管理工作站。
考虑部署 Privileged Access Management（PAM）。
对高权限账户使用限时访问，而非长期启用管理员权限。

保护端点配置管理系统

将 SCCM 等端点管理系统视为高价值资产，实施额外访问限制、网络隔离和持续监控。

分隔 OT 网络

在 IT 与 OT 环境之间实施严格的防火墙和访问控制。
限制跳板机访问 OT 网络，并为所有连接启用 MFA。
定期审查 OT 架构和访问路径。
减少不必要的 IT/OT 连接。
监控 OT 网络中的横向移动和未授权访问。
使用变更管理方案追踪并限制 OT 组件修改。

验证安全控制

验证方法

CISA 建议组织根据该公告中的 MITRE ATT&CK 行为实际测试安全控制，而不是仅确认工具已经部署。

建议流程：

选择公告中描述的一项 ATT&CK 技术；
确认哪些安全技术负责检测或阻止该技术；
使用安全测试重现相应行为；
分析检测和预防工具的表现；
对所有相关安全技术重复测试；
根据测试数据调整人员、流程和技术控制。

免责声明：

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

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

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

本文转载自：securitainment Groot Groot《两个 SOC 的故事：两次红队评估带来的启示》