1stOMAR/Detection-Engineering-Environment

# 检测工程环境 — Multi-TTP 威胁检测      ## 为什么会有这个项目 大多数入侵并非始于 zero-day。它们始于一条无人问津的日志。 一次失败的登录演变成了 7,000 次。一个进程悄悄地访问了 `lsass.exe`。一条用 Base64 包装的 PowerShell 命令，让人连看都不想看第二眼。这些都会留下痕迹——问题在于是否有人在监控，以及监控者是否知道“正常”是什么样子。 这个项目是我对这个问题的回答。我从头开始构建了一个检测工程环境，针对它生成了真实的对抗活动，并编写了能捕获每种技术的检测逻辑。这不是我照做的教程——而是我设计、破坏并保护的环境。 ## 架构 ``` ┌─────────────────────────┐ │ Kali Linux (Attacker) │ │ 192.168.2.128 / .129 / │ │ .130 │ └───────────┬─────────────┘ │ Attacks ┌───────────────┴───────────────┐ ▼ ▼ ┌───────────────────────┐ ┌───────────────────────┐ │ Windows 10 (Victim) │ │ Ubuntu Server (Victim)│ │ 192.168.2.141 │ │ 192.168.2.145 │ │ Sysmon + Forwarder │ │ auth.log monitored │ └───────────┬───────────┘ └───────────┬───────────┘ │ Windows Event Logs │ Linux auth.log └───────────────┬───────────────┘ ▼ ┌───────────────────────┐ │ Splunk Enterprise │ │ 192.168.2.145 │ │ SIEM · Rules · Dash │ └───────────────────────┘ ``` | 主机 | 角色 | 遥测数据源 | |------|------|------------------| | Kali Linux | 攻击者（3 个源 IP） | — | | Windows 10 | 端点受害者 | Sysmon + Universal Forwarder → Windows Event Logs | | Ubuntu Server | 端点受害者 + SIEM | 本地监控 → `/var/log/auth.log` | | Splunk Enterprise | 检测平台 | Windows Event Logs + Linux auth.log | **设计决策 —— 三个攻击者 IP：** 单个攻击者持续攻击单个受害者只是一项实验室练习。真正的攻击者会分散活动以逃避速率限制并稀释检测。我为 Kali 节点分配了三个 IP 别名，因此检测必须能经受住*分布式*源地址的考验——就像在生产环境中那样。 ## 四种技术 选择每种技术是为了覆盖 kill chain 的不同阶段、不同的遥测源以及不同的检测挑战。 | # | 技术 | ATT&CK ID | 战术 | 遥测数据 | 检测挑战 | |---|-----------|-----------|--------|-----------|---------------------| | 1 | SMB 暴力破解 | T1110 | 凭证访问 | Windows Event ID 4625 | 大容量阈值调优 | | 2 | SSH 暴力破解 | T1021.004 | 横向移动 | Linux auth.log | 从纯文本中提取字段 | | 3 | LSASS 内存转储 | T1003.001 | 凭证访问 | Sysmon Event ID 10 | 区分恶意访问与系统访问 | | 4 | PowerShell 编码命令 | T1059.001 | 执行 | Sysmon Event ID 1 | Living-off-the-land 检测 | ## 技术 1 — SMB 暴力破解 (T1110) **攻击过程。** 从 Kali 发起，Metasploit `smb_login` 扫描器通过 SMB（端口 445）向 Windows 端点发送了数以千计的凭证对。Windows 如实记录了每一次失败。 **留下的痕迹。** 每次身份验证失败都会写入 **Event ID 4625**。超过 7,500 条这样的记录堆积起来——这是一堵噪音墙，但解读正确的话，就是赤裸裸的罪证。 **检测逻辑：** ``` index=* EventCode=4625 | bucket _time span=1m | stats count by _time, Source_Network_Address, Account_Name | where count > 20 | sort -count ``` **隐藏在字段名中的教训。** 攻击者的 IP 存储在 `Source_Network_Address` 中——*而不是* `IpAddress`，后者在 SMB 登录失败时显示为空。正是这种细节，决定了一个规则是真正有效，还是悄无声息地永不触发。我是像所有人一样学到这一点的：通过看着空白的列。 ## 技术 2 — SSH 暴力破解 (T1021.004) **攻击过程。** Hydra 使用 `rockyou.txt` 字典对 Ubuntu 服务器上的 SSH（端口 22）进行攻击——从所有三个攻击者 IP 发起，以模拟分布式活动。 **留下的痕迹。** Linux 不会为你提供结构化的字段。它给你的是一句话： ``` Failed password for root from 192.168.2.128 port 39266 ssh2 ``` **检测逻辑：** ``` index=linux_logs "Failed password" | rex "from (?P\d+\.\d+\.\d+\.\d+)" | bucket _time span=1m | stats count by _time, src_ip | where count > 10 | sort -count ``` **为什么 `rex` 很重要。** Windows 会提供解析好的字段。Linux 只提供原始文本。`rex` 命令利用正则表达式捕获组从那句话中提取出攻击者的 IP——这是在 Linux 日志中进行 Hunting 最重要的技能，因为那里没有任何为你预先解析好的内容。 结果清晰地讲述了故事：三个源 IP，三个不同的访问量——这正是经过调优的检测必须能够经受住的分布式模式。 | 源 IP | 失败尝试次数 | |-----------|-----------------| | 192.168.2.128 | 120 | | 192.168.2.129 | 48 | | 192.168.2.130 | 47 |  ## 技术 3 — LSASS 内存转储 (T1003.001) 这是最重要的一种技术——也是默认配置几乎漏掉的一种。 **为什么针对 LSASS。** `lsass.exe` 掌握着王国的钥匙：NTLM 哈希、Kerberos 票据，有时甚至是明文凭证。转储其内存，你就可以以任何人的身份进行横向移动。它是受损 Windows 主机上最有价值的单一目标。 **检测缺口。** SwiftOnSecurity Sysmon 配置——尽管非常优秀——却让 `ProcessAccess` (Event ID 10) 缺少专门针对 LSASS 的规则。因此我编写了一个： ``` C:\Windows\System32\lsass.exe 0x1fffff ``` **攻击过程。** `procdump64 -ma lsass.exe`——在 0.6 秒内将 55 MB 的进程内存写入磁盘。Windows Defender 瞬间对其进行了标记，这本身就证明了：这种行为是毫无争议的恶意。（Defender 被故意禁用，以便让事件到达 Sysmon 并验证规则。） **检测逻辑：** ``` index=* EventCode=10 TargetImage="C:\\Windows\\System32\\lsass.exe" | where GrantedAccess="0x1FFFFF" | table _time, SourceImage, GrantedAccess, host ```  **让规则值得信赖的细节。** Defender 本身会不断访问 LSASS——但其 `GrantedAccess` 为 `0x1010`（有限的查询 + 读取）。`procdump` 请求的是 `0x1FFFFF`——即 `PROCESS_ALL_ACCESS`。这个访问掩码就是例行安全扫描与凭证窃取之间的区别。无法区分它们的检测会陷入无尽的误报中。而这个规则可以做到。 ## 技术 4 — PowerShell 编码命令 (T1059.001) **攻击过程。** 一行简单的“Living off the land”——PowerShell，已经被信任，无处不在： ``` powershell -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3... ``` 一条命令中出现了三个危险信号：`-nop`（跳过安全配置文件）、`-w hidden`（隐藏窗口）、`-enc`（Base64 编码的 payload）。解码后，它会连接到攻击者以拉取第二阶段的 payload。 **检测逻辑：** ``` index=* EventCode=1 Image="*powershell*" | where like(CommandLine, "%-enc%") OR like(CommandLine, "%-w hidden%") | table _time, CommandLine, ParentImage, host ```  **判断依据。** 编码的命令并不能证明系统已被入侵——管理员也会合法地使用它们。因此，该规则将其视为*调查的触发器*，而不是最终定论。分析师的工作从告警结束时开始：解码 Base64，阅读意图，做出决定。检测工程不是为了追求确定性——而是为了在对的时间，将正确的信号呈现给对的人。 ## 仪表板 所有四种技术汇聚到一个单一的 SOC 仪表板中，汇总了跨两种端点类型的 **28,000+ 条恶意事件**： - **总事件数** — 单值健康指标（阈值突破时显示为红色区块） - **攻击时间轴** — 随着时间推移绘制出的所有四种 TTP，按技术进行颜色编码 - **LSASS 访问表** — 针对 `lsass.exe` 的每一次 `ProcessAccess`，包含访问掩码 - **PowerShell 表** — 完整的编码命令行，未截断 - **攻击者 IP 分布** — 分布式的 SSH 源地址，按排名排列 时间轴一目了然地讲述了整个故事：一条平缓的基线，然后是遭受攻击的环境所特有的明显激增。 所有四个检测规则，按计划触发：  ## 这证明了什么 这不仅仅是关于运行工具。这关乎闭环： **攻击 → 遥测 → 检测 → 验证。** 对于每一种技术，我都生成了活动，定位了痕迹，编写了规则，并确认了告警的触发。我针对分布式源调优了阈值，从原始的 Linux 日志中提取了字段，通过解读访问掩码区分了恶意的内存访问与例行的系统访问，并做出了深思熟虑的决定：将模糊的信号视为调查的触发器，而不是错误的定论。 其结果是一个可用的、多源、多技术的检测环境——并且清晰地展示出：当日志开始说话时，防御者是如何思考的。 ## 技术栈 `Splunk Enterprise` · `Sysmon` · `Windows Event Logs` · `Linux auth.log` · `Hydra` · `Metasploit` · `ProcDump` · `MITRE ATT&CK` · `VMware Workstation` *由 Omar Tayiawi 构建并编写文档 — SOC 分析师 · 事件响应 · 威胁 Hunting · 检测工程*

标签：AMSI绕过, Cloudflare, DNS 反向解析, MITRE ATT&CK, Sysmon, 威胁检测