Zeltoc/wazuh-lsass-credential-access-detection

# Wazuh SIEM 实验室 - lsass 凭据访问检测 (T1003.001) **工具：** Wazuh 4.x，Sysmon (SwiftOnSecurity 配置，已修改)，PowerShell **平台：** Proxmox 家庭实验室 - Ubuntu 22.04 (Wazuh 管理端)，Windows 11 (受监控端点) **MITRE ATT&CK:** T1003.001 ## 目标 检测使用 Sysmon 事件 ID 10 (ProcessAccess) 针对lsass.exe的凭据访问尝试。记录 Wazuh 内置规则集中的检测盲区，识别来自合法安全工具的误报，并编写一条自定义规则来填补盲区同时过滤噪声。 ## 环境 | 虚拟机 | 操作系统 | 角色 | IP | |---|---|---|---| | wazuh-manager | Ubuntu 22.04 | Wazuh Server + Dashboard | 192.168.1.x | | DESKTOP-72VLLG0 | Windows 11 | 受监控端点 (Wazuh 代理 + Sysmon) | 192.168.1.162 | Sysmon 使用修改后的 SwiftOnSecurity 配置部署。默认配置将 `powershell.exe` 排除在 ProcessAccess 日志记录之外——该排除项已被移除以启用对模拟攻击的检测。有关为何这很重要的上下文，请参阅环境挑战部分。 ## 背景 -- 为什么是 lsass lsass.exe (本地安全机构子系统服务) 处理 Windows 身份验证并在内存中存储凭据材料。像 Mimikatz 这样的工具专门通过打开高特权句柄并读取进程内存来提取密码哈希、Kerberos 票据以及某些配置下的明文凭据，从而针对性地攻击它。 Mimikatz 请求的特定访问掩码是 `0x1FFFFF` (PROCESS_ALL_ACCESS)。该值是主要的检测信号——它比合法系统进程在交互 lsass 时所需的权限要宽松得多。Sysmon 在每次 lsass 句柄请求时记录源进程和访问掩码，这使得区分攻击者行为与正常系统活动成为可能。 ## 环境挑战 本实验室遇到了两个值得记录的 Windows 11 安全控制措施，因为它们在真实环境中也息息相关： **LSA 保护 (RunAsPPL)** Windows 11 默认启用 LSA 保护，这会将 lsass 标记为受保护进程轻量级 (PPL)。这甚至会阻止管理员级别的进程打开指向 lsass 的高特权句柄。ProcDump、comsvcs.dll MiniDump 和类似工具在没有内核级驱动程序的情况下，都会对受 PPL 保护的 lsass 失败。 本实验室通过注册表禁用了它： ``` HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 0 ``` 需要重新启动才能生效。在真实环境中，启用 LSA 保护是一项有意义的防御控制措施——如果主机上缺少此功能，则值得将其标记为一项配置发现。 **SwiftOnSecurity Sysmon 配置过滤** SwiftOnSecurity 配置在默认设计上将 powershell.exe 排除在 ProcessAccess 日志记录之外。这是一个刻意的降噪决定——PowerShell 在正常运行期间会合法地访问许多进程，记录所有这些会产生巨大的日志量。 第 304 行的相关排除项： ``` powershell.exe ``` 从 ProcessAccess 排除块中移除这一行，可让 Sysmon 记录攻击模拟。在生产环境中，可见性与日志量之间的权衡是一个真正的调整决策——而不是配置错误。 ## 攻击模拟 该模拟使用一个 PowerShell 脚本，直接调用带有 `PROCESS_ALL_ACCESS (0x1FFFFF)` 的 Windows `OpenProcess` API。这会生成与 Mimikatz 在进行凭据访问时产生的完全相同的 Sysmon 事件 ID 10 遥测数据，且不需要任何攻击性工具。 ``` $sig = @' [DllImport("kernel32.dll")] public static extern IntPtr OpenProcess(uint dwDesiredAccess, bool bInheritHandle, uint dwProcessId); '@ $kernel32 = Add-Type -MemberDefinition $sig -Name 'Kernel32' -Namespace 'Win32' -PassThru $lsassId = (Get-Process lsass).Id $handle = $kernel32::OpenProcess(0x1FFFFF, $false, $lsassId) Write-Host "Handle opened: $handle" ``` 非零的句柄值确认访问已被授权。生成的 Sysmon 事件中的 `CallTrace` 显示内存区域为 `UNKNOWN`——这在直接调用 API 且磁盘上没有关联模块时是预期的结果，它本身在更高级的威胁狩猎场景中也是一个检测信号。 ## 检测结果 -- 内置规则 在 Sysmon 中启用 lsass ProcessAccess 规则会立即生成警报，但并非来自预期的来源： | 规则 ID | 级别 | 源进程 | GrantedAccess | 描述 | |---|---|---|---|---| | 92900 | 12 | MsMpEng.exe (Defender) | 0x101000 | 以读取权限访问 Lsass | | 92900 | 12 | MsMpEng.exe (Defender) | 0x1010 | 以读取权限访问 Lsass | Windows Defender 作为其自身威胁扫描的一部分，会定期访问 lsass 内存——这是正常行为。规则 92900 在模拟攻击脚本运行之前就在 Defender 上触发了，这意味着在真实环境中，此规则会因合法的杀毒活动而持续生成警报。 `GrantedAccess` 值说明了问题： - Defender 使用 `0x101000` 和 `0x1010`——用于扫描的有限读取权限 - Mimikatz 和模拟攻击使用 `0x1FFFFF`——完全进程访问权限 这种区别正是区分误报与真阳性之处。 ## GrantedAccess 参考 | 访问掩码 | 名称 | 含义 | |---|---|---| | `0x1FFFFF` | PROCESS_ALL_ACCESS | 完全访问权限——由 Mimikatz、凭据转储工具使用 | | `0x101000` | 有限读取 | 常见于杀毒扫描工具 | | `0x1010` | 有限查询/读取 | 最低访问权限，通常是良性的 | | `0x1410` | 读取 + 查询信息 | 常见于诊断工具 | ## 自定义检测规则 Wazuh 内置的 92900 规则没有机制来区分攻击者访问与 Defender 访问。下面的自定义规则专门针对 `0x1FFFFF`，并排除了已知合法的进程： ``` 61612 (?i)lsass\.exe 0x1FFFFF (?i)MsMpEng\.exe CRITICAL: Possible credential dump - PROCESS_ALL_ACCESS handle opened on lsass.exe by $(win.eventdata.sourceImage) [T1003.001] T1003.001 credential_access,lsass_access, ``` **为什么是 15 级：** 这是 Wazuh 的最高严重级别。非 Defender 进程打开指向 lsass 的完全访问句柄，是 Windows 遥测数据中最明确的凭据访问信号之一——在已经处于排除列表中的安全工具之外，lsass 上的 `0x1FFFFF` 没有任何合法的用例。 **反向过滤器：** `negate="yes"` 属性反转了匹配项——该规则会对任何不是 MsMpEng.exe 的进程触发。在生产部署中，此排除列表将扩大以包含其他已知合法的工具（EDR 代理、备份软件等）。仅从 Defender 开始适合此环境。 ## 检测结果 -- 自定义规则 | 规则 ID | 级别 | 源进程 | GrantedAccess | 结果 | |---|---|---|---|---| | 92900 | 12 | MsMpEng.exe | 0x101000 | 误报 -- Defender 扫描 | | 100005 | 15 | powershell.exe | 0x1FFFFF | 真阳性 -- 模拟凭据转储 | 两条规则在同一个事件窗口上同时触发。Wazuh 仪表板中的对比是关键结论——92900 规则重复地由一个已知合法的源触发，而 100005 规则只由带有完全访问掩码的 powershell.exe 触发了一次。 ## 经验教训 **访问掩码是信号，而不是目标进程。** 每个安全工具都会访问 lsass。区分攻击者行为的是请求的权限。来自非 EDR 进程对 lsass 的 `0x1FFFFF` 访问是高可信度的。 **误报需要源进程上下文。** 规则 92900 并没有错——Defender 确实在访问 lsass，并且理论上这可能是可疑的。但如果范围中没有源进程，该规则就会持续针对预期行为触发。自定义规则添加了该上下文并使检测具备可操作性。 **默认的 Sysmon 配置旨在降低噪声，而非实现最大可见性。** SwiftOnSecurity 配置出于正当理由将 powershell.exe 排除在 ProcessAccess 日志记录之外。移除该排除项增加了可见性，但也增加了日志量。这是一个真正的检测工程权衡，而不是配置错误——理解它比仅仅遵循一个假设日志已经存在的教程更有价值。 **LSA 保护是一项有意义的防御控制措施。** 在 Windows 11 上模拟此攻击的难度正是关键所在。在一个真实的 SOC 中，未启用 LSA 保护的主机值得标记——这是一个使凭据转储对攻击者来说变得显著容易的配置缺口。 **`UNKNOWN` CallTrace 条目值得注意。** 模拟攻击的调用跟踪为发起句柄请求的内存区域显示 `UNKNOWN(00007FFB9A78DC28)`。发生这种情况是因为直接调用了 API，而没有磁盘上的模块支持该内存地址。在威胁狩猎中，发起敏感 API 调用的无后备内存区域比仅凭进程名称是可信度更高的指标。 ## 仓库结构 ``` wazuh-lsass-detection-lab/ ├── README.md ├── rules/ │ └── local_rules.xml ├── alerts/ │ └── *.json └── screenshots/ └── 01-detection-results.png ``` ## 参考 - [Wazuh 规则语法](https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html) - [SwiftOnSecurity Sysmon 配置](https://github.com/SwiftOnSecurity/sysmon-config) - [MITRE ATT&CK T1003.001 -- 操作系统凭据转储：LSASS 内存](https://attack.mitre.org/techniques/T1003/001/) - [Microsoft -- 配置额外的 LSA 保护](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection) - [Windows 进程访问权限](https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights)

标签：AI合规, AMSI绕过, Conpot, HomeLab, IPv6, LSASS, Mimikatz, PowerShell, Proxmox, Sysmon, SysmonEventID10, Wazuh, Windows安全, 威胁检测, 安全实验室, 攻击模拟, 数字取证, 网络安全, 自动化脚本, 自定义规则, 误报处理, 进程访问监控, 隐私保护, 驱动签名利用