Detect Many Unauthorized Access Attempts
Most login failures are due to failed passwords. Login failure to sensitive systems where the users simply aren't authorized, though, can indicate malicious intent. Detect that.
How to Implement
Implementation of this should be easy -- just ensure that you have data being ingested from the Universal Forwarder and the Splunk Technology Add-on present, and all will work automatically.
Known False Positives
The most likely scenario where this detection indicates a false positive is where the user's access has simply been messed up. There was an AD group change last night, and this user was accidentally removed from the "dev_system_access" security group. Beyond that, there's no standard pattern that would be expected for false positives.
How To Respond
When this alert fires, investigative steps you could take are to evaluate whether this user has previously had access to the desired resources, look for recent job role changes, and look for recent changes around AD groups. In most organizations, the next escalation step would be to consult the owner of the desired resources, and/or the user's manager, to determine whether this behavior is intended. Keep an eye out for indications of malicious intent alongside potential account compromise.
Detect Many Unauthorized Access Attempts Help
This example leverages the simple search assistant. Our dataset is an anonymized collection of Windows Security logs. For this analysis, we are looking specifically for the event logs that indicate a user authenticated successfully but was not authorized (i.e., correct username and password, but not permitted to log into this system). We're looking for any user with many of these per day, that can indicate attempted access to sensitive resources.
SPL for Detect Many Unauthorized Access Attempts
| `Load_Sample_Log_Data(Windows Logons with Failure Codes)` | search Failure_Reason=* Status=0xC000015B
|First we bring in our basic demo dataset. In this case, a list of anonymized Windows logon events. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.|
index=* source="*WinEventLog:Security" user=* EventCode=* action=failure Logon_Type=* Failure Reason Logon Type Status=0xC000015B
|We're bringing in our Windows security logs, looking specifically for the status code 0xC000015B which indicates that the user hasn't been granted the requested logon type (aka, logon right). You may note that we use the bare words failure, reason, logon, and type. These words are found in the raw event, which will help Splunk focus just to in-scope fields. Probably the 0xC000015B is enough to suffice here, but why not be complete.|
Screenshot of Demo Data