Skip to content

Track authentication events from the Windows Security Auditing provider #705

Description

@rabbitstack

Motivation

Fibratus has no visibility into Windows authentication activity today. Logon success/failure is core telemetry for detection engineering (brute-force, lateral movement, credential validation abuse), and it's available through the Microsoft-Windows-Security-Auditing ETW provider. This provider is special: its session (the built-in Security auditing log) is started by the OS itself. Fibratus can't start or stop it, but it can open the existing trace and consume events from it.

Expectation

Fibratus gains a new Authenticate event type that surfaces both successful and failed logons through a single unified event, with a parameter indicating the outcome.

Proposal

  • Open the OS-managed Microsoft-Windows-Security-Auditing ETW session for consumption (read-only attach, no start/stop lifecycle management needed, unlike Fibratus's other kernel/user ETW sessions)
  • Handle event IDs 4624 (successful logon) and 4625 (failed logon attempt) from that provider's manifest
  • Treat both as the same underlying Authenticate event type in Fibratus's event model, distinguished by an outcome parameter (success/failure) rather than as two separate event kinds. In other words, both AuthenticateOk and AuthenticateFailed event.Type definitions will converge on the same event name - Authenticate. This will make it possible to express the event condition as evt.name = 'Authenticate' which we'll wrap into the authenticate macro. For failed authentication attempts, we'll discern on authentication.status = 'failed' field.
  • Parse the event payload via binary reading in the ParamDecoder, consistent with how other ETW events are decoded in Fibratus
  • Reference schema: the Microsoft-Windows-Security-Auditing manifest (event IDs 4624/4625). See nasbench/EVTX-ETW-Resources for the field layout

Additional context

  • Since Fibratus doesn't control this session's lifecycle, error handling should account for the session already existing/being unavailable (e.g. auditing policy not enabled for logon events) rather than assuming Fibratus-managed start semantics
  • Logon type (interactive, network, RDP, service, etc.), target/subject account, and logon ID are typically the fields of most detection value from 4624/4625 and would be natural candidates for the Authenticate event's params, alongside the success/failure outcome

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs: configIndicates the issue requires changes in the config file/flagsneeds: docsIndicates that the issue needs documentation updatesscope: events/telemetryAnything related to kernel eventstype: featureIntroduces a new functionality

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions