Winlogbeat structured event data

[jimmyjones2]

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]

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]

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]

@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]

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

[ken5scal]

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