Enterprise Security Hardening
Windows Advanced Audit Policy baseline assessment against Microsoft Security Baseline. 27 subcategories audited. 11 ATT&CK techniques unblocked. Zero regressions.
Problem / Hypothesis
A structured Splunk threat hunt across 283,976 Windows Security events had identified critical audit gaps — command-line logging disabled, zero failed logon events, no NTLM credential validation telemetry. But closing individual gaps is not the same as having a defensible baseline.
The hypothesis: a systematic subcategory-by-subcategory audit against the Microsoft Security Baseline would reveal the full scope of what was configured, what was missing, and what I had already hardened beyond the baseline.
Environment
Windows 11 Enterprise, domain-joined. Domain controller dc01 (Active Directory). Tools: auditpol /get /category:*, wevtutil, PowerShell registry operations. Pipeline: Windows Security Log → Wazuh Agent → Wazuh Manager → Splunk / OpenSearch → Grafana.
Methodology
Step 1 — Capture before-state snapshot
Full Advanced Audit Policy exported in three formats: plain text, CSV, and Local Security Policy export. This is the documented baseline — everything that follows is diffed against it.
Step 2 — Map against Microsoft Security Baseline
All 27 audit subcategories compared against Microsoft-recommended settings. For each: current state, baseline recommendation, and delta classification (match, superset, gap, or hardened-beyond).
Step 3 — Enable subcategories
Each subcategory enabled for both Success and Failure, with documented justification mapping to detection capability and MITRE ATT&CK technique.
Step 4 — Enable command-line logging
Registry key ProcessCreationIncludeCmdLine_Enabled = 1 set. The single highest-priority gap from the threat hunt — the fix that unlocks triage of every process creation event.
Step 5 — Expand Security Event Log
Default 20MB fills in hours with 27 subcategories active. Expanded to 1GB via wevtutil sl Security /ms:1073741824.
Step 6 — After snapshot and diff
After snapshot captured. Diff report generated as markdown table showing every subcategory change.
Findings
MITRE ATT&CK Techniques Unblocked
| Technique | ID | Enabling Subcategory |
|---|---|---|
| Brute Force | T1110 | Credential Validation |
| Golden Ticket / AS-REP Roasting | T1558 | Kerberos Auth Service |
| Kerberoasting | T1558.003 | Kerberos Service Ticket Ops |
| Account Manipulation | T1098 | Security Group Mgmt |
| Create Account | T1136 | User Account Mgmt |
| Windows Credential Manager | T1555.004 | DPAPI Activity |
| Removable Media | T1091 | Plug and Play Events |
| Data from Local System | T1005 | File System |
| Run Keys / SAM Dumping | T1547.001 | Registry, SAM |
| Exfil over USB | T1052.001 | Removable Storage |
| Disable Event Logging | T1562.002 | Audit Policy Change |
Command-Line Logging
BEFORE: EventID 4688 CommandLine = [EMPTY in 100% of events] AFTER: EventID 4688 CommandLine = populated with full arguments
Security Log Expansion
BEFORE: 20 MB (default) AFTER: 1 GB (1,073,741,824 bytes)
Self-Detection
Event ID 4719 (Audit Policy Change) fired immediately after the hardening changes. The hardening activity was captured by the same pipeline being hardened. Any future attempt to weaken auditing generates the same event class.
Operational Impact
Verification
- Before/after exports: Plain text, CSV, and Local Security Policy at C:\OPS\audit-hardening\
- CommandLine: index=wazuh data.win.system.eventID=4688 | where len(commandLine)>0 | head 20
- Failed logon: index=wazuh data.win.system.eventID=4625 | head 20
- Meta-detection: index=wazuh data.win.system.eventID=4719
- Log size: wevtutil gl Security — maxSize=1073741824
- Registry: reg query "HKLM\SOFTWARE\...\Audit" /v ProcessCreationIncludeCmdLine_Enabled → 0x1
What This Demonstrates
Individual gap remediation is reactive. Baseline assessment is systematic. I did both.
The before/after snapshot discipline is borrowed from manufacturing process validation. You don’t declare a changeover complete because you believe it worked. You declare it complete because you can show the documented delta between the before state and the after state, and verify the output changed.