Detect Many Unauthorized Access Attempts

Description

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.


Use Case

Insider Threat

Category

Insider Threat

Security Impact

In most organizations, it's rare for a user to get an unauthorized message, beyond low risk scenarios such as proxy logs. When this is occurring for higher risk activities such as system logins, file share access, etc., and when it occurs persistently for a user, there's usually reason to investigate.

Alert Volume

Low (?)

SPL Difficulty

Medium

Journey

Stage 1

MITRE ATT&CK Tactics

Credential Access

MITRE ATT&CK Techniques

Brute Force

MITRE Threat Groups

APT3
APT33
APT41
Dragonfly 2.0
Lazarus Group
Leafminer
OilRig
Turla

Data Sources

Windows Security
Authentication

   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.

   Help

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

Demo Data

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.

Live Data

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