高级威胁攻击技战术分析

为什么检测工程需要技战术分析?

• 攻击工具在做什么?
  • 为了检测攻击工具,必须了解其在做什么
  • 通常需要更深入的理解,而不是简单的描述,如"mimikatz dumps passwords"
• 如何确定分析是否足够?
  • 抽象有助于可视化检测,从而使检测的不足之处更加明显
  • 评估不同的遥测生成机制有助于了解解决方案固有的局限性
• 技战术分析有助于在早期就识别未知攻击的可能性
• 帮助预测潜在的规避技术并构建更全面的解决方案

检测和响应的公理

• 计算机上发生的每个动作都可能代表安全威胁
  • 确定一个动作是否实际上是安全威胁并非易事
• 检测和响应必须应对有限的资源
  • 无法将每个事件都作为同样的威胁级别进行对待并审计
• 必须有一个系统来显示更可能代表安全威胁的事件
  • 保真度漏斗是用来描述该过程的模型之一
  • 系统中的每个过滤器都会减少转发到下一个过滤器的事件数量
  • 每个后续阶段都可以增加对事件进行分析的资源
• 根据漏斗,检测是第一个过滤器,因此负责使用最少的资源最大程度减少事件
  • 由于事件与资源分配成反比,配置不当的检测过滤器可能会使小错误变成大错误
  • 因此增加对检测过滤器有效能力的关注非常重要

保真度漏斗模型

保真度漏斗描述了应用不同的分析过程来管理数百万个上下文事件并将有限的调查资源应用于最有可能是恶意事件的过程.

由五个阶段组成:

• 收集
• 检测
• 分类
• 调查
• 修复

每个阶段都接受前一阶段生成的输入执行某种过滤或降噪,并为下一阶段产生输出.理想情况下每个阶段都允许对相关事件进行更深入或更多的手动分析,因为已过滤掉不相关的事件.

收集:

• 角色:数据工程师
• 输入:数据传感器
• 输出:事件

遥测是安全监控的基石.成熟的企业/组织应尽可能多的收集遥测数据,并进行集中处理和存储.如Windows事件日志,代理日志,netflow,EDR等.

检测:

• 角色:检测工程师
• 输入:事件
• 输出:告警

检测工程师定义检测规则来识别与安全相关的事件.检测阶段的目标是将收集阶段的数百万事件减少到数百个告警.通常在称为威胁狩猎或检测工程的过程中创建的,但应在生产环境中进行自动化实施.

分类:

• 角色:SOC分析师
• 输入:告警
• 输出:线索

分类阶段,SOC工程师将告警分为恶意的,良性的和未知的.恶意活动会被识别为事件并进入修复阶段.而未知的活动则被识别为线索进入调查阶段.告警是检测的结果,允许一定程度的误报.但很多组织此处会产生告警疲劳.导致告警疲劳的一个重要原因是告警的性质通常不明确,SOC分析师很难理解产生告警的检测逻辑及目标,告警的上下文等,此处可以使用ADS框架来解决.

调查:

• 角色:SOC分析师(高级)或取证分析工程师
• 输入:线索
• 输出:事件

分类阶段用于消除误报并产生可管理数量的线索.对无法识别为恶意或良性的活动进行额外的调查,例如对文件系统进行分析,内存取证分析,二进制分析等.来帮助识别活动的真正来源.

修复:

• 角色:事件响应工程师
• 输入:事件
• 输出:无

事件响应人员确定事件范围并从网络中清除恶意活动.许多组织在此阶段与第三方进行合作.

什么是检测?

• 由于不确定性,检测不可能完美
• 相反,检测的目标应该是对事件进行排序以确定哪些事件最有可能与安全相关
• 要做到这一点,需要遵循以下步骤:
  • 描述检测规则的目标
  • 找到所有事件的基本条件
  • 识别基本条件的所有实例
  • 添加必要的上下文来评估已经识别的事件
  • 将事件分类为"告警"和"非告警"
• 随着时间推移,应根据反馈调整告警的阈值
• 两个子阶段:
  • 识别 - 找到满足感兴趣攻击的最低标准所需的所有事件
  • 分类 - 确定是否需要发出告警的过程
• 告警阈值是任意的
  • 阈值应与资源数量相关
  • 拥有更多资源则可能会允许更多的告警(更高的灵敏度)
  • 阈值可以是二进制匹配的,也可以是基于分值的
  • 例如:在二进制分析中80被认为是恶意软件,那么得分79的是否完全是非恶意的?我们可以调整检测规则来减少误报意味着阈值是任意的.

