Splunk® User Behavior Analytics

Get Data into Splunk User Behavior Analytics

Acrobat logo Download manual as PDF


Acrobat logo Download topic as PDF

Add Windows events to Splunk UBA

Windows security events from endpoints such as desktop systems or laptops are used by Splunk UBA to provide insight into system activity. You can also use Windows event data to associate IP addresses to device names and human users.

Windows events can be logged in many formats, with native multiline or XML being the most command formats. Splunk UBA can ingest Windows logs in both multiline and XML formats. A different method of ingestion is required for each, as described below:

How to get multiline Windows events in to Splunk UBA

Perform the following steps to get multiline Windows events in to Splunk UBA:

  1. Verify that your Windows events are in multiline format. See What does a multiline Windows event look like?
  2. Follow the steps in Use the Splunk Raw Events connector to get multiline Windows events in to Splunk UBA.

What does a multiline Windows event look like?

An example multiline Windows event is shown below:

11/18/2020 2:49:32 PM
LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4624
EventType=0
Type=Information
ComputerName=ubanode.exampledomain.local
TaskCategory=Logon
OpCode=Info
RecordNumber=989284571
Keywords=Audit Success
Message=An account was successfully logged on.
Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0
Logon Type:         3
Impersonation Level:        Impersonation
New Logon:
    Security ID:        EXAMPLEDOMAIN\ad_user1
    Account Name:       ad_user1
    Account Domain:     EXAMPLEDOMAIN
    Logon ID:       0xF13AE
    Logon GUID:     {3134bb44-1592-fc31-6404-b4b820e7507e}
Process Information:
    Process ID:     0x0
    Process Name:       -
Network Information:
    Workstation Name: 
    Source Network Address: -
    Source Port:        -
Detailed Authentication Information:
    Logon Process:      Kerberos
    Authentication Package: Kerberos
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

Use the Splunk Raw Events connector to get multiline Windows events in to Splunk UBA

Perform the following steps to get your multiline Windows events in to Splunk UBA. See Add raw events from the Splunk platform to Splunk UBA for detailed instructions about how to add data sources using the Splunk Raw Events connector.

  1. In Splunk UBA, select Manage > Data Sources.
  2. Click New Data Source.
  3. Select Splunk as the data source type.
  4. Click Next.
  5. Specify a name for the data source, such as Splunk.
  6. Type a connection URL that matches the URL for your Splunk platform search head and management port. For example, https://splunksearchhead.splunk.com:8089. If you have search head clustering configured and a load balancer is available, you can specify the load balancer host name to avoid a single point failure. Ensure that port 8089 is accessible on the load balancer.
  7. Type the user name and password for the Splunk platform account.
  8. Select a Connector Type of Splunk Raw Events.
  9. Click Next.
  10. Select a time range, such as Live and All time.
  11. Click Next.
  12. Click Splunk Query and add the name of your index as the query. For example:

    index=<your_multiline_Windows_index_name>

  13. Select Single Format, then click in the drop-down list and select Windows Event Log (Multiline).
  14. Click Next.
  15. To add the data source in test mode, leave the check box selected. See Add data sources to Splunk UBA in test mode.
  16. Click OK.

How to get XML Windows events in to Splunk UBA

Perform the following steps to get multiline Windows events in to Splunk UBA:

  1. Verify that your Windows events are in XML format. See What does an XML Windows event look like?
  2. Follow the steps in Use the Splunk Direct connector to get XML Windows events in to Splunk UBA.

What does an XML Windows event look like?

An example XML Windows event is shown below:

