Currently, in our SIEM environment, we are attempting to reduce noise and any non-actionable items. One of the most frequent items we receive on a weekly basis is a report based on excessive member and server authentication failures.

The overall concept is to inform us of any accounts that consistently fail authentication on a host over a 24hr period, where no successful events are seen within the same 24hr period. We often determine the type of failure based on the event code that it is producing as well as the signature/signature ID.

Our standard process is to contact the account or server owner and have he/she investigate what is causing the excessive failures. This process can be rather lengthy and time-consuming and is dependent on analyst communication to the account owner. I'd say 95% of these alerts are not actionable or they are closed after a follow-up SIEM search.

To avoid a possible brute force attack we do monitor these logs. My question is; is there an additional layer of filtering or rules that be tweaked to reduce these logs.

Common Event Codes:


Also is there perhaps a different process that can be utilized for monitoring and reporting such excessive accounts. At, the moment we need to create a new tracking ticket for each and every account that meets our current standard and/or threshold.

Through analysis, I would believe that if an analyst can determine if the failure is indeed a brute-force is actionable than we would then complete the required steps. Otherwise, these excessive failures can be reviewed and forwarded to the respected account owner as needed.

Any thoughts on the matter? Thank you!

  • You could send an email to the effected user after the invalid attempts pass the threshold, but before the 24 hour window has passed. The email would say something like "We noticed you are having issues logging in, for your security please check your password and login again within 24 hours, or we will flag your account for manual review". That way if they actually need password help they will call and get it sorted then, and this will reduce your false positives, otherwise they will be expecting the call after the 24 hours passed. You may also want to ID repeat offenders. – Daisetsu Oct 14 '18 at 17:43
  • cont. Also, if it is indeed malicious, and they get an email like that, they will probably call YOU immediately telling you it's not them. – Daisetsu Oct 14 '18 at 17:45

It is true, as you said, that both event IDs can be very noisy (especially ID 4625). However the way how to handle those event can be, from my experience, improved with the following suggestions.

On the first hand, and if your aim is to improve your process, I would suggest to review the way you group and manage those events in your SIEM (whatever it is). Actually, analyzing each event as a single event can turn out into a waste of time and total loss of visibility. What would be interesting is that you group events and count (with thresholds) for example the amount of time that a source IP, a user or a target is seen during a failed login attempt. This can be done creating some advanced brutforce rules/scenarios/use case. Below I provide you a concept that I have done and that I have implemented. On the left you have the different parameters than can be adjusted and on which you should group over or not. Risk means the criticality level of the scenarios when you alert and thresholds the variable you should adjust for the scenario/use case.

ID 4625 brutforce scenarios

You will notice that I don't group over the error code. This is because I consider that an attacker can produced different results during a brutforce attack. However, you can still build specific use cases for specific errors (lock-out, disabled, expired, un-existing accounts ...).

On the other hand, if your aim is also to reduce the amount of those events, I can suggest the following actions:

  • Increase priority on failed login attempts on specific assets (sensitive servers, DMZ servers, databases, domain controllers, PKI, ...)
  • Focus on failed logins on sensitive accounts (eg: service or admin accounts)
  • Ignore lock out failures on user accounts until they remain under your lock out policy thresholds
  • Correlate failure events (ID 4625 and 4776) with the events produced on the source machine (ID 4648). This may allow to detect Pth or lateral movement attacks. You can use the following table of failure/success events to make the link between source and target and enrich your output for your analyst.

enter image description here

  • Correlate failure events IDs 4625 with Kerberos events (ID 4771, 4768) to enrich the results that the analyst will need to check

  • Ignore some specific error codes into your main use cases BUT make out of it a new use cases with lower priority. You will check those incidents later. As an input, I can provide you the following extract of error codes for 4625 to filter out what you need:

enter image description here

So I hope this bunch of information will help you. But keep in mind, correlation in the key to reduce load, false positive and increase visibility.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.