可能性思维

• 这种方法背离了传统的概率思维
  • 可能会认为:可以根据过去发生的可能性来预测未来发生的可能性
• 假设概率基于不完整的观察的结果
  • 因此重要的是不要简单的考虑过去的事情,而要考虑未来可能发生的事情
• 这有助于通过对抗性方法挑战现状和测试未实现的风险
• 例如:
  • Sysmon包含三个WMI事件(19-21)
    • 是否可以在不触发这些事件的情况下创建WMI事件?
    • 如果组织当前的检测建立在对Sysmon事件稳健性的信任之上,那么可能性思维将帮助思考研究这个问题.

关于规避技术的技战术分析

• 什么是隐身?
  • 隐身与目标的感知能力有关
  • 新的技术并不是天生就比较隐蔽
• 攻击者在不进行数据分析时做出的技战术选择
  • 传感器(EDR)是否可以捕获到该活动?
  • 如何捕获?
  • 是否有办法不使用该动作来达成目标操作或破环传感器的捕获机制
• 有助于融入正常操作系统活动的操作
• 调整工具避免被常规的检测捕捉到

例子:Cred Dumping

• Windows10中微软添加了一个默认的SACL,以在任何人尝试从Lsass中读取内存时进行捕获
• James研究了如何规避SACL,表明他正在建立相对于已知检测的规避
• 分析SACL以找到它所要查找的内容
• 经过一些可能性思考,使用DuplicateHandle技巧从另一个未触发SACL的进程中获取复制的句柄

规避漏斗

• 感知
  • 传感器无法检测到活动的发生
• 配置
  • 传感器可以捕获,但配置未开启相关事件
• 逻辑
  • 数据存在,但没有将该事件作为告警引发的检测规则
• 分类
  • 发出告警,但标记为误报,实际上并非误报
• 时间性
  • 流程按照预期进行,但响应太晚导致无法阻止攻击者
• 技术
  • 技术能力缺少完成漏斗的必要功能
• 功能性
  • 流程应该有效,但有些地方未按照设计进行

理解抽象:

情景

• 威胁情报团队发现,利用管理工具混入正常网络噪音的威胁团伙数量显着增加.
• 一种流行的特定工具是 Sysinternal 的 PsExec
  • PsExec 由系统管理员用来在远程系统上执行命令
  • 攻击者使用此工具进行横向移动和特权升级
• 这对你意味着什么?
  • 检测工程师
    • 任务是"检测在整个企业中使用PsExec 的任何尝试"
  • 规避工程师
    • 任务是"通过对手模拟帮助蓝队评估检测结果"

任务分析:

特定任务:

• 指定要完成的任务
• 侧重于高层次,并有解释它如何完成的空间
• 如:检测PsExec

隐含任务:

• 为完成指定任务而必须执行但并未明确分配的任务
• 如:
  • 使用非默认设置检测PsExec
  • 检测所有派生自PsExec的工具

检测"PsExec"意味着什么?

• 当有人说他们"检测到PsExec"时,他们是什么意思?
  • 你能检测到PsExec.exe吗?
  • 类似的衍生工具,如Meterpreter的PsExec插件呢?
  • 是否能检测到PsExec用于横向移动的机制?以便于捕获任意替代方法?
  • 是否能够检测到在远程工作站上的payload?
• 对你来说"检测PsExec"意味着什么?
  • 如果你的领导告诉你,你该如何理解?
• 你的成功标准是什么?
  • 这是主观的还是客观的?

能力识别:

• 工具只是一种应用程序,它结合了一定数量的能力来实现某些目标
• 例如:PsExec是一种用于实现下面这些目标的工具:
  • 横向移动
  • 特权升级
  • 持久化
• 如果检测狭窄的集中在该工具上,那么攻击者将很容易迁移到具有相同功能但不同的实现方法上
  • 即技战术的进化
  • PsExec有非常多的替代品
    • SMBExec,Impacket,Invoke-PSExec,SharpExec,SharpMove等等
• 基于此,重要的是以能力为中心的检测来补充以工具为中心的检测
• 第一步是识别工具的能力实现

分析方法:

• 动态分析:
  • 依靠执行代码来观察系统变化
  • 较低的技术门槛
  • 可能有多个执行工作流
  • 结果是相关的
  • 提供快速广泛的理解
