How to prevent your SIEM from being blind

Getting log files from multiple systems requires additional actions such as correct permissions, appropriate network settings, proper resources allocations, and KeepAlive alerts.


But what happens if something goes wrong? Apparently, the log files will not arrive.

We will focus on a problem that can cause peripheral blindness with minimal effort:

Disable SIEM service account

As an adversary, the first action I would take is to disrupt the SIEM functioning.

One simple way is to make the SIEM blind by locking the SIEM service account. Doing this is very simple: after a few failed logins the SIEM account is locked, and from now on,   the SIEM (on the SOC) will become blind.

There is a high chance (especially when the brute-force is directed to the DC) that the event of User locked (and likely, the failed login that causes the account to be locked) will not arrive at the SIEM because the user will be locked before the record is created and pulled/pushed to the SIEM.

Unless you have an excellent KeepAlive system, you will not be able to get an alert when it happens.

To get over this, our recommendations are:

Account Name Camouflage:

  • In most cases, user account names imply being associated with SIEM (i.e. svc_siem)

  • Make it difficult to identify the SIEM account.

Improve lock policy:

  • All the SIEM Accounts should be under GPO with Account lockout threshold of 999, or never unlocked. If unlocked then  rapid action is required from the response team, or implement automatic response

  • Create specific UseCase in the SIEM for brute force only for SIEM accounts with priority 10 and with a threshold of 100 (with a reason that is different from user locked)

  • Event log permissions. The SIEM Accounts for reading events from the event log will have permission only to read the event logs. Exposing the password to this service account will reveal only the event logs from the server, without the option to do anything else.

  • Policy to unlock the user after 5-10 minutes only to the SIEM account. That way, there is a very good chance to receive the ‘lock’ event within 5-10 min, assuming that guessing a password 5 times every 5-10 min is impossible.

Separation of accounts:

Use different accounts for reading events from DC and for other needs such as folders, and databases.

Dual monitoring:

  • Create additional connector with different account to read DC’s events but filter out all events except the SIEM account activities. In such a case you will get the alert for one of them, unless both accounts will be locked at the same time.

Specific Use Cases for SIEM Account:

  • Develop rules based on internal audits and keep alive those that can indicate a problem with the user.

  • Have the time to get alert for brute force to SIEM accounts and to find the source fast.

  • Earn time without being blind.


By creating a special policy, monitoring and use cases, you can reduce dramatically the chance for losing important logs that can alert you on security incidents.

The risk of increasing the threshold to 1000 will not change ,as there is a way to guess the password within 1000 times with the complexity policy that you have. Once again, the risk is only in the event’s log data.

Risk Management: (Being blind) Vs. (999 attempts guessing a complex password)

For any further questions and information do not hesitate to contact us.

Share This Story, Choose Your Platform