<?xml version="1.0"?>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}"/>
    <EventID>4624</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2015-11-12T00:24:35.079785200Z"/>
    <EventRecordID>211</EventRecordID>
    <Correlation ActivityID="{00D66690-1CDF-0000-AC66-D600DF1CD101}"/>
    <Execution ProcessID="716" ThreadID="760"/>
    <Channel>Security</Channel>
    <Computer>WIN-GG82ULGC9GO</Computer>
    <Security/>
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-5-18</Data>
    <Data Name="SubjectUserName">WIN-GG82ULGC9GO$</Data>
    <Data Name="SubjectDomainName">WORKGROUP</Data>
    <Data Name="SubjectLogonId">0x3e7</Data>
    <Data Name="TargetUserSid">S-1-5-21-1377283216-344919071-3415362939-500</Data>
    <Data Name="TargetUserName">Administrator</Data>
    <Data Name="TargetDomainName">WIN-GG82ULGC9GO</Data>
    <Data Name="TargetLogonId">0x8dcdc</Data>
    <Data Name="LogonType">2</Data>
    <Data Name="LogonProcessName">User32</Data>
    <Data Name="AuthenticationPackageName">Negotiate</Data>
    <Data Name="WorkstationName">WIN-GG82ULGC9GO</Data>
    <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">-</Data>
    <Data Name="KeyLength">0</Data>
    <Data Name="ProcessId">0x44c</Data>
    <Data Name="ProcessName">C:\\Windows\\System32\\svchost.exe</Data>
    <Data Name="IpAddress">127.0.0.1</Data>
    <Data Name="IpPort">0</Data>
    <Data Name="ImpersonationLevel">%%1833</Data>
    <Data Name="RestrictedAdminMode">-</Data>
    <Data Name="TargetOutboundUserName">-</Data>
    <Data Name="TargetOutboundDomainName">-</Data>
    <Data Name="VirtualAccount">%%1843</Data>
    <Data Name="TargetLinkedLogonId">0x0</Data>
    <Data Name="ElevatedToken">%%1842</Data>
  </EventData>
</Event>

Use the Splunk Direct connector to get XML Windows events in to Splunk UBA