• 静态分析
  • 分析代码但不执行它
  • 更高的技术门槛
  • 可用于枚举之前未知的工作流程
  • 结果是因果关系
  • 提供更完整的理解

对于动态分析,可以使用ProcMon进行辅助分析.

• 分析人员应该执行他们想要分析的命令
• PsExec提供了多种远程命令执行的能力

通过ProcessMonitor的动态分析并将其与ATT&CK做关联后可以确认:

• T1570:横向工具传输
• T1021.002:远程服务 - SMB/Windows管理共享
• T1543.003:创建或修改系统进程 - Windows服务
• T1569.002 系统服务 - 服务执行

Payload组件:

• 1.交付(Windows Admin Shares)
  • 交付机制:SMB传输,RPC与远程服务控制器(SCM)进行通信远程创建/启动服务
• 2.引爆(Service Execution)
  • 触发 - 启动服务
  • 执行 - PE模块加载执行(DLL 或 EXE + 参数)
• 3.命令与控制(命名管道)

解构过程:

• 1.技术:
  • 我们对分析什么技术感兴趣?
• 2.工具:
  • 知道哪些工具可以执行此技术?
• 3.函数
  • 哪些API函数支持该技术?
• 4.IPC
  • 这种技术是否利用进程间通信?
• 5.安全对象
  • 该技术是否与安全对象交互?
• 6.网络
  • 该技术是否需要有网络活动?

能力抽象:

• 在当前的检测和响应环境中,非常难以对检测工作的功效进行量化
  • 团队倾向于减少误报来排除告警疲劳
• 工具代表攻击的最表面的技术
  • 有无数种方法可以将技术重新实现为不同的工具
• 如果了解幕后发生的事情,可以提高检测的弹性
  • 防御者和攻击者往往关注的是这是什么工具,通常不会花时间去了解工具是如何做到的
  • 这使他们无法预测或解释技术实施中的变化
• 通过足够深入的挖掘,可以识别攻击技术的"阻塞点"
  • 无论工具如何实施,都必须发生常见的行为
  • 阻塞点可以作为稳健检测能力的起点

抽象映射:

有一个视觉辅助工具可以来演示攻击技术的层次：

• 映射以实施攻击的已知工具列表开始
• 分析工具以去除抽象层并揭示工具之间的共性
• 这些层包括:
  • 函数(.NET类方法,Win32 API,设备驱动等)
  • 进程间通信(COM,RPC,ALPC)
  • 安全对象(文件,进程,服务,注册表,内存节区)
  • 网络协议(SMB,Kerberos,LDAP,RDP)
• 检测工程师或红队可以使用映射的图来了解工具的技战术以及如何通过多种途径到达相同的目的

抽象如何帮助你?

检测工程师:

• 了解攻击技术的深度
• 熟悉操作系统内部结构
• 量化特定检测分析的覆盖范围
• 更彻底的评估差距和盲点
• 确定提高可见性的机会

规避工程师:

• 量化工件(artifacts)或日志
• 了解技战术的选择
  • OSINT帮助了解目标的监控能力从而提供信息帮助进行技战术的选择
  • 是融入环境更好还是破坏遥测收集更好
• 与蓝队进行更积极的对话促进改进

解构:

• 1.技术

  • 攻击技术像是积木块,结合起来允许攻击者实现目标
    • 工具通常结合多种技术来提高操作者的效率
  • 解决这个问题的一种方法是确定一个离散的概念并尽可能详细地了解它
  • 最好选择一种攻击技术并尽可能多地了解它
    • 将为做出有关检测和规避的明智的决策奠定基础
  • PsExec的技术
    • T1570:横向工具传输
    • T1021.002:远程服务 - SMB/Windows管理共享
    • T1543.003:创建或修改系统进程 - Windows服务
    • T1569.002 系统服务 - 服务执行
  • 通常需要研究每一个技术,作为演示只关注Windows服务

• 2.工具

  • 工具是能力的表面封装
  • 一个好的检测是使用尽可能多的已知工具来测试
  • 通常工具为操作者提供一个或多个特性:
    • 一致性:单个命令可能更不容易出错
    • 简单性:需要很多步骤的复杂操作集成到一个步骤里
    • 速度:开箱即用
    • 不透明:多种功能封装到一个工具中可以减少或隐藏日志中的发现
  • 创建服务的工具:
    • sc.exe(系统内置)
    • Powershell的New-Service Cmdlet(系统内置)
    • WMI (Win32_Service)(系统内置)
    • SharpSC
    • PsExec
  • 解构多个相同功能的工具很有价值
  • 工具可以采用不同的路径来达到相同的目的,了解这些不同的路径很有价值
  • 通常最好从激发兴趣的工具(PsExec)开始
  • 分析其他工具找到抽象图中与其他工具会和的位置

