Cherry-pick of PR #17517 to 7.x branch. Original message:

Added Kerberos Tickets Events (4768,4769,4770,4771,4776), aditional logon events (4778,4779,4964), sensitive privilege use events (4673,4674), service and task scheduler events (4697,4698,4699,4700,4701,4702)

Event categories, types and outcome were aligned to the ones defined in ECS 1.5

Other minor fixes/improvements introduced

New Events
The new events are commonly used when analyzing lateral movements
Sources:
https://www.jpcert.or.jp/english/pub/sr/20170612ac-ir_research_en.pdf
https://www.sans.org/security-resources/posters/dfir/windows-forensic-analysis-170
https://www.sans.org/security-resources/posters/dfir/hunt-evil-165
https://www.sans.org/security-resources/posters/dfir/windows-forensics-evidence-of-75

Event Categories and Types

ECS 1.5 define which are the values allowed for event categories and types.
https://www.elastic.co/guide/en/ecs/current/ecs-allowed-values-event-category.html
https://www.elastic.co/guide/en/ecs/current/ecs-allowed-values-event-type.html

Modifications have been introduced in order to adjust the events to fall into allowed categories/types.
In order to add flexibility the function addActionDesc was replace for a more general function, the addEventFields. This function completes the category (event.category), the primary type (event.type) and the action description (event.action).
Aditional types can be attached to the event via AppendTo function.
For example, for Evt 4719 the addEventFields sets the event.category="iam", event.type="admin" but because it is also a change thet event.type=change is also added via AppendTo in the specific function that process the event
Having more than one value in the event.type, allow us to detect, for example, this type of activity

 event.category:iam AND event.type:admin AND event.type:change

In this way event categories/types can be easily modified according to futher ECS changes.

For all events the evet.outcome was also aligned to the specification of ECS 1.5
https://www.elastic.co/guide/en/ecs/current/ecs-allowed-values-event-outcome.html

Fixes/Improvements

• Event 4648:
  Events 4648 and 4624 were processed by the same function, but the winlog.logon.id field needs to be copied from different source field in the case of evt 4648
  For evt 4624 the winlog.logon.id comes from winlog.data.TargetLogonID whereas that for evt 4648 should be copied from winlog.data.SubjectLogonID
  The processing for those events were decoupled.
  In the Evt 4648 we have now the winlog.logon.id of the user logging in with the explicit credentials and thus be able to correlate with the original winlog.logon.id. See example below

• Event 4625:
  In this event the Add(copyTargetUserLogonId) was replaced for the .Add(copySubjectUserLogonId). The relevant LogonID information is in the winlog.event_data.SubjectLogonId and was obtain from winlog.event_dataTargetLogonId
  Normaly the winlog.event_data.SubjectLogonId is 0x0 but when one logged-in user tries to run as a different user and fails to, the LogonID is the one of the logged-in user
  In this way we can track all the activity, right from the original connection. See example below
  

• Events 4728,4729,4732,4733,4743,4746,4747,4751,4752,4756,4757,4761,4762 :
  Extracted user from winlog.event_data.MemberName in order to be added to related.user field

• Events 4688 and 4689: winlog.logon.id field was missing. The .Add(copySubjectUserLogonId) was added.

• Event 4688: Modified to not to add related.user when winlog.event_data.TargetUserName is "-"

• Event 4672: add event.outcome. Aligned to ECS 1.5

• Event 4647: Missing event.action

• Event 4731 and 1102: Wrong event.action

• copyTargetUser was modify in order to parse properly the user name in Kerberos Events

• Added missing codes to logonFailureStatus table in order to map failure codes from Event 4776

• addAuthSuccess and addAuthFailed removed and replaced for addEventOutcome and addEventFields functions.

• Enrichment information sources. For all tables with data used to enrich events the source of that information was added.

Future Work

• From the discussion [ECS] Multiple users in an event proposal ecs#809 will be (probably) modifications to perform in order to adapt events with mutiples users
• Policy Modifications Events