美国CISA红队的攻击手法分析

引言

评估背景

该评估持续约三个月，CISA红队在不了解目标组织技术资产的情况下进行评估。评估分为两个阶段：

• 第一阶段：获取并维持对组织企业网络的持续访问权限

• 第二阶段：触发组织的安全响应

红队TTPs细节深度解析

一、初始访问技术细节

1. 钓鱼攻击具体实施

• 目标选择：通过开源情报定位13个可能与外部沟通的员工

• 邮件设计：基于组织的邮件语法规则推断邮箱地址

• payload投递：一名用户执行了两个恶意载荷，但被未知的EDR解决方案拦截

2. Web Shell利用

• 发现过程：

• 使用Shodan和Censys扫描外部暴露服务

• 发现一个存在XML外部实体(XXE)漏洞的过时服务

• 利用公开的PoC发现预先存在的web shell（）

• 利用细节：

• 获得WEBUSER1用户权限

• 识别开放的内部代理服务器用于HTTPS出站通信

• 下载并执行Sliver payload建立C2通道

二、基础设施搭建详解

1. 命令与控制(C2)基础设施

• C2框架选择：

• 主要使用Sliver、Mythic和Cobalt Strike

• 针对不同环境选择不同框架

• 多云服务器部署：

• 每个服务器配置不同域名

• 使用多个云供应商分散风险

• 所有评估数据保留在这些服务器上

• 重定向器配置：

• 利用商用云计算平台创建动态重定向

• 使用HTTPS反向代理在目标网络与团队服务器间重定向C2流量

• 通过VPN和多因素认证保护静态数据

• CDN混淆技术：

• 利用高信誉域名关联的CDN

• 实施域前置技术[T1090.004]隐藏真实C2流量

• 使流量看似指向信誉域名，实际重定向到红队控制的服务器

2. 通信协议实现

Linux环境

• HTTPS隧道：

• 利用内部HTTPS代理[T1090.001]

• 绕过直接互联网访问限制

• 确保C2通信加密

Windows环境

• 初始阶段：

• 工作站通过HTTPS建立C2

• 后续阶段：

• 通过SMB[T1071.002]连接服务器

• 特定SBS访问仍使用HTTPS

命令与控制红队在整个评估过程中使用了第三方拥有和运营的基础设施和服务[T1583]，包括在某些情况下用于命令与控制。团队获得的工具包括[T1588.002]：命令与控制工具Sliver、Mythic、Cobalt Strike和其他商业命令与控制框架。团队维护了由多个云供应商托管的多个命令与控制服务器。每个服务器配置了不同的域名，用于与受感染主机通信。这些服务器保留了所有评估数据。基础设施两个商用云计算平台。团队使用这些平台创建灵活和动态的重定向服务器，将流量发送到团队的服务器[T1090.002]。重定向服务器使防御者难以将评估活动归因于后端团队服务器。重定向器使用HTTPS反向代理在目标组织的网络与团队服务器之间重定向命令与控制流量。团队对所有传输中的数据进行加密[T1573]，并通过具有多因素认证的VPN保护所有静态数据。内容分发网络(CDN)服务。此技术利用与高信誉域名相关联的CDN，使恶意流量看似指向一个信誉域名。然而，它实际上被重定向到红队控制的服务器。这使团队能够混淆其部分命令与控制流量。团队使用域前置[T1090.004]来伪装出站流量，使持久性信标与域名之间的通信多样化。这种技术（也利用CDN）允许信标看似连接到第三方域名，但实际上连接到团队的重定向服务器。

三、后渗透技术细节

1. Linux权限提升链

Copy
初始访问(WEBUSER1)
↓
发现sudo权限配置错误
↓
无密码执行root命令
↓
部署root权限回调
↓
访问NFS共享(no_root_squash)
↓
收集凭据和密钥

2. 持久化技术实现

• Linux系统：

  Copy
  [持久化1] 修改cron任务
  [持久化2] 后门化ifup-post脚本
  [持久化3] 修改.bashrc
  [持久化4] 自定义启动脚本

• Windows系统：

  Copy
  [步骤1] 伪造/请求TGT
  [步骤2] 投放DLL
  [步骤3] 触发计划任务
  [步骤4] DLL劫持启动C2

3. 横向移动技术实现

Linux环境横向移动

1. SSH密钥利用：

• 获取61个私有SSH密钥

• 发现两个具有root访问权限的高权限账户

• 利用密钥进行免密码认证

2. Ansible Tower利用：

• 获得基础设施管理服务器root访问

• 发现root SSH私钥

• 访问六个不同敏感IP范围的SBS

Windows环境横向移动

1. 域控制器入侵链：

   Copy
   发现.pfx文件
   ↓
   使用Rubeus获取TGT和NTLM哈希
   ↓
   利用S4U2Self获取UDHOST管理访问
   ↓
   上传修改版Rubeus监控模式
   ↓
   使用DFSCoerce强制DC认证
   ↓
   捕获票据
   ↓
   执行DCSync

2. SCCM服务器入侵：

• 利用AD数据识别管理员

• 使用已获取凭据访问

• 通过首选横向移动技术获取控制权

四、防御规避技术详解

1. 进程隐藏

• PID操作：

• 重新排序可执行进程的PID

• 使进程在内存中更接近内核

• 降低检测可能性

• 进程伪装：

• 内存中修改进程名称

• 执行时更改进程标识

