From Default to Detection: My First Dive Into SIEM Tuning and Threat Detection

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. 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. 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. 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. 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. 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. 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. The 4 Experiments #1 Credential Dumping 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. 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: 61603 KRShowKeyMgr Atomic Red Team: Potential OS Credential Dumping via keymgr.dll (T1003.005) T1003.005 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: - Case-Sensitivity Bypasses: Wazuh’s default string matching is case-sensitive, meaning an attacker could completely bypass this rule just by typing krshowkeymgr orKrShowKeyMgr . - 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. To fix these gaps, here is what the hardened version of that rule looks like: 61603 (?i)KRShowKeyMgr|rundll32.*keymgr.dll Suspicious Credential Dumping: Abuse of keymgr.dll / KRShowKeyMgr T1555 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. While both T1003/T1555 and T1552 share the same Sysmon process creation rule (61603) as a common starting point, T1552 involves entirely different behaviors, and therefore the rule written for this would have to be entirely separate, rather than a parent-child chain. #2 Anti-Forensic Activity Once I had credential dumping sorted out, my next target was anti-forensic activity. What happens when an adversary tries to erase their tracks by deleting generated logs? With default settings, Wazuh only flagged the action as a low-priority (level 5) event. In order to get these wipes to trigger SOC escalation, I needed to engineer custom rules to boost that severity. During the initial Atomic test run, I noticed a major gap in the paper trail. The Domain Controller wasn't natively looking out for Windows Event ID 1102 (Security Audit Log Cleared). Since the OS failed to generate the local event, Wazuh was none the wiser about anything happening, creating a complete blind spot to the tampering. To resolve this, I had to update the Advanced Audit Policy on ad01 via an auditpol command to enforce logging of security state modifications. auditpol /set /subcategory:"Security State Change" /success:enable Once the OS knew that action was something to create a log for, I needed to deploy a custom rule to fix the earlier mentioned issue of Wazuh defaulting to level 5 on it. 63104 CRITICAL: Windows Application or System log was cleared (T1070) T1070.001 63103 CRITICAL: Windows Security Audit Log was cleared (T1070) T1070.001 By nesting these rules under the parent SIDs, they target the structural OS events, rather than just looking at command-line inputs. That way, no matter what tool an adversary might use to wipe the logs, the action itself will trigger a critical alert. Additionally, one should consider other anti-forensic techniques, such as timestomping and the deletion of malicious files post-exploit. While process creation logging (Sysmon Event ID 1) successfully recorded the execution of utilities like wevtutil.exe , relying on process execution leaves gaps if an adversary can use native APIs. Tracking timeline reconstructions effectively requires an expansion on the ruleset tree to monitor for Sysmon Event IDs 11 and 23 (file creation and deletion) to capture when staging folders are manipulated or purged. #3 Persistence Mechanisms The next phase of my lab modifications targeted endpoint visibility into persistence mechanisms. If malware was designed to survive a system reboot, like through Registry Run key additions, Startup folder shortcut drops, Explorer shell context menu hijacking, and rogue Windows Services, I wanted there to be an actionable alert for it. Luckily, my earlier configurations were already tuned so that Wazuh's native engine did most of the heavy lifting here, successfully parsing structural changes without requiring me to come up with brand-new rules after running the Atomic modules for T1547. The registry modifications and startup directory shortcuts lit up Sysmon Event IDs 1, 11, and 13, and RegistryEvent (ID 13) proved invaluable for capturing modifications to TargetObject paths. While most baseline monitoring focuses solely on standard Run keys, tracking subkeys under _Classes...\shell successfully flagged living-off-the-land persistence attempts that traditional registry audits miss. Additionally, creating a test service generated a correlation-ready audit trail by pairing Sysmon Event ID 13 with a native Windows System Event ID 7045 (New Service Installed ). Finally, executing administrative configuration utilities like secedit to modify security templates and turn off persistence configurations still sent the necessary alerts needed to know something suspicious was brewing on ad01 . However, this round of testing brought a huge real-world realization to me: the biggest challenge with autostart persistence isn't the lack of data, but separating it from routine administrative noise. Legitimate software constantly updates registry keys and installs services during normal operation. This experiment taught me that a hardened security architecture can't simply look for service creation. High-fidelity detection means you have to dig into process lineage, specifically separating normal parent-child process relationships, and flagging when services attempt to execute out of unusual locations like AppData or temp directories. #4 Stealthy Triggers For my