3

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 ?

Michel de Crevoisier
  • 571
  • 4
  • 9
  • How is this a problem? This is expected behavior and completely normal. – Greg Askew Mar 21 '19 at 16:21
  • Well problem is that this is happening all the time and it should not (from my understanding). Microsoft says " 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". Since there is no "diff" between the ACL, no event should trigger. From my understanding, this should only happend each time a new "protected" account is detected. Is that correct ? – Michel de Crevoisier Mar 21 '19 at 17:39
  • You may want to include the Windows version of the PDCE DC, and the domain functional level. – Greg Askew Mar 21 '19 at 18:28
  • 1
    PDCE: 2012 R2, DFL: 2012 R2, DC OS: Server 2012 R2 – However, and as you may see on the picture above, some accounts (eg: schema admins) were not triggering the event for some time. And this point remains unclear to me. – Michel de Crevoisier Mar 22 '19 at 14:10
  • Why don't you just enumerate all user accounts in AD that have the **adminCount** attribute set? While you'll likely get some false positives (since that attribute is not removed once it's set), it's IMHO a good way to find administrative user accounts. That attribute is set on group as well BTW. – Lucky Luke Mar 22 '19 at 14:38
  • After SDProp runs, do the accounts show that the security descriptor was modified? You can use `repadmin /showobjmeta DCName "[AccountDN]"` to view the attributes that changed. nTSecurityDescriptor would be the attribute. – Greg Askew Mar 22 '19 at 15:37
  • 1
    Thanks for the feedback. But our current limitation is that we do not have LDAP access for security reasons. So we have to rely on the security logs instead. PS: I have also found the following PowerShell script which is doing a quiet good output regarding the AdminSDholder attribute. https://gallery.technet.microsoft.com/Reset-AD-adminCount-195bf65e – Michel de Crevoisier Mar 24 '19 at 22:01

0 Answers0