S1L3NC37/detection-engineering-writeups

# 检测工程实验室 我从零开始构建了一个完全监控的环境，并针对该环境编写检测规则，将其映射到 MITRE ATT&CK，涵盖了 Windows 和 Active Directory、Linux、Kubernetes 以及云（Entra ID 和 AWS）。 每篇检测文档都遵循相同的结构：在实验室中运行该技术，寻找其产生的遥测数据，找出能将其与正常活动区分开来的信号，然后针对该信号引入的误报进行调优。编写查询是最简单的部分。查询背后的推理才是我真正在实践的内容。 **状态：** 实验室的构建已完成并记录在案，检测文档将在我完成后陆续发布。 ## 文档 **[在单台机器上构建检测实验室](building-a-detection-lab-on-one-machine.md)** 介绍环境是如何组装的以及原因。包括网络、域、端点遥测、收集层、云和 Kubernetes pipeline，RAM 限制迫使我做出的决定，以及让我学到最多的失败经验。 **[捕获我的第一个 Reverse Shell](catching-my-first-reverse-shell.md)** 我对一台 Windows 工作站触发了一个 Meterpreter reverse shell 攻击，然后构建了两个 Splunk 检测规则，从不同角度捕获它：一个针对生成它的进程，另一个针对启动它的命令行长度。涵盖了为什么每个信号都有效，每个信号在哪里产生误报，以及为什么结合两个弱信号比单独调优任何一个效果更好。 **[通过文件共享捕获凭证访问](catching-credential-access-through-file-shares.md)** 我在域中建立了文件共享，放置了一个伪造的 passwords.txt，并针对它们运行了 Snaffler 来抓取整个环境的信息。然后，我基于 Windows 事件 5145 构建了 Splunk 检测规则：一个通过名称标记对敏感文件的访问，另一个通过失败量来捕获扫描行为本身。涵盖了检测原语及其字段、整个系统默默依赖的审计策略、失败阈值引入的误报，以及 Malcolm 中的网络层如何在独立于主机日志的情况下佐证相同的活动。 ### 检测目录 | 检测规则 | 平台 | 遥测数据 | ATT&CK | 状态 | | ----------------------------------------------------------------------------------------------- | -------- | ------------------- | ---------------------------------------------------------- | --------- | | [Reverse shell：异常父进程](catching-my-first-reverse-shell.md) | Windows | `sysmon` EID 1 | [T1059.003](https://attack.mitre.org/techniques/T1059/003/) | 已发布 | | [Reverse shell：命令行长度](catching-my-first-reverse-shell.md) | Windows | `sysmon` EID 1 | [T1059.001](https://attack.mitre.org/techniques/T1059/001/) | 已发布 | | [共享上的敏感文件访问](catching-credential-access-through-file-shares.md) | Windows | `winlogs` EID 5145 | [T1552.001](https://attack.mitre.org/techniques/T1552/001/) | 已发布 | | [通过失败量进行共享枚举](catching-credential-access-through-file-shares.md) | Windows | `winlogs` EID 5145 | [T1135](https://attack.mitre.org/techniques/T1135/) | 已发布 | 更多检测规则正在开发中，将在完成后添加，每个规则都包含其 ATT&CK 映射以及我必须调优消除的误报。 ## 实验室架构 **Domain：** `condef.local` · **网络：** VMware NAT `192.168.137.0/24` (网关 `.2`) | 主机 | 地址 | 角色 | | ------- | ----------------- | ------------------------------------------------------------------------ | | DC | `192.168.137.135` | Windows Server 2019: domain controller, DNS, **Splunk Enterprise 9.3.2** | | CERTER | `192.168.137.136` | Member server, Sysmon config-push host | | Win11V | `192.168.137.137` | Domain-joined workstation (Sysmon), primary detonation target | | Win11A | `192.168.137.138` | Domain-joined workstation (Sysmon) | | LinuxA | `192.168.137.139` | Attacker box: Metasploit, later Mythic C2 | | Malcolm | `192.168.137.140` | Network traffic analysis appliance | | LinuxV | `192.168.137.141` | Minikube / Kubernetes host, auditd and Laurel telemetry | 每个 VM 都运行在一个具有 32 GB RAM 的物理主机上。它们的最小分配总和接近 44 GB，因此它们无法同时运行。决定哪些 VM 可以共存结果证明是整个构建过程中最具启发性的限制条件。 LinuxA 是攻击机，也是实验室中唯一被故意不留监控的机器。它上面的任何数据都不会发送到 Splunk。在真实的事件中，你无法从攻击者的机器上获得遥测数据，因此必须利用受害者产生的数据来捕获一切。这就是环境其余部分构建所围绕的限制条件。 ### 遥测 Pipeline 主机和云遥测数据通过专用索引落入 Splunk。网络流量在 Malcolm 中单独分析，检测规则会在这两者之间进行关联。 | 索引 | 来源 | | --------- | --------------------------------------------- | | `winlogs` | Windows Security and System event logs | | `sysmon` | Sysmon (sysmon-modular config) | | `etw` | ETW providers (index created, not yet fed) | | `linux` | auditd via Laurel | | `kube` | Kubernetes audit logs via OTel collector | | `azure` | Entra ID sign-in and audit logs via Event Hub | | `aws` | CloudTrail via S3 | **数据接入路由：** Universal Forwarder 在 `9997` 端口推送，HTTP Event Collector 在 `8088` 端口推送，AWS 通过 S3 拉取，Azure 通过 Event Hub 消费。两个推送，两个拉取，每个都有不同的故障模式。Malcolm 在混杂模式下从虚拟网络中捕获数据。 ### 工具 Splunk Enterprise 9.3.2 · Splunk Universal Forwarder · Splunk Add-on for AWS · Splunk Add-on for Microsoft Cloud Services · Splunk OpenTelemetry Collector · Malcolm · Sysmon + [sysmon-modular](https://github.com/olafhartong/sysmon-modular) · Laurel + auditd ([Neo23x0 ruleset](https://github.com/Neo23x0/auditd)) · Minikube + kubectl + Helm · Azure Event Hubs + Entra ID diagnostic settings · AWS CloudTrail + S3 ## 背景 我在学习 Anton Ovrutsky 编写的 [Constructing Defense](https://www.justhacking.com/course/condef-lite/) (justhacking.com) 时构建了这个实验室。我选择了 Lite 路径，这意味着没有提供现成的 cyber range：我在自己的硬件上亲自搭建了整个环境。 我遵循了课程中关于实验室架构和遥测配置的指导。我所拥有的是从指导说明到实际运行的系统之间的所有成果：在指导未考虑的 RAM 限制下搭建环境，诊断故障原因，并理解为什么存在每个部分，而不仅仅是知道它能运行。检测文档是在我自己的环境中运行的，因此我必须调优消除的误报是针对我的实验室的特定情况，而不是从现成的示例中照搬的。查询遵循了我正在学习的技术；而调优则是需要我对自己的数据进行推理的地方。