SPL Nuggets: Know your admins – from eventlogs!

In case your threat hunters are idling around, here’s the first post from the “SPL Nuggets” series to the rescue! Without further explaining why it is extremely important to track user accounts in your environment, let’s start “Siri” style:

Splunk, give me all potential local admin accounts you can see based on ingested eventlogs!

For that, we are going to leverage the super-amazing Boss of the SOC (BOTS) dataset from Splunk. In case you haven’t heard about the CTF/Game and the dataset itself, do yourself a favor and check it out here.

While there must be many other ways to do it, the following query is very handy in case your audit policy enforces successful authentication (4624) and new process creation (4688) events logging.

And below is the output with filters* applied:

The field hosts holds the hostnames where the user (account) potentially has admin privileges. That’s possible due to the “elevated token” info available from those eventlogs. Besides being less intrusive, this approach may reveal other potential use cases upon understanding what those events are about and how important they are.

For instance, you could systematically match those accounts against an external IAM system or even against Splunk’s identity lookup, tracking unexpected ones. Same goes for generic or service accounts (usually running svchost/services.exe). Ultimately, every single new instance can be tracked via a notable event (alert).

Still eager for more?

The following event codes are also eligible to track potential local admin and other suspicious accounts but require a more in-depth write-up or analysis, so please consider adding to your research:

  • 4648: A logon was attempted using explicit credentials
  • 4722: A user account was enabled
  • 4673: A privileged service was called

The quick hint is checking whether the host field value is equal to the domain field value likely not related to a domain account:

| where lower(host)=lower(domain)

* Filters

If you are paranoid (sometimes we need to be), remove the following from the base query in order to avoid filtering out likely default cases:

  Account_Name="system" OR 
  (Account_Name="dwm-*" Process_Name="c:\\windows\\system32\\winlogon.exe") OR
  (Security_ID IN ("* service","nt *","iis *") Process_Name IN ("c:\\windows\\system32\\services.exe","c:\\windows\\system32\\svchost.exe"))

The SPL code from the screenshot can be copied from here. Have fun!