Windows password reset/creation: Will you help me create a search that returns Event "A" and NOT Event "B" within a given period of time?

[utsav45]

Hi All,

We've set up an alert to flag AD Service account passwords are reset. Below is the alert condition:

index=winevents sourcetype="WinEventLog:Security" EventCode=4724 OR EventCode=627 OR EventCode=628 OR EventCode=4723 user="_s*"
| fields _time member_id user EventCode EventCodeDescription Message
| eval intelSubject="ad_service_account_password_reset " + member_id
| eval intelSource="Security Monitoring"
| rename member_id AS "Actioning User" user AS "Target User"
| table _time intelSubject intelSource "Actioning User" "Target User" EventCode EventCodeDescription Message

However, we're seeing a lot of false positives. When new service accounts are created, we see the subsequent password reset event.

Hence, we would like to tune the alert in such a way that service account password reset should only get triggered if the same user account hasn't been created within last hour of the password reset event.

I've tried to use options listed out in below thread but no joy.

https://answers.splunk.com/answers/38318/search-for-event-a-and-not-event-b-within-a-given-period-of...

Any pointers or help much appreciated!!

Thanks

[utsav45 · Accepted solution]

I believe below query seems to be serving my purpose. Can someone please validate if it's as per best practice and not resource intensive?

index=winevents sourcetype="WinEventLog:Security" EventCode=4724 OR EventCode=627 OR EventCode=628 OR EventCode=4723 user="_s*" NOT [search sourcetype="WinEventLog:Security" EventCode=4720 OR EventCode=624 user="_s*" | fields user]

Thanks

[vupham]

You're on the right track there. The issue I see with that is that if you were looking over a 1hr period for recent account creations, the password reset events at the beginning of your window might cause false positives due to account creations possibly being outside your search time range. You could address this by specifying a different time range inside your subsearch.

so assuming your normal search window is -1h to now, you can try
index=winevents sourcetype="WinEventLog:Security" EventCode=4724 OR EventCode=627 OR EventCode=628 OR EventCode=4723 user="_s*" NOT [search sourcetype="WinEventLog:Security" EventCode=4720 OR EventCode=624 user="_s*" earliest=-2h | fields user]

[utsav45]

Hi @vupham,

Yeah that makes sense. I will definitely consider your suggestion.

Thanks a lot.

[vupham]

For a better idea on how to attack your problem, what is the schedule frequency and time window of the search?

One way to address this is to have a lookup table of your service accounts (or ideally for security monitoring, all accounts) that has the user account creation date available. When the lookup matches the account id, the event will be enriched with the account creation date. Then you can do a simple eval to get the time difference for filtering. This should work as long as that lookup table is being updated more frequently than your alert's scheduled search interval.
The Splunk add-on for active directory has an ldapsearch command that can help you build this table http://docs.splunk.com/Documentation/SA-LdapSearch/2.1.7/User/Theldapsearchcommand#Examples
The example given is formatted for ingestion into Splunk Enterprise Security's Identity Management, but you could tweak it to your needs.

If you're working with tighter tolerances than the lookup option allows (like a real-time search) or insist on having it done in a single search, you could include the account creation events in your base search. Then use eventstats split by account to get your account creation info fields into the password reset events. The downside of this approach is that depending on the amount of events you're dealing with and how big the time window is, it could take a long time to run and maybe even hit time and resource limits.

And if that proves to be not a good fit, there's the option of an external script lookup to fetch the account creation time property straight out of AD.