Fix Authentication suppression dropping UAC elevation logons (fixes #28)

[ZayanKhan-12]

Background

Fixes #28.

Authentication.xml suppressed on EventData field position 1:

<Suppress Path="Security">*[EventData[Data[1]="S-1-5-18"]]</Suppress>

On 4624, Data[1] is SubjectUserSid — the account that requested the logon — not TargetUserSid, the account that was logged on. UAC elevation produces a 4624 where SYSTEM is the subject and a real user is the target, so @uplateandonline is correct that every UAC logon was silently dropped.

Why not the Data[5] fix from the thread

@Beercow suggested changing Data[1] to Data[5]. That does fix 4624, but the <Suppress> applies to every <Select> in the query, and EventData ordering is not consistent across the event IDs this subscription collects:

Event	Data[1]	Data[5]
4624 / 4625	SubjectUserSid	TargetUserSid
4634	TargetUserSid	LogonType
4647	TargetUserSid	(only 4 fields — no Data[5])
4672	SubjectUserSid	PrivilegeList

On 4634 Data[5] is LogonType and on 4672 it is PrivilegeList, so neither can ever equal a SID. Data[5] silently stops suppressing SYSTEM logoffs (4634) and SYSTEM special-privilege assignments (4672) — the two highest-volume SYSTEM event types in this query. It would increase forwarded volume substantially rather than cutting it.

I mention this only because the suggestion reads as a drop-in fix and the failure mode is silent in the noisy direction.

The fix

Match on named fields, which removes the positional fragility entirely:

<Suppress Path="Security">*[EventData[Data[@Name="TargetUserSid"]="S-1-5-18"]]</Suppress>
<Suppress Path="Security">*[System[(EventID=4672)]] and *[EventData[Data[@Name="SubjectUserSid"]="S-1-5-18"]]</Suppress>

• Matching TargetUserSid keeps UAC logons (target is a real user) while still dropping genuine SYSTEM logons, and stays correct on 4634/4647 where the target fields come first.
• 4672 has no TargetUserSid — the account receiving the privileges is the subject — so it gets its own rule scoped to that event ID. Without the EventID=4672 scope, matching SubjectUserSid globally would re-break UAC 4624s.

This is consistent with existing practice in the repo: Data[@Name=...] on Path="Security" is already used in Explicit-Credentials.xml and Registry.xml, and inside a <Suppress> in DNS.xml.

Per the issue's second request, the inline comment now records the field-ordering table and why the rule is shaped this way, so the next person doesn't have to rediscover it.

Verification

Rather than reason about field offsets from memory, I built synthetic Security events using the documented Microsoft-Windows-Security-Auditing schema and evaluated all three candidate rules with a real XPath engine. Windows evaluates *[...] with the document as context, so * matches <Event>; that maps to /*[...] in standard XPath, which is the only transformation applied.

event                                                want  A: Data[1]   B: Data[5]   C: named
4624 UAC elevation (Subject=SYSTEM, Target=user)     no    YES  WRONG   no   ok      no   ok
4624 interactive user logon                          no    no   ok      no   ok      no   ok
4624 SYSTEM service logon (noise)                    YES   YES  ok      YES  ok      YES  ok
4634 SYSTEM logoff (noise)                           YES   YES  ok      no   WRONG   YES  ok
4634 user logoff                                     no    no   ok      no   ok      no   ok
4647 user initiated logoff                           no    no   ok      no   ok      no   ok
4672 SYSTEM special privileges (noise)               YES   YES  ok      no   WRONG   YES  ok
4672 admin user special privileges                   no    no   ok      no   ok      no   ok
4776 credential validation                           no    no   ok      no   ok      no   ok

A (current)   8/9   - reproduces the bug in #28
B (Data[5])   7/9   - fixes 4624, regresses 4634 and 4672
C (this PR)   9/9

Rule A reproduces exactly the reported bug, which confirms the harness models the real semantics. The final run extracts the <Suppress> expressions from the committed file rather than from a copy, and also checks that the subscription XML parses, that the CDATA QueryList is itself well-formed, and that all 6 Select and 2 Suppress expressions compile as valid XPath.

What I could not verify

I'm on macOS, so I could not run wecutil cs to confirm the collector accepts the subscription, nor capture live events. Two things worth a reviewer's eye on Windows:

1. A top-level and inside <Suppress>. <Select> uses this form throughout the repo, and Select/Suppress share the same XPath grammar, but I could not confirm it against a live collector. If it is rejected, the alternative is moving 4672 into its own <Query Id="1"> with a self-contained suppress.
2. Volume impact. Keeping UAC logons increases 4624 volume, as the reporter noted. The 4634/4672 suppression is preserved, so this should be materially cheaper than the Data[5] change.

Note on scope

Single-file change; no other subscription touched. I have a separate PR (#66, for #50) that adds a CLAUDE.md and a subscription validator — deliberately not duplicated here so the two don't conflict on merge. This PR stands alone.

[palantirtech]

Thanks for your interest in palantir/windows-event-forwarding, @ZayanKhan-12! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.