Abbayipyip/soc-analyst-homelab

# SOC Analyst 家庭实验室：攻击模拟与检测工程 ## 目标 我搭建这个实验室是为了获得网络攻击和检测的实际操作经验。不仅仅是阅读相关资料或通过认证考试，而是真正去实践。我想要攻击一个系统，从防御者的角度观察它是什么样的，并编写规则来捕获它。 ## 使用的工具 - LimaCharlie (EDR) - Sliver C2 (命令与控制框架) - Sysmon (Windows 事件日志记录) - YARA (恶意软件签名扫描) - Windows VM (目标机) - Ubuntu Server (攻击机) ## 实验环境搭建 使用了来自 Eric Capuano 的 SYWTBSA 2.0 课程中的两个云端托管 VM。Windows 作为受害者，运行 Sliver 的 Linux 作为攻击者。我在 Windows VM 上安装了 LimaCharlie sensor，将其设置为拉取 Sysmon 日志，并开启了 Sigma ruleset 扩展以实现基线检测。 ## C2 Implant 部署 我在 Linux VM 上生成了一个 Sliver C2 implant，并通过 web 服务器将其提供给 Windows 机器。第一次尝试时搞砸了。我设置了 HTTPS listener 而不是 HTTP listener，直到我在 Windows 上下载了 implant、运行了它却什么也没发生时才意识到这一点。没有回调。我不得不返回，终止该任务，启动一个 HTTP listener，生成一个新的 payload，然后再试一次。 第二个 implant (SMALL_ADVERTISING.exe) 连接正常。拥有对 Windows 机器的完全访问权限。命令、进程、网络连接，一切尽在掌握。 第一个损坏的 implant (MID_SIDECAR.exe) 只是静静地待在 Downloads 文件夹中，什么也没做。这在后来变得至关重要。 ## 凭据转储 进入系统后，我使用 Sliver 的 `getsystem` 命令将权限提升至 SYSTEM，然后使用 rundll32 和 comsvcs.dll 从内存中转储了 lsass.exe。这是一种真实的凭据窃取技术。我转到 LimaCharlie，并在时间线中找到了 SENSITIVE_PROCESS_ACCESS 事件，它准确地显示了发生的一切。 ## 编写检测规则 构建了一个 D&R 规则，通过监视访问 lsass.exe 的非正常 Windows 进程来检测凭据转储。测试了一下，奏效了，然后继续下一步。 接着我编写了一条针对勒索软件行为的规则。专门用于捕获 `vssadmin delete shadows /all`，这是勒索软件在加密文件之前用来清除备份副本的命令。 规则的第一版使用 `op: is` 进行命令行匹配。这意味着它需要完全一致的字符串才能触发。它在技术上可行，但后来我仔细想了想，意识到这是个问题。如果攻击者加入了一个额外的空格，改变了大小写，或者重新排列了参数，就会导致漏报。因此我将其更改为 `op: contains`，并将其拆分为对 "delete"、"shadows" 和 "/all" 的单独检查。这样更具鲁棒性。 在更新规则时，我还遇到了一个 YAML 缩进错误，花了我好一会儿才弄明白。YARA 是不会原谅你的。 ## 勒索软件模拟 下载了一个勒索软件模拟器（NextronSystems QuickBuck），以在更真实的场景中测试我的规则。它执行了整个链路：虚假的宏执行、影子副本删除、文件创建和加密。我更新后的 D&R 规则捕获到了影子副本的删除并将其终止。Sigma 规则和我的自定义规则在相同的事件上都被触发了。 ## YARA 将 NCSC 编写的 YARA 规则添加到 LimaCharlie 中以检测 Sliver implant。这些规则会寻找在编译后存在于 Sliver 二进制文件中的字符串和字节模式。比如路径 `/sliver/`，像 `ScreenshotReq` 和 `KillSessionReq` 这样的函数名，以及来自特定 Sliver 函数的原始机器码。 接下来的事情变得很有趣。我在 Downloads 文件夹上运行了 YARA 扫描，它捕获到了 MID_SIDECAR.exe（我之前失误产生的损坏的 implant），却完全错过了 SMALL_ADVERTISING.exe（那个实际上已经连接到 C2 并正在实施破坏的 implant）。同样的框架，同样的大小，但构建配置不同。HTTPS 构建的混淆方式可能与 HTTP 构建不同，从而去除了 YARA 规则正在寻找的字符串。 因此被标记的文件反而是无害的那个。真正的威胁对该扫描来说是不可见的。如果我是一名真正的分析师，并且只看 YARA 捕获到的内容，我就会错过真正的 implant。这一点让我印象深刻。 ## 自动化扫描 设置了 D&R 规则，使用 YARA 自动扫描从 Downloads 目录启动的任何进程。终止了 Sliver implant，重新启动它，并观察触发的检测链：首先是“Execution from Downloads directory”，然后是“YARA Detection in Memory”，确认运行中的进程包含 Sliver。这部分成功了。 我试图对落入 Downloads 中的新文件（NEW_DOCUMENT 事件）做同样的事情，但事件始终没有生成。我对此进行了深入研究。检查了 Sysmon 配置，确认 FileCreate 已设置为监视 Downloads，检查了 LimaCharlie 中的 FIM 规则，尝试了不同的文件操作。毫无结果。最终发现这是云 VM 设置中的 sensor 级别摄取问题，而不是规则问题。我将其记录下来并继续下一步。 ## 我的心得体会 精确匹配规则很脆弱。我亲身体会到了这一点，我的 `op: is` 规则在受控测试中有效，但对任何稍微改变语法的攻击者来说都会失效。使用带有单独关键字检查的 `op: contains` 才是明智之举。 YARA 的事情真的让我深思。两个构建略有不同的 Sliver implant，一个被捕获，另一个却没有。你不能依赖单一的检测方法。你需要分层防御。使用 YARA 进行签名检测，使用 D&R 规则进行行为检测，使用 Sigma 检测已知模式，并且需要一名真正去阅读时间线的分析师，而不是仅仅关掉弹出的任何警报。 那些出问题的东西比那些起作用的东西教会了我更多。调试 YAML 错误，排查丢失的事件，弄清楚为什么一个 implant 被检测到而另一个没有。这比一步一步地遵循教程更接近真实的 SOC 工作。 我也把它当作游戏来思考。Red team 应该一直试图破坏 Blue team 构建的东西。这种推拉博弈让双方都变得更好。每一次绕过都是构建更好检测的机会。每一次检测都是 Red team 需要解决的难题。这个循环正是这个领域让我感兴趣的地方。 ## 下一步计划 - 解决 NEW_DOCUMENT 问题。可能需要调优 Sysmon Event ID 11 或者在 LimaCharlie 中使用不同的事件名称 - 为触发的其他检测编写规则（Suspicious Microsoft Office Child Process, Sysmon File Executable Creation） - 尝试从头开始编写 YARA 规则，而不是使用预先构建好的规则 - 添加除报告之外的响应措施。自动隔离主机，终止进程树，发送警报 ## 致谢 基于 Eric Capuano 的“你想成为一名 SOC Analyst 吗？”2.0 课程。他是一名 SANS 讲师，并运营着 Recon InfoSec。

标签：AMSI绕过, EDR, SOC分析, 威胁检测, 攻击模拟, 网络安全, 脆弱性评估, 隐私保护, 驱动签名利用