Accounts getting disbled in active directory.

Here is my situation.  Today dozens of accounts were locked by Active Directory disabling all the users PKI common access cards as a by product.

Here what I know:

Dozens of user accounts are listed as logging on to Retina Scanner appliance (a vulnerability scanner).  The loggins are passed on to the server, verifed and disabled via the same local DC.  This occurred over a period of four hours or so.  We checked the logs for jobs on the Retina server and so far can't find anything wonky in the event logs figuring the local security logs would not be useful since they are AD logons and will be on the DC.
Being that all of these accounts attempted logons to a particular subnet which is not it's normal AOR (Area of Responsibility) is strange.
WE do have logs from DC showing the attempts and subsequent locking of the accounts that targeted the particular serve but no idea why they would all to do in hat looks to be an automated fashion

Again, but any help would be appreciated.
We cannot match up any running scan jobs at the time of login attempts.
Besides why would a vulnerability scanner be the target (not the initiator) of dozens of unsuccessful logons from the same subnet?
Finally the logon attempts causng the lock outs where definitely automated as they where hapening less that a second appart.

I have no idea so far where else to look and I'm supposed to tell the boss what going on by the end of tommorow.  I'm not asking someone to do my work for me but maybe suggest other things to consider.
The more paranoid of us immediately suggested some grand AD aware piece of malware but I would rather start at something more mundane.
My only hunch is that somehow the Retina server will be culprit,not the target as the logs show because it's job is to rapidly scan swath of IP's, but again no apparent jobs where running at the time....

Sorry fore the long description but wanted you to know I'm not looking for free hand outs :-)
Who is Participating?
btanConnect With a Mentor Exec ConsultantCommented:
It sounds like the client is autonomously attempting to login (through Retina) to AD and eventually caused user account lockout. Note that user account is normally to deter any Denial Of service based attack especially in automated fashion (by innocent "bots" - client having infected by worm and trojan).
This possibility is high ...

Having said that, do note that other ways accounts can get locked out include:
    * Applications using cached credentials that are stale.
    * Stale service account passwords cached by the Service Control Manager (SCM).
    * Stale logon credentials cached by Stored User Names and Passwords in Control Panel.
    * Scheduled tasks and persistent drive mappings that have stale credentials.
    * Disconnected Terminal Service sessions that use stale credentials.
    * Failure of Active Directory replication between domain controllers.
    * Users logging into two or more computers at once and changing their password on one of them.

In order to glean as much intelligence from this lockout scenario, I will suggest checking out the Microsoft document using of their Account Lockout and Management Tools (installed typically in DC). Mainly is to sieve out more info from log (in more details with  timestamp, last reset, last change, etc) that is not be default available from the standard installation of DC.

- See

But I would like to highlight the below tool that may help to isolate and mitigate the issue::

a) The Network Monitor can be used to capture unfiltered network communication. The program or process (from Client) causing this lockout most likely (if it is malicious client) will continue to send incorrect credentials while trying to gain access to resources that are on the network.

b) Capturing all traffic to and from the client may help you determine which network resource the process is trying to gain access to. After you determine the network resource, you can determine which program or process is running on that client computer.

c) After you identify a program or service as the cause of the lockout, view the software manufacturers Web site for known resolutions. This behavior typically occurs because the program is running with the currently logged on user's credentials.

d) If a service is causing the lockout, consider creating accounts that are specifically for running services so user account password changes do not affect the services.

Adding on, do check out all the client health as well - latest patches for OS and security software like AV.....

As for Retina, better to post this queries up to the customer support portal as well - believe this may not be a unique instance, see

Hope it helps ....

In the security logs, you should be able to find the source of the lockout on the server, and in the client, you should see a Logon Type code
Logon Type Codes Revealed
have you installed antivirus , isit upto date with the virus definitions ?

do a full scan on the server
We Need Your Input!

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!


The frequent account lockout issue in a domain may occur due the downtab/conflicker worm activity on your network.Install the following patches on the computers.

2. Malicious Software Removal Tool)

After intsalling these patches restart the computer and run a full scan with Microsot Malicious Software Removal Tool using followng command

c:\windows\system32\mrt.exe /F:Y

Do the above steps on the suspected computers, you can find these computers from the account lockout logs in the security log.
SecGeekAuthor Commented:
Thank you every one for your help.  Breadtan you were very close to the what we determined to be the solution.  We always suspected that the Retina server was causing the lockouts.  The rub was that when we looked at the AD DC logs and the Retina scanner Job times.  They didn't match up.  So it messed me up for a bit.
Essentially, I was an idiot. My organization does not adhere to UTC (or any NTP) specifically.  One log was in UTC and the other was in the Retina scanners time zone. So I concluded that it might not be the scans after all and started looking elsewhere.

Once, someone pointed out that "duh"  I had a time zone issue and that the scans WERE running when the lock out began, I looked at the scan configurations and sure enough the password strength checks were on!

They had always been erroneously set as on but did not come to light until a GPO change changed account lock out time to permanent which triggered a ton of complaints.

It's fixed now.

Thanks again.
SecGeekAuthor Commented:
Very good advice. We came to the solution slightly differently but would have found it through breadtan's solution.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.