From Default to Detection: My First Dive Into SIEM Tuning and Threat Detection
From Default to Detection: My First Dive Into SIEM Tuning and Threat Detection
从默认设置到主动检测：我首次深入 SIEM 调优与威胁检测的实践
Bridging Theory and Practice Security tools like Wazuh and Sysmon are designed to catch common malware out of the box, but they’ll quickly flood log storage with useless alert noise. You don’t get real visibility that way. Security teams have to actively modify policies and write custom rules just to catch threats lurking in the shadows. To make matters worse, indicators like credential dumping, log clearing, and persistence mechanisms hide in plain sight as low-severity events, if they trigger an alert at all. 将理论转化为实践：像 Wazuh 和 Sysmon 这样的安全工具在开箱即用时，虽然能捕获常见的恶意软件，但很快就会用无用的告警噪音淹没日志存储空间。通过这种方式，你无法获得真正的可见性。安全团队必须主动修改策略并编写自定义规则，才能捕获潜伏在阴影中的威胁。更糟糕的是，诸如凭据转储（Credential Dumping）、日志清除和持久化机制等指标，往往以低严重性事件的形式隐藏在众目睽睽之下，甚至根本不会触发任何告警。
For this project, I modified a pre-built lab environment to see what it takes to cut through the log clutter and validate how well a SIEM can catch active adversary techniques and turn them into concrete, actionable alerts. By the time I finished, I’d learned some surprising lessons about where default rules fail and why tuning is everything. 在这个项目中，我修改了一个预构建的实验环境，旨在探索如何从杂乱的日志中提取关键信息，并验证 SIEM 在捕获活跃攻击者技术并将其转化为具体、可操作的告警方面的能力。在项目结束时，我学到了一些令人惊讶的经验，了解了默认规则在何处失效，以及为什么调优至关重要。
Before we look more closely at this lab, it’s probably worth sharing my angle on all this. My main motivation for getting into cybersecurity was to be part of the team building the shield to stop data leaks and the chaos adversaries leave behind. Somewhere along the way, I realized my long-term goal is the analytical forensics side of DFIR. The idea of being the one to figure out the “what, where, and why” of an attack is what pulled me into this field. But to solve those high-stakes puzzles, you have to get down in the weeds where the data lives and make sure that you’re seeing the logs and alerts that matter. 在深入探讨这个实验室之前，我想分享一下我的切入点。我进入网络安全领域的主要动力是成为构建防御盾牌团队的一员，以阻止数据泄露和攻击者留下的混乱。在这一过程中，我意识到我的长期目标是数字取证与事件响应（DFIR）中的分析取证方向。能够查明攻击的“是什么、在哪里、为什么”，这种想法吸引我进入了这个领域。但要解决这些高风险的难题，你必须深入数据所在的底层，确保自己能够看到那些至关重要的日志和告警。
Ultimately, that’s why I decided to focus this project on modifying Active Directory to separate the signal from the noise, ensuring that key events hit the centralized system to catch potential adversarial activity. This project is my first contribution to the security community, marking the leap from textbook theory to hands-on detection. I hope someone finds something useful in my experience! Let’s dive in. 最终，这就是我决定将本项目重点放在修改 Active Directory 上的原因，旨在从噪音中提取信号，确保关键事件能够进入集中式系统，从而捕获潜在的攻击者活动。这是我对安全社区的第一次贡献，标志着我从书本理论向实战检测的跨越。希望我的经验能对大家有所帮助！让我们开始吧。
The Telemetry Pipeline
遥测管道
While the lab environment included several other endpoints, I opted to streamline the scope. To keep the telemetry clean and manageable, I focused my project on a three-node setup: an Active Directory endpoint (ad01) to host target services and execute attacks, a command-line SIEM backend (Wazuh_SIEM) for log processing and custom detection, and an analyst system (Blue-Team Workstation) to visualize the results. 虽然实验环境包含其他几个端点，但我选择精简范围。为了保持遥测数据的整洁和可管理性，我将项目重点放在了一个三节点架构上：一个用于托管目标服务和执行攻击的 Active Directory 端点 (ad01)，一个用于日志处理和自定义检测的命令行 SIEM 后端 (Wazuh_SIEM)，以及一个用于可视化结果的分析系统 (Blue-Team Workstation)。
Juggling these virtual (albeit a little outdated) machines to keep the pipeline alive was a constant headache. Early on, I ran into a really confusing roadblock where my Wazuh dashboard was missing large chunks of time from the logs. The annoying part was that the dashboard didn’t even flag the agents as offline. Everything looked fine on paper, but no new logs came through when I wasn’t staring at it. I eventually discovered that virtual machine idle suspensions were messing with background states on limited resources, causing the connection between the host and Wazuh to silently lock up. 维护这些（虽然有点过时）虚拟机以保持管道运行一直是个令人头疼的问题。起初，我遇到了一个非常令人困惑的障碍：Wazuh 仪表板丢失了大量时间段的日志。最烦人的是，仪表板甚至没有将代理标记为离线。从表面上看一切正常，但当我不在监控时，就没有新日志传进来。最终我发现，虚拟机在资源受限情况下的空闲挂起干扰了后台状态，导致主机与 Wazuh 之间的连接静默锁死。
To fix it, I had to troubleshoot the pipeline by verifying active TCP socket connections for ad01 on port 1514, clearing the local agent cache, and manually restarting WazuhSvc to force a fresh connection. Once I figured out that rhythm, the plumbing stayed stable. 为了解决这个问题，我通过验证 ad01 在 1514 端口上的活动 TCP 套接字连接、清除本地代理缓存并手动重启 WazuhSvc 以强制建立新连接，对管道进行了排查。一旦掌握了这个节奏，系统就保持稳定了。
The 4 Experiments
四项实验
#1 Credential Dumping
#1 凭据转储
Before running experiments, I had to isolate ad01 from the other active agents shipping logs to the manager, which is a standard reality of any multi-endpoint environment. Dashboard filters were essential just to separate the simulated Atomic attacks from background noise. The first goal I had in mind was to isolate credential dumping telemetry and crank up its severity. 在运行实验之前，我必须将 ad01 与其他向管理器发送日志的活动代理隔离开来，这是任何多端点环境中的标准操作。仪表板过滤器对于将模拟的 Atomic 攻击与背景噪音区分开来至关重要。我的第一个目标是隔离凭据转储的遥测数据，并提高其严重性级别。
With the default settings, if an adversary breached this lab environment and used rundll32.exe to dump OS credentials via KRShowKeyMgr, Sysmon would label this as process creation, and Wazuh saw it as a low-level (3) alert. While it’s nice that Sysmon was already forwarding the raw security events, if I want actionable alerts from Wazuh, I need to write custom detection rules. The rule I initially made worked, but with a lot of caveats: 在默认设置下，如果攻击者入侵了该实验环境并使用 rundll32.exe 通过 KRShowKeyMgr 转储操作系统凭据，Sysmon 会将其标记为进程创建，而 Wazuh 会将其视为低级别（3）告警。虽然 Sysmon 已经转发了原始安全事件，但如果我想要来自 Wazuh 的可操作告警，就必须编写自定义检测规则。我最初编写的规则虽然有效，但存在许多局限性：
<!-- Atomic Red Team T1003.005 Credential Dumping Detection -->
<rule id="100007" level="10">
<if_sid>61603</if_sid>
<field name="win.eventdata.commandLine">KRShowKeyMgr</field>
<description>Atomic Red Team: Potential OS Credential Dumping via keymgr.dll (T1003.005)</description>
<mitre>
<id>T1003.005</id>
</mitre>
</rule>While the Atomic tests for this experiment successfully sent logs that Wazuh read as an elevated severity threat, it seemed to only catch the NTDS shadow copy extractions and not the exact extraction utility as cleanly as desired. I was excited that it worked on the first try, but looking back, I rushed into the deployment before finishing my MITRE ATT&CK research. If I were to write this rule again for a production-ready environment, there are two major flaws I would need to fix to change it from a tactical detection to a more strategic one: 虽然该实验的 Atomic 测试成功发送了日志，且 Wazuh 将其识别为高严重性威胁，但它似乎只捕获了 NTDS 卷影复制提取，而未能像预期的那样清晰地捕获特定的提取工具。第一次尝试就成功让我很兴奋，但回过头来看，我在完成 MITRE ATT&CK 研究之前就匆忙进行了部署。如果我要为生产环境重新编写此规则，为了将其从战术检测转变为更具战略意义的检测，我需要修复两个主要缺陷：
- Case-Sensitivity Bypasses: Wazuh’s default string matching is case-sensitive, meaning an attacker could completely bypass this rule just by typing krshowkeymgr or KrShowKeyMgr.
- Wrong MITRE Tag: While T1003 focuses on cached domain credentials, the keymgr.dll utility actually interacts with application password stores, which technically maps to T1555.
- 大小写敏感绕过： Wazuh 的默认字符串匹配是区分大小写的，这意味着攻击者只需输入 krshowkeymgr 或 KrShowKeyMgr 即可完全绕过此规则。
- 错误的 MITRE 标签： 虽然 T1003 侧重于缓存的域凭据，但 keymgr.dll 工具实际上与应用程序密码存储交互，这在技术上应映射到 T1555。
To fix these gaps, here is what the hardened version of that rule looks like: 为了弥补这些差距，以下是该规则的加固版本：
<!-- Consolidated Credential Dumping Detection -->
<rule id="100007" level="10">
<if_sid>61603</if_sid>
<field name="win.eventdata.commandLine" type="pcre2">(?i)KRShowKeyMgr|rundll32.*keymgr\.dll</field>
<description>Suspicious Credential Dumping: Abuse of keymgr.dll / KRShowKeyMgr</description>
<mitre>
<id>T1555</id>
</mitre>
</rule>Additionally, other techniques exist, like T1552 (unsecured credentials), which involves hunting for plaintext passwords that sit in config files, scripts, and registry keys. Unfortunately, the logic in the rule above won’t capture this activity whatsoever and would require a separate rule. 此外，还存在其他技术，例如 T1552（不安全的凭据），涉及搜寻存在于配置文件、脚本和注册表项中的明文密码。遗憾的是，上述规则中的逻辑完全无法捕获此类活动，需要单独的规则。