User Login with Local Credentials

Description

Categorically, most interactive logins should use domain credentials. Detect when a new user logs on with local credentials that bypass most centralized logging and policy systems, but not Splunk!


Use Case

Insider Threat, Security Monitoring

Category

Insider Threat, Privilege Escalation, Endpoint Compromise, Account Compromise

Security Impact

Local credentials enable a user (or attacker) to bypass some auditing controls, and persist access effectively. There are many different approaches to this problem, including logging the creation of local accounts.

Alert Volume

High (?)

SPL Difficulty

Basic

Journey

Stage 1

MITRE ATT&CK Tactics

Privilege Escalation
Initial Access
Credential Access

MITRE ATT&CK Techniques

Valid Accounts
Account Manipulation

MITRE Threat Groups

APT18
APT28
APT3
APT32
APT33
APT39
APT41
Carbanak
Dragonfly 2.0
FIN10
FIN4
FIN5
FIN6
FIN8
Lazarus Group
Leviathan
Magic Hound
Night Dragon
OilRig
PittyTiger
Soft Cell
Stolen Pencil
Suckfly
TEMP.Veles
Threat Group-1314
Threat Group-3390
menuPass

Data Sources

Windows Security

   How to Implement

Implementing this search is as tricky as your environment is complex. For smaller shops with minimal complexity, run a Splunk search to look at the expected domains, and add them to your explicit whitelist:

index=* daysago=7 source=*win*security | top Account_Domain limit=0
. In more complex environments (such as with many subsidiaries, or services routinely logging in with local accounts), you may wish to run this over a long period of time and create a lookup to tune out your noise. Create the lookup with
index=* daysago=60 source=*win*security | top Account_Domain limit=0 | fields Account_Domain | outputlookup allowable_account_domains.csv
Then in your correlation search, access that lookup by replacing the existing list of account domains so that it reads:
index=* source=*win*security tag=authentication action=success Logon_Type=2 OR Logon_Type=10 OR Logon_Type=11 Logon Type NOT ( [ | inputlookup allowable_account_domains.csv | table Account_Domain ] )

   Known False Positives

Many service accounts will log in with local domains as a matter of normal activities, and computer accounts may also show up. 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 etc. Verify whether this is a service account that should be added to the tuning whitelist moving forward.

   Help

User Login with Local Credentials Help

This example leverages the Simple Search assistant. Our dataset is an anonymized collection of Windows Authentication logs. For this analysis, we are looking at what domains we expect to see in our authentication logs, and alert on anything unexpected.

SPL for User Login with Local Credentials

Demo Data

First we bring in our basic demo dataset. This dataset includes interactive logins from Windows Security logs. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data. If you're paying close attention, you'll notice that the dataset here is called Legacy Pass the Hash. The reason? The legacy (and not really relvant) pass the hash detection actually resembles this detection, where we are looking for unexpected Account_Domains.
Next we filter out the domains that we are expecting to see. Controversially, we are also ignoring accounts that end in a dollar sign, which will typically occur from server accounts. This is a problematic assumption, as there's nothing to keep attackers from using dollar sign usernames for their own purposes -- as you mature this detection, try to move away from this limitation.
Next we use eval to filter out the Account_Domain of "-" as Windows will typically include blank domains in one of the log fields, and we don't want to distract analysts. We aren't putting this in the prior search command because we don't want to exclude those events, we just want to strip that value from the field.

Live Data

First we bring in our basic dataset. This dataset includes successful interactive logins (logon type 2, 10, 11) from Windows Security logs where we filter out the domains that we are expecting to see. Controversially, we are also ignoring accounts that end in a dollar sign, which will typically occur from server accounts. This is a problematic assumption, as there's nothing to keep attackers from using dollar sign usernames for their own purposes -- as you mature this detection, try to move away from this limitation.
Next we use eval to filter out the Account_Domain of "-" as Windows will typically include blank domains in one of the log fields, and we don't want to distract analysts. We aren't putting this in the prior search command because we don't want to exclude those events, we just want to strip that value from the field.
Finally we put it in a table to make it easy to read

Screenshot of Demo Data