The Loop Log

I was experimenting with group policies in Windows 11 Pro. I edited some group policies in secpol.msc, but I also ran a few custom scripts in PowerShell. The following day I noticed an excessive amount of entries in Event Viewer – Windows Logs – Security. For example, over 500 entries within an hour.

I was able to track down the primary culprit by selecting View – Group By – Event ID and seeing that Event ID 4688 alone had over 300 of those entries. Event ID 4688 corresponds to Process Creation. While this can be helpful for threat hunting, it writes an entry in Event Viewer every time a new process is created. I wanted to disable it. However, when I looked in secpol.msc, it showed as Not Configured. I also noticed other Event IDs that were being triggered where the corresponding policy in secpol.msc was set to Not Configured.

This sent me down a path of learning about the difference between secpol.msc and auditpol, and how secpol.msc is designed for enterprise environments where policies need to be centrally managed, documented, and consistently applied across multiple systems through Active Directory, while auditpol provides direct, immediate configuration control useful for scripting, automation, troubleshooting, and standalone systems where you need precise, real-time changes without the overhead of Group Policy processing.

Here are my notes:

Problem
Excessive Event Viewer logs (500+ entries/hour) in Windows Logs – Security, primarily EventID 4688 (Process Creation events). Group Policy GUI showed “Not Configured” but auditing was still active.

Root Cause
Windows has two separate audit policy systems that can conflict:

1. Legacy Audit Policy (9 broad categories) – viewed in secpol.msc > Local Policies > Audit Policy
2. Advanced Audit Policy (granular subcategories) – viewed in secpol.msc > Advanced Audit Policy Configuration

When audit settings are configured via command line (auditpol), scripts, or registry edits, they bypass Group Policy and write directly to system audit configuration. The secpol.msc GUI only shows policies set through Group Policy itself, causing the mismatch.

Key Commands (PowerShell)

# View all current audit policies.auditpol /get /category:*

# View specific subcategory.auditpol /get /subcategory:"Process Creation"

# Disable specific audit policy.auditpol /set /subcategory:"Process Creation" /success:disable /failure:disable

# Filter auditpol output to show only enabled policies.auditpol /get /category:* | findstr /v /c:"No Auditing"

# Show only Success or Failure (exclude "No Auditing").auditpol /get /category:* | findstr /c:"Success" /c:"Failure"

# Clear all audit settings (use with caution).auditpol /clear /y

# Force Group Policy update.gpupdate /force

# View resultant set of policy (what's actually applied).rsop.msc

Key Concepts
auditpol vs Group Policy GUI

auditpol shows effective/active configuration (what’s actually running).

secpol.msc shows only what was configured through Group Policy.

Command line settings (auditpol) take precedence over Group Policy.

Settings stored in registry: HKLM\Security\Policy\PolAdtEv.

Troubleshooting Workflow
Check what’s actually enabled: auditpol /get /category:*

Compare with Group Policy GUI (secpol.msc).

If mismatch exists, audit settings were configured outside Group Policy.

Use auditpol commands to directly modify effective settings.

Verify changes: auditpol /get /subcategory:"[policy name]".

Test by clearing Event Viewer logs and monitoring for 15-30 minutes.

Lessons Learned
Windows audit configuration can be set multiple ways (GUI, command line, scripts, registry).

Command line settings override Group Policy settings.

“Not Configured” in GUI doesn’t mean auditing is disabled.

Always verify effective configuration with auditpol, not just GUI.

Event ID 4688 (Process Creation) is extremely verbose. 500+ events/hour is normal when enabled.

For standalone systems, auditpol commands are more reliable than Group Policy GUI.

Use findstr to filter command output for easier reading.

Balance security monitoring needs with log volume management.

Future Project
I would like to do a deeper investigation into Group Policies, familiarize myself with what each one does, and also learn how to fine tune policies beyond simply having them enabled/disabled or set to Success, Failure, or Success and Failure. I can imagine using PowerShell might allow for a modular approach to refining Group Policies beyond the standard options.