All Apps and Add-ons

Example of how to detect when local credentials are used to log into endpoints?

Ultra Champion

Does anyone have examples of how to use Splunk to detect when local credentials are used to log into endpoints?

0 Karma
1 Solution

Ultra Champion

The Splunk Product Best Practices team helped produce this response. Read more about use case examples Splunk® Platform Use Cases on Splunk Docs.

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.

Load data

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

In more complex environments such as those with many subsidiaries, or services routinely logging in with local accounts, run the following search over a longer period and create a lookup to tune out your noise:
index=* daysago=60 source=*win*security
| top limit=0 AccountDomain
| fields AccountDomain
| outputlookup allowable
accountdomains.csv

Then run a correlation search that accesses that lookup by replacing the existing list of account domains:
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 Account_Domain.

Get insights

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 Account
Domain=mvfilter(AccountDomain!="-")
| table _time user Account
Domain, 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=* 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.

Help

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.

View solution in original post

Ultra Champion

The Splunk Product Best Practices team helped produce this response. Read more about use case examples Splunk® Platform Use Cases on Splunk Docs.

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.

Load data

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

In more complex environments such as those with many subsidiaries, or services routinely logging in with local accounts, run the following search over a longer period and create a lookup to tune out your noise:
index=* daysago=60 source=*win*security
| top limit=0 AccountDomain
| fields AccountDomain
| outputlookup allowable
accountdomains.csv

Then run a correlation search that accesses that lookup by replacing the existing list of account domains:
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 Account_Domain.

Get insights

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 Account
Domain=mvfilter(AccountDomain!="-")
| table _time user Account
Domain, 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=* 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.

Help

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.

View solution in original post