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 structured event data #1053

Closed
jimmyjones2 opened this issue Feb 27, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@jimmyjones2
Copy link

commented Feb 27, 2016

I've previously used nxlog but would like to replace it with Winlogbeat... but there is one feature missing for me - parsing of EventData into JSON fields, rather than just having the human readable message. This allows much more powerful analysis in Kibana as you can aggregate on all kinds of things.

<EventData>
<Data name="key">value</Data>
</EventData>

For some reason a small number of events, such as 1033 from MsiInstaller (logs installation of applications) has the data tags without any attributes - maybe a simple array would be the best way to handle that case?

@andrewkroh

This comment has been minimized.

Copy link
Member

commented Feb 27, 2016

I would like to implement this since we should have all that data available already. I have heard this request from a few people. For everyone's reference, the current event structure can be seen here.

@andrewkroh andrewkroh self-assigned this Mar 14, 2016

andrewkroh added a commit to andrewkroh/beats that referenced this issue Mar 15, 2016

Include structured event data with each event.
The benefit to this change is that Winlogbeat now provides the data from
the event log message in a structured format so that most message no
longer require groking to extract data.

Changes
- Add additional data to the events published by Winlogbeat. The new
  fields are activity_id, event_data, keywords, opcode, process_id,
  provider_guid, related_activity_id, task, thread_id, user_data, and
  version.
- The message_inserts field was replaced with the event_data field
- The category field was renamed to task to better align with the Windows
  Event Log API naming

Closes elastic#1053

@ruflin ruflin closed this in 074fa5d Mar 16, 2016

@andrewkroh

This comment has been minimized.

Copy link
Member

commented Mar 17, 2016

If anyone wants to test this you can use the development build. The updated list of exported fields is here. And there are some details in the #1153.

Checklist:

  • Re-test on a machine with a non en-US locale and verify that the message field is rendered correctly. I want to make sure that UTF-16 characters like Japanese symbols are not broken by these changes.

Please leave any questions or feedback (bad or good) here. Thanks!

@ken5scal

This comment has been minimized.

Copy link

commented May 11, 2017

@andrewkroh This is a quite late follow-up message, but our winlogbeat runs on a machine with Japanese locale. Although message field is rendered fine, message field seems failed to be structured.

Below is the message received in logstash when I logged on(event id 4624) to the Windows server in which winlogbeat v5.1.1 runs. I know v5.1.1 is not the latest winlogbeat, but according to release notes, it should have been capable of structuring event data, right?

"message": "アカウントが正常にログオンしました。\n\nサブジェクト:\n\tセキュリティ ID:\t\tS-1-0-0\n\tアカウント名:\t\t-\n\tアカウント ドメイン:\t\t-\n\tログオン ID:\t\t0x0\n\nログオン タイプ:\t\t\t3\n\n偽装レベル:\t\t偽装\n\n新しいログオン:\n\tセキュリティ ID:\t\tSID1\n\tアカウント名:\t\tWINDOWS-machine$\n\tアカウント ドメイン:\t\tMY_DOMAIN\n\tログオン ID:\t\t0x12881DD\n\tログオン GUID:\t\t{69640C6A-5FD0-6594-6B0C-2403DA6DE9A1}\n\nプロセス情報:\n\tプロセス ID:\t\t0x0\n\tプロセス名:\t\t-\n\nネットワーク情報:\n\tワークステーション名:\t\n\tソース ネットワーク アドレス:\t192.168.81.102\n\tソース ポート:\t\t63365\n\n詳細な認証情報:\n\tログオン プロセス:\t\tKerberos\n\t認証パッケージ:\tKerberos\n\t移行されたサービス:\t-\n\tパッケージ名 (NTLM のみ):\t-\n\tキーの長さ:\t\t0\n\nこのイベントは、ログオン セッションの作成時に生成されます。このイベントは、アクセス先のコンピューターで生成されます。\n\nサブジェクトのフィールドは、ログオンを要求したローカル システム上のアカウントを示します。これはサーバー サービスなどのサービスまたは Winlogon.exe や Services.exe などのローカル プロセスであることが最も一般的です。\n\nログオン タイプのフィールドは、発生したログオンの種類を示します。最も一般的なタイプは、2 (対話型) と 3 (ネットワーク) です。\n\n新しいログオンのフィールドは、新しいログオンを作成するアカウント、つまりログオン先のアカウントを示します。\n\nネットワークのフィールドは、リモート ログオン要求の送信元を示します。ワークステーション名は常に表示されるとは限らず、場合によっては空白のままであることがあります。\n\n偽装レベルのフィールドは、ログオン セッション内のプロセスが偽装できる程度を示します。\n\n認証情報のフィールドは、この特定のログオン要求に関する詳細情報を示します。\n\t- ログオン GUID は、このイベントを KDC イベントに関連付ける場合に使用できる一意の識別子です。\n\t- 移行されたサービスは、このログオン要求に関与した中間サービスを示します。\n\t- パッケージ名は、NTLM プロトコルのうち使用されたサブプロトコルを示します。\n\t- キーの長さは、生成されたセッション キーの長さを示します。これは、セッション キーが要求されなかった場合は 0 になります。",
@andrewkroh

This comment has been minimized.

Copy link
Member

commented May 11, 2017

The structured data is stored under an event_data key. You can see examples here.

@ken5scal

This comment has been minimized.

Copy link

commented May 11, 2017

Ahh, I restarted the process, and now it appeared. Also, message field seems rendered correctly. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.