Perform the following steps to get your XML Windows events in to Splunk UBA. See Add CIM-compliant data from the Splunk platform to Splunk UBA for detailed instructions about how to add data sources using the Splunk Direct connector. The procedure for adding XML Windows events into Splunk UBA is the same as adding a CIM-compliant data source, except that you will not select the CIM Compliant checkbox during the procedure.

  1. In Splunk UBA, select Manage > Data Sources.
  2. Click New Data Source.
  3. Select a data source type of Splunk.
  4. Click Next.
  5. Specify a name for the data source, such as Splunk.
  6. Type a connection URL that matches the URL for your Splunk platform search head and management port. For example, https://splunksearchhead.splunk.com:8089. If you have search head clustering configured and a load balancer is available, you can specify the load balancer host name to avoid a single point failure. Ensure that port 8089 is accessible on the load balancer.
  7. Type the user name and password for the Splunk platform account.
  8. Leave or select Splunk Direct as the connector type.

    Do not check the CIM Compliant check box.

  9. Click Next.
  10. Select a time range, such as Live and All time.
  11. Click Next.
  12. Select Splunk Query and enter the following search in the field. Replace <YOUR_INDEX_NAME> with the name of your XML Windows events index.

    index="<YOUR_INDEX_NAME>" | eval uba_source_type="ad" | spath output='Event.System.Computer' path=Event.System.Computer | spath output='Event.System.Level' path=Event.System.Level | spath output='Event.System.Version' path=Event.System.Version | rex "\<Provider Name=\'(?<SourceName>[^\']+)\'" | eval Account_Domain=SubjectDomainName, Account_Name=SubjectUserName, Application_Name=if(isnotnull(Application), Application, app), Authentication_Package=AuthenticationPackageName, Caller_Computer_Name=if(isnotnull(TargetDomainName), TargetDomainName, CallerComputerName), Caller_Process_ID=if(isnotnull(CallerProcessId), CallerProcessId, ProcessId), Caller_Process_Name=if(isnotnull(CallerProcessName), CallerProcessName, ProcessName), Client_Address=IpAddress, Client_Port=IpPort, commandArgs=CommandLine, ComputerName=Computer, Creator_Process_ID=ProcessId, Error_Code=Status, EventCode=EventID, EventType=if(isnotnull(EventType),EventType, "0"), Failure_Code=Status, Failure_Reason=FailureReason, Group_Domain=TargetUserName, Group_Name=TargetDomainName, Handle_ID=HandleId, Impersonation_Level=ImpersonationLevel, LogName=Channel, Logon_Account=TargetUserName, Logon_GUID=LogonGuid, Logon_ID=if(isnotnull(SubjectLogonId), SubjectLogonId, TargetLogonId), Logon_Process=LogonProcessName, Logon_Type=LogonType, Network_Address=IpAddress, New_Account_Name=TargetUserName, New_Process_ID=NewProcessId, New_Process_Name=NewProcessName, New_Security_ID=TargetUserSid, Object_Name=ObjectName, Object_Server=ObjectServer, Object_Type=ObjectType, Operation_Type=OperationType, Privileges=PrivilegeList, Privileges_Used_for_Access_Check=PrivilegeList, Process_Command_Line=CommandLine, Process_ID=ProcessId, Process_Name=ProcessName, Protocol=Protocol, Result_Code=Status, Security_ID=SubjectUserSid, Server=Computer, Service_ID=ServiceSid, Service_Name=ServiceName, Share_Path=ShareLocalPath, Source_Address=SourceAddress, Source_Network_Address=IpAddress, Source_Port=if(isnotnull(IpPort), IpPort, SourcePort), Source_Workstation=Workstation, Status=Status, Sub_Status=SubStatus, Supplied_Realm_Name=TargetDomainName, Target_Server_Name=TargetServerName, Ticket_Encryption_Type=TicketEncryptionType, Ticket_Options=TicketOptions, Token_Elevation_Type=TokenElevationType, Transaction_ID=TransactionId, User_ID=TargetSid, Workstation_Name=if(isnotnull(WorkstationName), WorkstationName, Workstation_Name) | fields 'Event.System.Computer', 'Event.System.Level', 'Event.System.Version', Access_Mask, Accesses, Account_Domain, Account_Name, Application_Name, Authentication_Package, Caller_Computer_Name, Caller_Process_ID, Caller_Process_Name, Client_Address, Client_Port, commandArgs, ComputerName, Creator_Process_ID, Disabled_Privileges, Enabled_Privileges, Error_Code, EventCode, EventType, Failure_Code, Failure_Reason, Group_Domain, Group_Name, Handle_ID, Impersonation_Level, Keywords, LogName, Logon_Account, Logon_GUID, Logon_Process, Logon_Type, Network_Address, New_Account_Name, New_Process_ID, New_Process_Name, New_Security_ID, Object_Name, Object_Server, Object_Type, Operation_Type, Privileges, Privileges_Used_for_Access_Check, Process_ID, Process_Name, Protocol, Result_Code, Security_ID, Server, Service_ID, Service_Name, Share_Path, SourceName, Source_Address, Source_Network_Address, Source_Port, Source_Workstation, Status, Sub_Status, Supplied_Realm_Name, Target_Server_Name, Ticket_Encryption_Type, Ticket_Options, Token_Elevation_Type, Transaction_ID, User_ID, Workstation_Name, action, privilege_id, sourcetype, uba_source_type

  13. Click Next.
  14. Select Single Format as the data format, then click in the drop-down list and select AD.
  15. Click Next.
  16. Remove everything in the Splunk Query field, and paste the same search from earlier in this procedure here.
  17. Click Next.
  18. To add the data source in test mode, leave the check box selected. See Add data sources to Splunk UBA in test mode.
  19. Click OK to save the data source.

Which Windows events are used by Splunk UBA?

The raw parser in Splunk UBA doesn't look for specific Windows events, Rather, all Windows events are analyzed to find common field names such as account name or workstation. These field names are extracted from Windows events and stored in data cubes to be consumed by anomaly rules and models. Having the right Windows events in Splunk UBA can lead to meaningful detections so that the desired security use cases are unlocked.

See the following categories of Windows events used by Splunk UBA:

Highly recommended Windows events used by Splunk UBA

Ingest the events listed in this table so that Splunk UBA can generate the proper anomalies and threats. See Which data sources to I need? to identify the anomalies and threats generated by Windows events. The absence of any of the listed events will prevent anomalies and threats from being generated.

