在第一部分中，我们介绍了在 Windows 系统中对 Sysmon 的对抗技巧，接下来我们将操作系统更改为 Linux，观察 Sysmon 又有何表现。
部署 SysmonForLinux
本文所使用的 Linux 系统发行版本为 openKylin 1.0（开放麒麟），我们将在该国产系统中进行 Sysmon 部署与测试。
下载 SysinternalsEBPF 和 SysmonForLinux 的 dpkg 软件包，分别进行部署。
部署完毕后，输入 sysmon 命令打印帮助，命令行参数与 Windows 版本没有太大区别。
使用 sysmon -i 命令安装 Sysmon 驱动与服务。
安装完成后，需要准备 SysmonForLinux 配置文件，该配置将监控并记录 Sysmon 在 Linux 系统上支持的所有行为事件，配置内容如下：
<Sysmon schemaversion="4.70">
<EventFiltering>
<!-- Event ID 1 == ProcessCreate. Log all newly created processes -->
<RuleGroup name="" groupRelation="or">
<ProcessCreate onmatch="exclude"/>
</RuleGroup>
<!-- Event ID 3 == NetworkConnect Detected. Log all network connections -->
<RuleGroup name="" groupRelation="or">
<NetworkConnect onmatch="exclude"/>
</RuleGroup>
<!-- Event ID 5 == ProcessTerminate. Log all processes terminated -->
<RuleGroup name="" groupRelation="or">
<ProcessTerminate onmatch="exclude"/>
</RuleGroup>
<!-- Event ID 9 == RawAccessRead. Log all raw access read -->
<RuleGroup name="" groupRelation="or">
<RawAccessRead onmatch="exclude"/>
</RuleGroup>
<!-- Event ID 10 == ProcessAccess. Log all open process operations -->
<RuleGroup name="" groupRelation="or">
<ProcessAccess onmatch="exclude"/>
</RuleGroup>
<!-- Event ID 11 == FileCreate. Log every file creation -->
<RuleGroup name="" groupRelation="or">
<FileCreate onmatch="exclude"/>
</RuleGroup>
<!--Event ID 23 == FileDelete. Log all files being deleted -->
<RuleGroup name="" groupRelation="or">
<FileDelete onmatch="exclude"/>
</RuleGroup>
</EventFiltering>
</Sysmon>使用 sysmon -c 命令导入配置文件。
现在，SysmonForLinux 开始正常工作，它稳定的记录着一切来自红队的操作痕迹......
配置存储位置
Windows 中的 Sysmon 将导入的配置内容以二进制形式保存在注册表中，但 Linux 系统并没有注册表，它的配置存储位置在哪里？
通过浏览 SysmonForLinux 服务程序源代码，从 这里 开始，Sysmon 将响应 -c 参数输出正在应用的配置。
我们继续审计 DumpConfiguration 函数，发现配置文件位置由 SYSMON_RULES_FILE 宏进行定义。
- 默认安装路径：/opt/sysmon
- 配置路径：/opt/sysmon/config.xml
- 规则路径：/opt/sysmon/rules.bin
在查看 config.xml 的时候，我们惊讶的发现，它的内容居然与我们指定的配置文件一致，而非默认的空配置，再结合前面截图中的正在运行的 sysmon 进程命令行参数......思考。
难道说，SysmonForLinux 不能离开明文配置独立工作？我们尝试重命名 config.xml，重启，观察 Sysmon 的运行状态。
重启后，Sysmon 服务程序已停止工作......
syslog 中也没有继续出现 Sysmon 的日志记录，内核中收集行为日志的机制完全失效。
我们只需要有权限可以访问到 SysmonForLinux 的配置文件，即可了解当前系统中的行为监控情况，不再需要二进制解析过程。
脆弱的 eBPF
SysmonForLinux 没有独立的内核模式程序（驱动程序），它通过 Linux 内核提供的 eBPF 框架实现用户层系统调用跟踪，类似的开源项目还有 tracee 和 Hades。
实际上，从 此处 审计可发现，在执行 sysmon -i 命令时，SysmonForLinux 只是将所需的配置文件与编译后的 eBPF 对象文件释放，而后通过前面提到的 SysinternalsEBPF 将 eBPF 程序注入进内核 eBPF 框架中，进而实现系统行为监控。
在注入前，SysmonForLinux 会读取 config.xml，将其中的规则保存为二进制的 rules.bin 文件，注入后，二进制会通过 linkTPprogs 修改 eBPF 跟踪点，这使得 eBPF 框架可以依照配置文件对特定系统调用进行跟踪。
但是，这些注入的 eBPF 程序并不能独立运行，它们类似于安插在系统调用中的回调函数，当指定的系统调用发生时，eBPF 会向处于用户态的将 eBPF 代码注入进内核的程序传达这些系统调用的详细信息，而且，这些 eBPF 程序依赖用户态进程，一旦用户态进程未能正常工作，则整个监控记录机制完全无效。
而且，被植入的 eBPF 程序由于 eBPF 框架的安全检查和功能需要，很难被混淆后再进行注入，即使是没有开源的编译后 eBPF 跟踪程序，也可通过 llvm-objdump 进行反编译。参考 此处。
总结
Sysmon 作为免费且公开的系统工具，实现了很多细致且开箱即用的系统行为记录功能，是蓝队手中的强大武器，可能出于对工具滥用的担忧，开发者并未设计它的自我保护和数据保护功能，但这并不妨碍它日常的行为记录功能。
在它灵活的监控规则下，红队不太可能在操作时隐藏自身，唯有充分了解 Sysmon 的弱点，在 SIEM 和 SOC 广泛流行的现在，才可以与使用 Sysmon 蓝队继续对抗下去。