Successful Login of Account for Former Employee

Description

You shouldn't see any successful authentication activity on the accounts of former employees. Track this easily in Splunk.


Use Case

Security Monitoring, Insider Threat

Category

Account Compromise, Insider Threat

Security Impact

Users who have left your organization should generally not be logging in. It could mean that their credentials were compromised earlier, or it could mean that they are trying to log in to take some inappropriate actions. Either way, this is something you want to detect.

Alert Volume

Low (?)

SPL Difficulty

Basic

Journey

Stage 4

MITRE ATT&CK Tactics

Privilege Escalation
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

Kill Chain Phases

Actions on Objectives

Data Sources

Windows Security
Authentication

   How to Implement

If you have followed the data onboarding guides in this app, this search will work immediately for you. You should generally specify the index where you are storing Windows Security logs (e.g., index=oswinsec), and if you use a mechanism other than the Splunk Universal Forwarder to onboard that data, you should verify the sourcetype and fields that are used. The rest is simple!

   Known False Positives

If your organization doesn't actually disable or remove accounts, then this search may not be actionable. If this is you, consider creating some boundaries around this behavior by specifying systems that "acceptable" post-termination activity can be expected on, such as the email environment. Also put a detective control in place to ensure that passwords are changed when an employee goes from active to not, and try to limit the usage of accounts after the employee leaves.

   How To Respond

The first thing to understand after this alert fires is whether this was some continuation of normal system operations (e.g., the desktop under their desk was still logged in, or iPhone account still active) versus a deliberate action. Obviously success or failure also carries weight. Finally, particularly for sysadmin type employees in less structured organizations, it's important to make sure that there are no services or scheduled jobs running under that account where disabling the account outright might impact operations.

   Help

Successful Login of Account for Former Employee Help

This example leverages the Simple Search search assistant. Our example dataset is a collection of anonymized Windows Authentication logs (onboarded in accordance with our Data Onboarding Guides), during which someone does something bad. Our live search looks for the same behavior using the standard sourcetypes.

SPL for Successful Login of Account for Former Employee

Demo Data

First we bring in our basic demo dataset. In this case, showing Interactive Logins. We're using a macro called Load_Sample_Log_Data to wrap around | inputlookup, just so it is cleaner for the demo data.
Next we check a lookup that shows the user status (this would typically be pulled from SA-ldapsearch or ADMon).
Now we can filter for users where the expiration is at least a day ago (timezones are hard), or that are disabled.

Live Data

First we bring in our basic dataset. In this case, successful logins.
Next we check a lookup that shows the user status (this would typically be pulled from SA-ldapsearch or ADMon).
Now we can filter for users where the expiration is at least a day ago (timezones are hard), or that are disabled.

Screenshot of Demo Data