Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[winlogbeat] message ids not expanded in individual fields #40386

Closed
Tracked by #39580
jdu2600 opened this issue Jul 30, 2024 · 6 comments · Fixed by #41525
Closed
Tracked by #39580

[winlogbeat] message ids not expanded in individual fields #40386

jdu2600 opened this issue Jul 30, 2024 · 6 comments · Fixed by #41525
Labels
bug Team:Security-Windows Platform Windows Platform Team in Security Solution Winlogbeat

Comments

@jdu2600
Copy link

jdu2600 commented Jul 30, 2024

Windows Event logs can include localised strings. To achieve this the raw event includes message ids that need to be looked up in localisation message tables.

Currently winlogbeat does this localisation for the message field, but not for the original individual fields.

Extracts showing the behaviour here -

{
  "winlog.event_data": {
    "VirtualAccount": "%%1843",
    "ElevatedToken": "%%1842",
    "ImpersonationLevel": "%%1833",
  },
  "message": "...Virtual Account:\t\tNo\n\tElevated Token:\t\tYes\n\nImpersonation Level:\t\tImpersonation...",
}
{
  "winlog.event_data": {
    "FailureReason": "%%2304",
  },
  "message": "...Failure Reason:\t\tAn Error occured during Logon.\n...",
}

The message id can be resolved using kernel32!FormatMessage.

@jdu2600 jdu2600 added bug Winlogbeat Team:Security-Windows Platform Windows Platform Team in Security Solution labels Jul 30, 2024
@elasticmachine
Copy link
Collaborator

Pinging @elastic/sec-windows-platform (Team:Security-Windows Platform)

@intxgo
Copy link
Contributor

intxgo commented Jul 31, 2024

does this concerns events originating from localhost or forwarded events? In the latter case, winlogbeat doesn't attempt doing any substitutions on it's own as the resource dlls most likely are not present on the WEC server. Forwarded events are just trivially converted from xml to json.

@jdu2600
Copy link
Author

jdu2600 commented Aug 1, 2024

I suspect both - but have not confirmed.
iirc the XML includes the message ids and it is the responsibility of the client (eg Event Viewer, winlogbeat) to localise them.

For System events the resource dll will be on the WEC server - so we could make a best effort attempt.
At a glance it looks like we do this currently but only for the message field, and the other event data fields are left as is.

// Associate key names with the event data values.
r.addEventData(eventMeta, eventData, event)
if event.Message, err = r.formatMessage(md, eventMeta, handle, eventData, uint16(event.EventIdentifier.ID)); err != nil {
errs = append(errs, fmt.Errorf("failed to get the event message string: %w", err))
}

@marc-gr
Copy link
Contributor

marc-gr commented Aug 1, 2024

For System events the resource dll will be on the WEC server - so we could make a best effort attempt.

Is this always true? We could do a best effort as you mention and stop trying if it fails.

@jdu2600
Copy link
Author

jdu2600 commented Aug 2, 2024

Is this always true?

If it wasn't true then our message field would also have the raw %% message ids, right?

During addEventData we should be able to call kernel32!FormatMessage (or wevtapi!EvtFormatMessage) if the extracted value matches ^%%[0-9]+$.

@marc-gr
Copy link
Contributor

marc-gr commented Aug 2, 2024

Oh I think I misunderstood when you meant System as System events even if they were forwarded. My bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Team:Security-Windows Platform Windows Platform Team in Security Solution Winlogbeat
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants