Home / server / Questions / 959355
In Process
Michel de Crevoisier
Asked: 2019-03-22 08:12:19 +0800 CST

[WINDOWS]: identifying new protected accounts based on ID 4780

  • 772

As a security best practice, I would like to keep track in my Windows Active Directory domain of any new "Protected Accounts and Groups". According Microsoft, this concerns any user or group which is directly or indirectly member of those specified groups (source). To achieve such detection, I have managed to collect all Windows servers logs into my SIEM after enabled proper auditing settings.

I'm currently focus on the event ID 4780 (The ACL was set on accounts which are members of administrators groups. - source). Again, according Microsoft, " If the ACL on the principal account differs from the ACL on the AdminSDHolder object, then the ACL on the principal account is reset to match the ACL on the AdminSDHolder object and this event is generated". So each time a new user or group is marked as "protected", it should trigger this event ID.

My problem here is that this event ID is generated hourly for all my "priviliged accounts" (see image below), as defined per default by the SDProp process. This concerns all built-in groups (domain admin, schema admin, ...) but also intermediate custom groups that are not directly part of those "built-in protected groups". Since those event are generated all the time, my detection is useless. The picture below represent the amount of event ID 4780 per user or group. I have taken it from different domain to ensure that this was not an isolate behavior. default account all accounts

In addition of this, I have also been looking on:

  • AdminSDHolder: attribute is set to 1 when object is marked as "protected". By modifying the attribute value manually, I'm able to trigger the event ID 5136. However, when the change is pushed by the SDProp process, nothing is triggered. Note that proper SACL auditing were in place on the object (full object audit).
  • Domain group membership change (ID 4728/4756): already in place but the limitation are intermediate groups. For example, group "SG_Admin1" is member of "Domain admin". Ideally I would need to monitor "SG_Admin1" but because we have so many customers, not all may report to us that this group is sensitive. Therefore, we would miss that a new "domain admin" member was added if someone add a user to "SG_Admin1".
  • LDAP query for AdminSDHolder: our detection is currently based only on Windows logs and not LDAP queries

So any one else is reaching this problem ? If yes how did you fix it ? Which others solution could I use to monitor any new "protected" objects ?

windows-event-log

0 Answers