Using local credentials to log in is one way a user or attacker can bypass auditing controls and gain access to your environment. Logging local accounts that are created is one way to reduce the risk of a breach.
This use case is from the Splunk Security Essentials app. For more examples, see the Splunk Security Essentials on Splunkbase.
How to implement: For smaller environments with minimal complexity, run the following search to examine the expected domains, and add them to your explicit whitelist:
index=* daysago=7 source=*win*security
| top AccountDomain limit=0
index=* daysago=60 source=*win*security
| top limit=0 AccountDomain
| fields AccountDomain
| outputlookup allowableaccountdomains.csv
index=* source=*win*security tag=authentication
action=success LogonType=2 OR LogonType=10 OR LogonType=11
Logon Type NOT ( [ | inputlookup allowableaccountdomains.csv | table Account_Domain ] )
Data check: This use case requires Windows security data with logon success events that contain the
Most interactive logins use domain credentials. This search detects new user logins with local credentials that bypass most centralized logging and policy systems.
Use the following search:
index=* source="*WinEventLog:Security" tag=authentication action=success Logon Type ( LogonType=2 OR LogonType=10 OR LogonType=11 )
| eval AccountDomain=mvfilter(AccountDomain!="-")
| table _time user AccountDomain, AuthenticationPackage, EventCode, KeyLength, LogonProcess, LogonType, Security_ID, Type
Best practice: In searches, replace the asterisk in
index=* with the name of the index that contains the data. By default, Splunk stores data in the
main index. Therefore,
index=main. Use the
OR operator to specify one or multiple indexes to search. For example,
index=main OR index=security. See About managing indexes and How indexing works in Splunk docs for details.
Known false positives: Many service accounts will log in with local domains as a matter of normal activities, and computer accounts may also appear. It's best to consider this alert as a contextual alert rather than a material alert that you would send to the SOC.
How to respond: Determine whether this user is authorized to log in with local credentials, and whether the configuration of the local account complies with company policies around password expiration, complexity, and so on. Verify whether this is a service account that should be added to the tuning whitelist moving forward.
This example leverages Windows authentication logs. For this analysis, look at what domains you expect to see in your authentication logs, and alert on anything unexpected.
This search requires Windows security data to run. If it is not present, consider ingesting it using a Splunk Universal Forwarder. You should log logon events. There are many event IDs that we look for in the underlying logs, but they should all fall into the
audit successful (or
failed) logon events in your Windows audit policy. You should have a field called
Account_Domain defined in your Windows security logs. This field is provided by the Splunk Add-on for Windows.
If no results appear, deploy the Add-ons to the search heads to access the knowledge objects necessary for simple searching. See About installing Splunk add-ons on Splunk Docs for assistance.
For more support, post a question to the Splunk Answers community.