By Nick Higby
Splunk is a class leading logging and alerting security software that is used by many organizations. Typical features of Splunk include the ability to search the indexed logs for those that meet a certain criterion. Often this is done for the purpose of creating an alert or adding to a dashboard, but this can also useful for analyzing specific logs. This allows a person using Splunk to easily monitor Windows login events and details regarding their generation.
Login successes and failures are stored as they’re created in the security section of the Windows Event Log. As is standard with Windows logs each has a corresponding ID, namely 4624 for successes and 4625 failures. A useful part of these logs is that they contain a details section with various information, but even more importantly is that they contain a variable called LogonType which details how the logon originated. This variable can contain up to any of nine different numbers which will be detailed below.
Logon Type 2 (Interactive):
This type is most commonly thought of when dealing with successful and failed logins. It is performed by logging in via a local keyboard or another form of local device authentication such as a biometric scan. While this would be useful to track via a dashboard metric, it would not be beneficial as an alerting mechanism for logins. Normal logins do not normally need alerting for logins, but alerting may be useful for failed logins within a certain period.
Logon Type 3 (Network):
Type 3 is often used in accessing a device from another device on the network. Examples of this would include accessing shared folders or logons to IIS, Window’s web server. It could possibly be useful to generate an alert based on this type depending on your organization. If there is little use of shared folders, then alerts would be beneficial as that may indicate there is unauthorized sharing of materials.
Logon Type 4 (Batch):
This type is associated with Windows executing a scheduled task. Often there is no need to alert or monitor logins of this type because these commonly occur when a device is starting.
Logon Type 5 (Service):
Type 5 is similar to type 4 in that it is used when a service initiates a login request, as a specific user runs the service. Again, you would not normally need to alert on this specific type as services are starting and stopping at a more frequent rate than most logon types.
Logon Type 7 (Unlock):
Logon type 7 shares its locality of use with type 2, although this type is based on unlocking a computer that has a user already signed in. This contrasts with actually signing a user into a device. As in type 2 the main use of alerting for this case would be on many failed logins within a short period of time.
Logon Type 8 (NetworkCleartext):
This type is similar to type 3 in that a network login is attempted but the password is sent in cleartext. Type 8 is mainly present in basic authentication for IIS. Alerting may be useful in this case as it would allow you to see if a server is still using this possibly insecure method of authentication.
Logon Type 9 (NewCredentials):
Type 9 is not usually seen in events and is only associated with RunAs with alternate credentials. Alerting would not be useful here as events commonly display another type instead of this one.
Logon Type 10 (RemoteInteractive):
Remote Desktop and Terminal Services are common signifiers of this logon type. It allows an easy distinction between the local sessions of type 2 and 7 logins. Triggering an alert for this type would add benefit to an organization who does not commonly use remote sessions, thus lessening the chance of someone accessing data they are not supposed to.
Logon Type 11 (CachedInteractive):
Type 11 is used in conjunction with Window’s ability to cache login credential hashes while connected to a domain. This type is then thrown when a login is performed while a device is not attached to the domain. A dashboard metric would be more beneficial here than an alert as this would still be a local login on a device, and better at tracking how often users are not connected to a domain.
Creating the Search:
In order to create an alert or add a metric to a dashboard you first have to start with a search. The parameters for this include, “index=*” to display all indexes, “source=“WinEventLog:Security”” to specify the security log, “EventCode=4624” to specify successful logins (could also be 4625 for failed), and “Logon_Type=7” to specify the lock screen login (could also use any of the other values mentioned above). Host is not needed in this instance but can be used if you have many devices and want to specify logs from a certain one.
Setting up the Alert:
In the case of some of the login types specified above an alert should be created in order to maximize the login logs Splunk has captured. To do this you would use the search string created above and click on Save As Alert. From here you can specify the title, alert type, trigger conditions, and various other options.
Adding a Dashboard Metric:
As seen in the above graph the results of this search are counted on a weekly value and formed into a line graph measured over time. This is done simply by adding a pipe with the following search string, “timechart count span=1w”. The span value can then be adjusted to best fit what time value you are trying to gather data for. After this is completed the search metric can be used in a dashboard to constantly display the graph.
From the above logon types, it can be seen that you don’t necessarily need to alert on all them in every organization. It all depends on how your organization is structured, and which logon types are uncommon in it. Splunk has additional options for manipulating the data shown above and allows you to customize the login metrics to best suit your needs.