Windows Event ID Description
4624 An account was successfully logged on.
4776 The computer attempted to validate the credentials for an account.
4768 A Kerberos authentication ticket (TGT) was requested.
4769 A Kerberos service ticket was requested.
4625 An account failed to logon.
4634 An account was logged off.

Recommended Windows events used by Splunk UBA

It is recommended to log the following Windows event types so that Splunk UBA can generate anomalies and threats.

Windows Event ID Description
1102 The audit log was cleared.

Nice to have Windows events used by Splunk UBA

The following Windows event types enhance the fidelity of your detections by providing additional evidence and clarity.

Windows Event ID Description
Windows PowerShell events
4103 PowerShell Module Logging. See Configure PowerShell logging to see PowerShell anomalies in Splunk UBA.
4104 PowerShell Script Block Logging. See Configure PowerShell logging to see PowerShell anomalies in Splunk UBA.
Windows object and registry handling events
4657 A registry value was modified.
4691 Indirect access to an object was requested.
4692 Backup of data protection master key was attempted.
4693 Recovery of data protection master key was attempted.
4695 Unprotection of auditable protected data was attempted.
4907 Auditing settings on object were changed.
4911 Resource attributes of the object were changed.
5145 A network share object was checked to see whether client can be granted desired access.
Windows domain, trust, and authentication events
4706 A new trust was created to a domain.
4713 Kerberos policy was changed.
4715 The audit policy (SACL) on an object was changed.
4772 A Kerberos authentication ticket request failed.
4820 A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions.
Windows policy events
6273 Network Policy Server denied access to a user.
6276 Network Policy Server quarantined a user.
6277 Network Policy Server granted access to a user but put it on probation because the host did not meet the defined health policy.
Windows account handling events
4627 Group membership information.
4704 A user right was assigned.
4718 System security access was removed from an account.
4719 System audit policy was changed.
4727 A security-enabled global group was created.
4728 A member was added to a security-enabled global group.
4729 A member was removed from a security-enabled global group.
4730 A security-enabled global group was deleted.
4731 A security-enabled local group was created.
4732 A member was added to a security-enabled local group.
4733 A member was removed from a security-enabled local group.
4734 A security-enabled local group was deleted.
4735 A security-enabled local group was changed.
4737 A security-enabled global group was changed.
4744 A security-disabled local group was created.
4745 A security-disabled local group was changed.
4746 A member was added to a security-disabled local group.
4747 A member was removed from a security-disabled local group.
4750 A security-disabled global group was changed.
4754 A security-enabled universal group was created.
4755 A security-enabled universal group was changed.
4756 A member was added to a security-enabled universal group.
4757 A member was removed from a security-enabled universal group.
4758 A security-enabled universal group was deleted.
4759 A security-disabled universal group was created.
4760 A security-disabled universal group was changed.
4761 A member was added to a security-disabled universal group.
4763 A security-disabled universal group was deleted.
4767 A user account was unlocked.
4781 The name of an account was changed.
4782 The password hash an account was accessed.
4797 An attempt was made to query the existence of a blank password for an account.
4798 A user's local group membership was enumerated.
4799 A security-enabled local group membership was enumerated.
Windows device handling events
4800 The workstation was locked.
4801 The workstation was unlocked.
6416 A new external device was recognized by the system.
Windows security incidents events
4618 A monitored security event pattern has occurred.
4649 A replay attack was detected.
Windows firewall policy changes events
4946 A change has been made to Windows Firewall exception list. A rule was added.
4947 A change has been made to Windows Firewall exception list. A rule was modified.
4948 A change has been made to Windows Firewall exception list. A rule was deleted.
4950 A Windows Firewall setting has changed.
Last modified on 07 December, 2020
PREVIOUS
Which data sources do I need?
  NEXT
Get data into Splunk UBA

This documentation applies to the following versions of Splunk® User Behavior Analytics: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.4.1


Was this documentation topic helpful?

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters