Does anyone have examples of how to use Splunk to detect when local credentials are used to log into endpoints?
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 Account_Domain limit=0
index=* daysago=60 source=*win*security
| top limit=0 Account_Domain
| fields Account_Domain
| outputlookup allowable_account_domains.csv
index=* source=*win*security tag=authentication
action=success Logon_Type=2 OR Logon_Type=10 OR Logon_Type=11
Logon Type NOT ( [ | inputlookup allowable_account_domains.csv | table Account_Domain ] )
Data check: This use case requires Windows security data with logon success events that contain the Account_Domain
.
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 ( Logon_Type=2 OR Logon_Type=10 OR Logon_Type=11 )
| eval Account_Domain=mvfilter(Account_Domain!="-")
| table _time user Account_Domain, Authentication_Package, EventCode, Key_Length, Logon_Process, Logon_Type, 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=*
becomes 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.
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 Account_Domain limit=0
index=* daysago=60 source=*win*security
| top limit=0 Account_Domain
| fields Account_Domain
| outputlookup allowable_account_domains.csv
index=* source=*win*security tag=authentication
action=success Logon_Type=2 OR Logon_Type=10 OR Logon_Type=11
Logon Type NOT ( [ | inputlookup allowable_account_domains.csv | table Account_Domain ] )
Data check: This use case requires Windows security data with logon success events that contain the Account_Domain
.
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 ( Logon_Type=2 OR Logon_Type=10 OR Logon_Type=11 )
| eval Account_Domain=mvfilter(Account_Domain!="-")
| table _time user Account_Domain, Authentication_Package, EventCode, Key_Length, Logon_Process, Logon_Type, 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=*
becomes 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.