• 3.函数

  • 可以使用API Monitor等工具进行函数调用分析
  • PsExec依赖WindowsAPI来实现其功能
  • 它实现的一项特定的技术是创建服务以在远程端点上执行代码
  • 为了创建服务调用了三个特定的API函数
    • OpenSCManagerW
    • CreateServiceW
    • CloseServiceHandle
  • 检测:
    • 为了执行攻击技术,工具通常依赖于API函数
    • API旨在使复杂的编程任务变得简单
      • 攻击者可以非常容易的在新工具中实现攻击技术
  • 进攻性:
    • 了解工具使用的API可以知道该工具的功能
    • 将技术重新应用到新的工具中可以规避基于已知工具的检测
      • 特别是基于工具+命令行的检测
  • 对其他的工具采用同样的分析方法
    

• 4.进程间通信机制

  • 一个进程可能需要与其他进程或操作系统组件进行交互
    • 例如:Lsass.exe负责身份验证,任何需要与其他资源进行身份验证的应用都应该与lsass.exe交互
  • Windows上有许多IPC机制
    • 文件
    • Sockets(TCP/UDP)
    • 命名管道
    • 油槽
    • 共享内存节区
    • RPC
    • COM
  • IPC是很多攻击技术的主要组成部分
    • 命令与控制
    • 横向移动
  • NdrClientCall4是发出RPC请求的API函数
  • 分析该函数的参数可以了解具体调用了哪个RPC接口
  • 第一个参数pStubDescriptor需要一个MIDL_STUB_DESC结构
    • 该结构第一个字段指向RpcInterfaceInformation的指针,包括GUID
      • 367abb81-9844-35f1-ad32-98f038001003
  • 第二个参数pFormat需要Procedure Header Descriptor
    • 分析后发现其proc_num为12
  • 现在可以知道通过API创建服务依赖于RPC
  • 检测:
    • NdrClientCall4用于进行RPC调用
    • 分析该函数的参数确定了RPC接口ID和Procedure Number
    • 问题:攻击者是否有可能跳过CreateServiceW调用?
  • 进攻性:
    • 规避:可以调用RPC方法而不是调用Win32API
    • 研究:是否有其他RPC方法调用来实现我们的目标?

  

• 5.网络

  

  

  

  • CreateServiceW是MS-SCMR协议的客户端
  • 一个RPC接口可以有多个客户端应用程序
  • 这些客户端可以是操作系统内置的也可以是第三方应用
  • 通过创建第三方RPC客户端攻击者可以绕过WindowsAPI抽象层

• 6.安全对象

  • services.exe是MS-SCMR的RPC服务器
  • RCreateServiceW函数不是导出函数,但在内部可用
    • 首先将服务添加到加载到内存中的SERVICES_ACTIVE_DATABASE
    • 将服务添加到注册表中的持久服务数据库中
  • 服务存储在HKLM\SYSTEM\CurrentControlSet\Services<service name>下的注册表中
  • 检测:
    • 通过分析RPC Server代码可以识别创建服务所做的更改
      • 服务详情信息添加到services.exe内存中的服务数据库中
      • 该服务被添加到注册表用于持久化
  • 进攻性:
    • 分析RPC Server知道它如何持久化
      • 我们可以使用它吗?
    • 是否可以在不使用服务API或SCMR RPC方法的情况下创建新的服务?
      • 可以使用reg.exe手动添加适当的键与键值来创建服务,也可以使用类似的工具如RemoteReg,WinRM,WMI等

  

理解遥测:

• 遥测简介:
  • 遥测是在远程点收集测量值或其他数据,并将其自动传输到接收设备以进行监控
    • 这就是分析人员了解其网络中正在发生的事情的方法
  • 传感器是用于执行测量和记录结果的工具
    • EDR传感器
    • 网络流量传感器
  • 分析师对事件的感知本质上受到他们用于遥测收集的传感器的限制
    • 正在收集哪些类型的事件?
    • 如何收集这些事件?
