Leave us a Message:

How to prevent your SIEM from being blind

Share on facebook
Share on linkedin
Share on twitter
Share on whatsapp
Share on email

How to prevent your SIEM from being blind

Getting logs from multiple systems also requires correct permissions, network settings, proper resources, and perfect KeepAlive alerts.

But what happens if something goes wrong? Apparently, the logs 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 of the simple ways to do it is to make the SIEM blind by locking the SIEM service account. The way to do this is very simple: A few failed logins and the SIEM account is locked, so from now on, the SIEM (on the SOC) will be 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 won’t 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.

Lock policy:

  • All the SIEM Accounts will be under GPO with Account lockout threshold of 999 (or never unlocked – but need a speedy response team, or automation 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)
  • The SIEM Accounts for reading events from the event log will have permission only to read the event logs. So exposing the password to this service account will reveal only the event logs from the server without the option to do anything else.
  • Policy (only for the SIEM account) to unlock the user after 5-10 min. That way, there’s a very good chance we will get the ‘lock’ event within 5-10 min. (Guessing a password 5 times every 5-10 min is impossible)

Separation of accounts:

Use different accounts for reading events from DC and other needs (e.g., folders, DB, etc)

Dual monitoring:

  • Create one more connector with another account to read DC’s events but filter out all events besides the SIEM account activities.
  • Unless both accounts will be locked at the same time, you will get the alert for one of them.

Use Cases specific 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.
  • Buy time without being blind.

Conclusions: 

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

The risk of increasing the threshold to 1000 will not change. (No way to guess the password within 1000 times with the complexity policy that you have). Once again, the risk is only in the events log data.

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

For any further questions and information don’t hesitate to contact us.

Share this post

Share on facebook
Share on linkedin
Share on twitter
Share on whatsapp
Share on email
Eli Benitah

Eli Benitah

Leave a Reply

About Us

We increase the security of organizational information and anticipate threats before they cause damage, and improve the level of protection of organizational information, by providing end-to-end SIEM solution.

Recent Posts

Skip to content