Atomic Red Team中Sysmon检测驱动卸载问题的技术分析

背景介绍

Atomic Red Team是一个用于模拟攻击技术的开源框架，其中的T1562.001测试用例专门针对防御规避技术中的"禁用或篡改工具"场景。测试编号11的用例旨在验证系统能否检测Sysmon过滤驱动被卸载的情况。

问题现象

在Windows Server 2022标准版（作为AD域控制器）环境中，当执行该测试的预检条件检查时，系统无法识别已安装并运行的Sysmon服务。具体表现为：

1. 通过Invoke-AtomicTest命令执行预检检查时返回失败
2. 使用sc.exe query命令查询服务状态时也无法找到Sysmon服务

根本原因

经过深入分析，发现问题根源在于服务命名差异：

• Atomic测试预期查找的服务名称为"sysmon"
• 实际环境中通过Chocolatey安装的服务名称为"sysmon64"

这种命名差异导致预检条件检查失败，因为检测逻辑仅查找"sysmon"服务名称，而没有考虑"sysmon64"这一变体。

技术验证

通过以下PowerShell命令可以验证服务确实存在但名称不同：

Get-Service -Name Sysmon64

Status   Name               DisplayName
------   ----               -----------
Running  Sysmon64           Sysmon64

同样，使用sc命令也能查询到该服务：

sc.exe query sysmon64 | findstr sysmon64

SERVICE_NAME: sysmon64

影响分析

这个问题会导致以下影响：

1. 测试用例无法正确执行，即使Sysmon实际已安装
2. 可能误导安全人员认为系统未安装Sysmon
3. 影响红队评估的完整性和准确性

解决方案建议

针对此问题，建议从以下几个方面进行改进：

1. 测试用例增强：修改预检条件检查逻辑，使其能够识别"sysmon"和"sysmon64"两种服务名称
2. 文档说明：在测试文档中明确说明支持的服务名称变体
3. 兼容性考虑：考虑未来可能出现的其他服务名称变体（如sysmon32等）

最佳实践

对于使用Atomic Red Team的安全团队，建议：

1. 在执行测试前手动验证Sysmon服务名称
2. 对于通过不同方式安装的Sysmon，注意其服务名称可能不同
3. 在自动化测试流程中加入服务名称检查逻辑

总结

这个问题揭示了安全工具在实际环境中可能遇到的兼容性问题。Sysmon作为Windows系统重要的安全监控工具，其不同安装方式可能导致服务名称差异。Atomic Red Team作为红队测试框架，需要不断适应各种环境差异，确保测试的准确性和可靠性。对于安全团队而言，理解这些细节差异有助于更准确地评估系统安全状态。