• 遥测如何影响感知?
  • 了解环境活动的能力受到收集的事件类型的限制
    • 包括配置中未开启的过滤条件
  • 如果事件发生时未收集到,则了解事件发生的选项将受到限制
    • 扫描 - 对短期事件的有限使用
    • 取证 - 只有某些类型的活动可以通过这种方式恢复
  • 是否明确考虑在整体网络感知中所包含的活动类型?
    • 如何分类?
    • 是否有具体的细节?
• 你在收集什么?
  • 你知道目前正在收集哪些日志吗?
  • 跟踪日志的清晰度是什么?
    • 通用(我们有日志)
    • 类型(我们有EDR日志)
    • 传感器(我们有Carbon Black日志)
    • 实体(我们有进程日志)
    • 操作(我们有进程创建日志)
    • 机制(我们有通过内核回调机制记录的进程创建日志)
  • 对日志记录了解的越详细,就越能准备的评估你的解决方案
• 遥测源识别:
  • 一旦对行为有足够的了解,下一步就是找到一个传感器(遥测源),它可以识别该行为何时在你的环境中发生
  • 关于选择遥测源的常见问题:
    • 是否存在概念上最全面的抽象层?
    • 是否存在捕获该层事件的日志?
    • 预计有多少噪音?
    • 如果有多个传感器,哪个更好?
• EDR:

  • EDR类产品应包含的功能:

    • 端点数据收集
    • 数据集中存储
    • 后处理流程
    • 交互式数据查询界面
    • 特定模式的告警

  • EDR如何生成遥测数据?

    • EDR生成遥测数据的方法有很多
    • 每种方法都有固有的缺陷和优点
    • 要正确评估检测的覆盖范围,重要的是了解用于检测的遥测数据如何生成
    • 五种主要的方法:
      • 日志记录
      • 系统访问控制列表(SACL)
      • ETW
      • 函数HOOK
      • 内核回调

  • 日志记录:

    • 许多操作系统都具有开箱即用的日志记录功能
    • Windows中使用事件日志
    • 例如:Windows事件日志有两个和服务创建相关的事件
      • 安全4697 - 系统中安装了一项服务
      • 系统7045 - 系统中安装了一项服务
    • Powershell中包含一个Write-EventLog的cmdlet,可以将事件写入事件日志

  • SACL

    • 通过安全描述符将审计设置应用于安全对象
    • 每个审计设置列为ACE
    • 允许管理员记录尝试访问安全对象的操作
    • 令牌通常需要SeSecurityPrivilege才能查看或编辑SACL
    • 在组策略管理器中配置

    

    • 配置的操作会在事件日志中记录
    • SACL适用于针对非临时的安全对象
      • 文件
      • 注册表
      • AD对象等

  • ETW

    • ETW是操作系统内置的强大的遥测资源
      • 需要与安全相关的事件日志都是由ETW生成的
    • 端点传感器可以通过创建订阅providers的跟踪会话来充当ETW的消费者
    • 攻击者和防御者可以枚举跟踪会话来查找ETW providers
      • 对于具有管理员权限的攻击者来说,禁用ETW跟踪会话相对简单
    • ETW可能非常嘈杂,但也会产生大量细粒度的有价值的信息

  • 函数HOOK

    • 拦截API调用并记录调用的时间和方法
    • API提供的上下文非常有价值:
      • 参数
      • 返回值
      • 令牌
    • 传感器可以在任何没有遥测的地方产生遥测
      • 例如不同操作系统都有不同的遥测能力
        • Windows7没有丰富的ETW能力
      • 操作系统提供的遥测可能无法满足需要
    • 一些工具:
      • Detours
      • EasyHook
      • MinHook
      • Frida
      • .NET - Harmony或DotNetHooking
    • 进攻性:
      • 攻击者可以逃避函数HOOK
        • 恢复原始代码
        • 映射未HOOK的DLL
        • 调用更低级别的API或直接syscall等
        • 异常调用也是一种可行的遥测源
        • 例如来自非Nt*函数的syscall调用

  • 内核回调

    • 操作系统提供的通知机制,在某些事情发生时通知驱动程序
      • 进程创建 - PsSetCreateProcessNotifyRoutine(Ex/Ex2)
      • 线程创建 - PsSetCreateThreadNotifyRoutine(Ex)
      • 镜像加载(.exe,.dll,.sys等) - PsSetLoadImageCallbackRoutine
      • 注册表访问/修改 - CmRegisterCallback
      • 进程、线程或桌面对象的访问 - ObRegisterCallback
      • 电源状态更改,时间更改等

标签

• 威胁情报