Example of how to detect new authentication against a domain controller?

[adukes_splunk]

Does anyone have examples of how to use Splunk to detect new authentication against a domain controller?

[adukes_splunk · Accepted solution]

The Splunk Product Best Practices team provided this response. Read more about How Crowdsourcing is Shaping the Future of Splunk Best Practices.

After an attacker gains access to a network through a compromised asset or credential, the attacker will move laterally in the network to target critical infrastructure. Domain controllers provide the physical storage for the Active Directory Domain Services (AD DS) database. In addition, they provide the services and data that allow enterprises to effectively manage endpoints such as servers and workstations, users, and applications. If a malicious user obtains privileged access to a domain controller, they can modify, corrupt, or destroy the AD DS database and all systems and accounts managed by Active Directory. Monitor both successful and unsuccessful authentication attempts to detect anomalies such as time of day, frequency and other suspicious patters that might indicate compromised assets or credentials.

This use case is from the Splunk Security Essentials app. Check it out for more examples and demo data for this type of use case.

Load data

This use case depends on the security data from Windows domain controllers.

Best practice: Use the Splunk Add-on for Microsoft Windows to accelerate time to value time to value with Windows data. For details, see Is it a best practice to use the Splunk Add-on for Microsoft Windows? on Splunk Answers.

1. Enable the [WinEventLog://Security] input in the add-on to collect Windows security data. For details, see our post How do I collect basic Windows OS Event Log data from my Windows systems? on Splunk Answers.
2. Deploy the add-on to the search heads to use the Common Information Model to normalize the data at search time. See Install the Splunk Add-on for Windows in Splunk documents for the procedure.
3. Run the following search to verify you are collecting Windows data: earliest=-1day index=* source=win*security 4776 EventCode=4776 | head 10

Get insights

A common indicator for lateral movement is when a user starts logging into new domain controllers. Use the following search for context or to aggregate risk.

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.

index=* source=win*security 4776 EventCode=4776
| rename ComputerName as DomainControllerName
| table _time DomainControllerName user

Known false positives: This is a behavioral search, so the definition for false positive is slightly differently from traditional searches. Every time this fires, it reflects the first occurrence in the time period you're currently searching. While there are no false positives in a traditional sense, there is lots of noise.

How to respond: When this search returns values, initiate the incident response process and identify the user account accessing the specific domain controller. Contact the user and system owner about the action. If the access is authorized, document that this is authorized and by whom. If not, it's possible that another person used the user credentials and more investigation is warranted to determine that lateral movement is not occurring.

If no results appear, you may need to deploy the Splunk Add-on for Microsoft Windows to the search heads to use the knowledge objects necessary for simple searching.