Skip to main content
Splunk Lantern

Windows Zombie account lockouts

You might need to track down the source of a Zombie account lockout when doing the following:

Prerequisites 

In order to execute this procedure in your environment, the following data, services, or apps are required:

Example

Zombie account lockouts in Windows environments typically happen in two scenarios:

  1. A disconnected RDP session logged in with an account whose password has been changed. 
  2. A service account password has been changed while a service is still using the old password. 

You need an efficient way to track down where the lockout is being generated.

To optimize the search shown below, you should specify an index and a time range. 

  1. Verify that you deployed the add-on to the search heads and Splunk Universal Forwarders on the monitored systems. For more information, see About installing Splunk add-ons.
  2. Run the following search: 
source="WinEventLog:Security" (EventCode=540 OR EventCode=4624) NOT (user=*$ OR user="ANONYMOUS LOGON" OR user=SYSTEM OR user=services OR user=Unknown) 
[search index="wineventlog" EventCode=4740 NOT (user=*$ OR user="ANONYMOUS LOGON" OR user=SYSTEM OR user=services OR user=Unknown) 
|fields user] 
|stats dc(src_ip) AS Number_logged_hosts, values(src_ip) AS "Logins IPs", values(dvc) AS "Logon Host", count BY user 
|rename user AS Users, count AS Total_times_logged_in 
|where Number_logged_hosts>1 
|sort -Number_logged_hosts Users 

Search explanation

The table provides an explanation of what each part of this search achieves. You can adjust this query based on the specifics of your environment.

Splunk Search Explanation

source="WinEventLog:Security"

Search only Windows event logs.

(EventCode=540 OR EventCode=4624) NOT (user=*$ OR user="ANONYMOUS LOGON" OR user=SYSTEM OR user=services OR user=Unknown)

Return successful network or local computer logon events that are not any of the account types shown in parentheses.

[search index="wineventlog" EventCode=4740 NOT (user=*$ OR user="ANONYMOUS LOGON" OR user=SYSTEM OR user=services OR user=Unknown) 

|fields user] 

Search for locked out user accounts that are not any of the account types shown in parentheses. Reduce the result to the single field “users” which is used by the outer search. The combined inner and outer search finds all accounts that are logged in and that are also locked out which is the definition of a zombie. 

 

The exclusions in the parentheses could be varied depending on your environment.

|stats dc(src_ip) AS Number_logged_hosts, values(src_ip) AS "Logins IPs", values(dvc) AS "Logon Host", count BY user

Return all the places the users have logged in by their IP address and host name, as well as the number of times users logged in.

|rename user AS Users, count AS Total_times_logged_in

Rename the fields as shown for better readability.

|where Number_logged_hosts>1

Return only results where the number of times logged in was greater than 1.

|sort -Number_logged_hosts Users

Sort the results with the largest count first.

Result

The sample results in the following table show a sub-search correlation of accounts that are locked out but also logged in.  

Users Number_logged_hosts Logins IPs Logon Host Total_times_logged_in

dall_gibbs

5

172.16.120.33

208.90.214.10

65.103.125.65

66.72.53.128

80.200.173.24

dc-pla-01

ext-cas-den-01

ext-cas-san-01

12

aa_dev_user

2

172.16.120.141

31.210.180.179

dc-pla-01

ext-cas-den-01

6

pete_do

2

172.16.120.94

208.90.214.10

dc-pla-01

exch-cas-cup-01

exch-cas-den-01

exch-cas-pla-01

ext-cas-den-01

ext-cas-san-01

31

A next step would be to run this search as a scheduled report, and, after each run, have the results processed by the admin team to unlock the accounts and force the log outs if necessary. The workflow for scheduling a report is documented here

  • Was this article helpful?