2. EDR规避

• 文件处理：

• 扩大文件大小超过上传阈值

• 避免使用已知特征

• 使用内存执行避免磁盘检测

• 通信隐藏：

• 使用合法协议

• 实施流量加密

• 利用CDN混淆

防御规避和受害者网络防御活动红队与网络防御人员之间的大多数遭遇发生在组织的Linux环境中。红队利用Linux技术来尝试规避网络防御。作为回应，网络防御人员的威胁搜寻活动识别出了团队在其Linux环境中的部分存在。为了规避防御，红队重新排序其可执行进程的进程标识符(PID)，使其看起来更接近内核，从而最小化团队被检测的可能性。团队还通过在内存中和执行时更改进程名称来修改其进程[T1055]。此外，他们使用在内存中运行的Python脚本[T1059.006][T1620]来避免磁盘检测。红队的一些Linux持久性技术包括修改由cron实用程序运行的预先存在的脚本，以及通过ifup-post脚本和.bashrc创建后门。网络防御人员最终识别出了团队在.bashrc中的后门[T1546.004]。防御人员还成功检测到了他们的Ansible Tower主机和Linux环境中其他系统上的异常活动。防御人员积极分析NetFlow数据，这帮助他们识别出红队的持久性和横向移动。为了降低红队战术的影响，网络防御人员本需要在其事件响应活动中关闭一个关键服务器。关闭将导致数百个系统，包括敏感业务系统的停机。组织的EDR解决方案在很大程度上未能保护组织。EDR仅检测到红队在组织的Windows和Linux环境中的少数载荷。在EDR保护组织免受初始钓鱼载荷影响的情况下，它生成了一个网络防御人员既未读取也未响应的警报。红队通过避免使用工具可能捕获的基本"已知恶意"检测来成功绕过EDR解决方案。团队还使其文件大小超过组织EDR的上传阈值[T1027.001]。此外，组织在遗留环境中完全缺乏任何EDR解决方案。因此，红队在那里的持久性在整个评估过程中都未被发现。由于缺乏适当的身份管理，网络防御人员未能检测到组织Windows环境中的红队活动。具体来说，网络防御人员未能检测和响应红队的S4U2Self、asktgs、dcsync和黄金票据活动。如果组织监控涉及AD和Kerberos的异常活动，他们本可以检测到更多红队活动。最后，组织的DMZ存在重大缺陷，本应检测到通过用于SMB和LDAPS的端口进入组织内部网络的流量。网络防御人员从未正确实施入侵检测系统(IDS)或入侵防御系统(IPS)来监控网络层面的DMZ。这种实施的缺失导致未能检测到通过其DMZ的恶意网络流量。此外，由于存在一个具有互联网访问权限的开放内部代理，使红队能够进行命令与控制，从而可以通过DMZ横向移动。

这些技术细节展示了CISA红队的高度专业性，他们不仅掌握了各种攻击技术，更重要的是能够灵活组合这些技术，形成完整的攻击链条。

附录：缓解措施

基于评估发现，建议组织实施以下缓解措施：

对网络防御人员的建议

1. 网络架构和分段

• 实施严格的网络分段，特别是在DMZ和内部网络之间

• 限制互联网访问，实施严格的出站流量控制

• 建立网络访问控制策略，基于最小权限原则

• 部署和正确配置防火墙、IDS/IPS系统

2. 身份和访问管理

• 实施强大的身份管理系统，覆盖所有环境（Windows和Linux）

• 定期审查和清理特权访问权限

• 要求对所有私钥进行密码保护

• 实施特权访问管理（PAM）解决方案

• 删除或禁用不必要的无约束委派配置

3. 监控和检测

• AD相关活动（DCSync、票据传递等）

• 横向移动

• 数据外流

• 特权账户使用

• 异常认证

• 建立全面的日志收集和分析机制

• 实施网络流量分析

• 监控关键系统的异常活动

• 建立基线并检测偏差

• 特别关注以下活动的检测：

4. 配置和补丁管理

• 默认配置的安全加固

• NFS共享的安全配置

• 服务器安全设置

• 建立严格的配置管理流程

• 实施安全基线配置

• 及时应用安全补丁

• 定期审查和更新系统配置

• 特别注意：

5. 事件响应能力

• 制定和维护事件响应计划

• 定期进行演练

• 建立快速响应机制

• 改进安全工具的配置和使用

• 加强团队协作和沟通

对软件制造商的建议

1. 安全开发实践

• 在整个软件开发生命周期中实施安全设计原则

• 进行定期的安全审查和测试

• 建立安全编码标准和指南

• 实施自动化安全测试

2. 产品安全功能

• 消除默认密码

• 将MFA设为默认选项

• 实施强制性的安全控制

• 提供安全的默认配置

3. 安全更新和补丁

• 建立快速的漏洞响应机制

• 提供自动更新能力

• 及时发布安全公告

• 提供明确的补丁指南

4. 文档和指导

• 提供详细的安全配置指南

• 包含最佳实践建议

• 提供安全部署指南

• 明确说明安全风险和缓解措施

对组织领导层的建议

1. 风险管理

• 改进风险评估流程

• 优化风险决策机制

• 定期审查安全态势

• 适当平衡业务需求和安全要求

2. 资源分配

• 提供充足的安全资源

• 投资安全技术和工具

• 支持团队培训和发展

• 优化安全预算分配

全文完！