`

ACTIVE DIRECTORY SECURITY VERIFICATION STANDARD

Author: Huy Kha

Title: ADSVF – Active Directory Security Verification Standard
Contact: [email protected]

<<DMS.DocIdFormat>>
TABLE OF CONTENT

 Introduction
 Requirements for financial institutions & government agencies
 Acknowledgements
 Example of ACL abuse

 Verify that the AD Root has not been modified

 Verify the ownership of all OU's
 Verify who can modify OU's
 Verify who can take-over multiple accounts
 Verify who can take-over ADM accounts
 Verify who can modify AD groups
 Verify who can enable Unconstrained Kerberos Delegation
 Verify who can make any changes to the SCHEMA
 Verify the AdminSDHolder is clean
 Verify the dsHeursitics has not been modified
 Verify sIDHistory has been removed after migration
 Verify SID Filtering is enabled
 Verify no unauthorized users added to the DNS server object
 Verify the ownership of GPO's and who can modify those
 Verify that Account Operators, Print Operators and Server Operators are empty
 Microsoft recommends not having more than four Global Admins for Azure, so let's do the
same for AD. Not more than four Domain Admins.
 Ensure that only Domain Controllers are part of the Domain Controllers group.
 Ensure Domain Controller settings has been changed
 Ensure User Right Assignment on workstations has been changed
 LOCAL Backup Operators needs to be empty on workstations
 Verify which users have insecure parameters
 Verify which users can link an (arbitrary) GPO

 Other Best practices

 (Enterprise) Key Admins

 Deploy Microsoft ESAE Model

 Local Users and Groups

<<DMS.DocIdFormat>>
INTRODUCTION
Before you implement all this stuff randomly. Please read the entire document first, before you are
doing anything. Yes, there is not so much text, but more images. Which should help you.

ADSVF was developed to have a minimum level of requirements for mature organizations, such
as government agencies and financial institutions. Well, everybody is allowed to use it, but this is
mainly focused for the mature organizations, because they have the resources and people to realize
this goal.

Government agencies and financial institutions are the ones that protect the most sensitive data, so
clients could expect a high-level of maturity in terms of (AD) security.

This documentation helps you to audit your Active Directory with in-depth recommendations
what to do, rather than just pointing out what is wrong or those ''annoying'' recommendations you
often get, with the likes of. ''Just'' implement X or Y, and your safe.

There are a few examples of common misconfiguration, tweaking default settings, and deploying
best practices of Microsoft. Which in my opinion every government or financial institutions
should follow.

ADSVF is inspired from the OWASP AVS framework that can be found here:
https://www.owasp.org/images/6/67/OWASPApplicationSecurityVerificationStand-
ard3.0.pdf

Like OWASP AVS. It should be easy to understand for system administrators what they should do
and look for.

I do not claim that I have covered everything in this documentation, but at least. I have tried to add
as much as valuable information as I can. I hope that it is helpful to you.

<<DMS.DocIdFormat>>
REQUIREMENTS
There are a few minimum requirements that all mature organizations should follow and that is the
following:

Banks & Government agencies have the resources to accomplish this goal, so this is what we
''minimum'' should expect from government agencies and banks.

- Periodically scan of all OU's and the different permissions that has been set on it.
- Periodically scans of all users and groups to look for permission that has been set on it,
which you might discover escalation paths.
- Periodically scan of all Domain Admins, Enterprise Admins, Administrators etc. All the
high-privileged groups needs to be limited and strictly monitored.
- No service accounts or accounts with SPN's should be Domain Admin and so one.
- Built-in groups with the likes of Account Operators, Server Operators and Print Operators
should NOT be used and needs to be EMPTY
- Periodically scans for Local Admins on workstations, servers etc. Reduce them, if not
needed.
- Periodically scans on all GPO's and who are allowed to modify those settings
- Periodically scans on all Computer Objects and why users or groups have ''Full control'' on
those?
- Periodically resetting the password of the KRBTGT twice
- Microsoft LAPS needs to be deployed on all workstations across the network.
- Built-in Administrator needs to be disabled and logon restriction needs to be set on denied
- Microsoft Red Forest needs to be implemented
- Detection mechanism Microsoft AzureATP / Alsid or similar should be in place to detect
malicious behaviour in AD.

<<DMS.DocIdFormat>>
1. Here we can see that we have only three Domain Admins.

2. Here we can see that Helpdesk has ''GenericWrite'' on Domain Admins.

<<DMS.DocIdFormat>>
3. Helpdesk contains 5 members

4. ServerAdmins has GenericAll on Arjen in Helpdesk

<<DMS.DocIdFormat>>
5. ServerAdmins contains 5 members as well.

6. Support Engineers has WriteDacl on ServerAdmins

<<DMS.DocIdFormat>>
7. Support Engineers contains 3 members

8. Technical Support is the owner of Support Engineers

<<DMS.DocIdFormat>>
9. Technical Support contains 4 members.

10. 3+5+5+3+4 = 20 Domain Admins

<<DMS.DocIdFormat>>
 Verify if the AD Root has been modified
Verify that the AD Root is clean and no unauthorized users or groups are added to it with
(insecure) delegated permissions.

 AD Root

 Ensure that only Domain Admins, Enterprise Admins, Administrators, have the
high-privileges on this object. Exchange Trusted Subsystem has Modify permission, and
that is a finding. This is by default in Exchange 2010.

<<DMS.DocIdFormat>>
 Ensure that Administrators is the owner of the object.
Here we are able to see that Ben Smith has ownership on the AD Root and that is a
finding.

 Ensure that no users have been added to the DACL

Since here, we are able to see that Paul West has for no reasons ''Full control'' on the AD
Root. This is a finding

<<DMS.DocIdFormat>>
 Ensure that no one has the ''Update Password is not required bit'', because otherwise they
can reset their password to <empty> and authenticate without password. This is a finding

 Ensure that no users or groups have the following permissions, except if you have Azure
AD Connect. Otherwise, this is a finding.

<<DMS.DocIdFormat>>
 Ensure that no group has been added to the AD Object with ''Full control'' – This happened
in the past, where Microsoft allowed Enterprise Key Admins to have ''Full control''
permission on the AD Root. This is a finding if you have a random group with those
permissions.

<<DMS.DocIdFormat>>
 Verify the ownership of the OU
All those folders are called Organizational Units or known as an ''OU''
In those OU's, different objects are stored in, such as users, groups and computers.

Here we can see that the OU ''Builtin'' has different groups stored in it. If a user wants to be able
to control all those groups in once, you can delegate permissions on an OU. So he or she has the
privileges to do so. But this can be a risk if you delegate more permissions than needed!

<<DMS.DocIdFormat>>
 Ensure that are aware of who has the ownership of all your OU's, especially on the critical
OU's, where you store groups with high-privileges in the domain.

Here we can see that Alice has for no reasons the ''Modify owner'' permission on the OU
''Builtin'' and can take ownership of it. Which then means, she is able to modify most
groups in that OU. This is a finding

 Ensure that Administrators or Domain Admins are the owner of all the OU's
Here we can see that Alice took ownership of the OU Builtin. This is a finding

<<DMS.DocIdFormat>>
 Verify who can modify OU's

Here we can see the OU ''Users'' that contains different groups.

 Ensure that you aware of who has delegated permissions on certain OU's, because in this
case. Helpdesk has ''Full control'' on the OU ''Users'', and is allowed to modify most
groups in it. Do you really want Helpdesk to have ''Full control'' on the OU=Users, which
is considered as an critical OU, because it also contains groups, such as DnsAdmins that
has elevated rights to Domain Admin?

<<DMS.DocIdFormat>>
 Verify who can take-over multiple accounts

In the following OU – We are able to see the Domain Users that are stored in it.

 In the green, we are able to see that Helpdesk has the privileges to reset the password of
the user accounts, when they forget their password. However, in the red, we can see that
Alice is also allowed to ''Reset passwords'' of users. I do not think Alice should be able to
do that :)

<<DMS.DocIdFormat>>
 Verify who can take-over Domain Admins account

In the following screenshot. We are able to see which members are part of the Domain Admins
group.

 Here we can see that Suzanne who is not part of the Domain Admins group, but it has
Full control on Darlene, so it can RESET the password of Darlene now and take over the
account. This is a finding

<<DMS.DocIdFormat>>
 Ensure that Domain Admins are the owner of the Domain Admin users, because
unauthorized users, who are the owner of the object, can still take-over the account.

Here we can see that for some reasons. Remote Desktop Users has the ownership of
Darlene his account. Now everyone in Remote Desktop Users can take-over the account.
If Domain Admins is not the owner, this is a finding

<<DMS.DocIdFormat>>
 Verify who can modify AD groups

Here you can see the current users in Administrators, but are they the only ones?

 Ensure that no users or groups have been added to high-privileged groups or otherwise
they could elevate their privileges.

Here is an example that Helpdesk can add themselves in Administrators. This is a

finding

<<DMS.DocIdFormat>>
 Here we can see that Alice has ''Full control'' on the Administrators and that means that
she also could elevate to Administrators. This is a finding

 Ensure that Domain Admins or Administrators are the owners of the groups or otherwise
unauthorized owners could leverage to Administrators.

Here we can see that ''Domain Users'' is the owner of Administrators. Which is a finding.

<<DMS.DocIdFormat>>
 Verify who can enable Unconstrained Kerberos Delegation

"When unconstrained delegation is configured on a server, it can impersonate connecting users

because their Ticket-Granting Ticket (TGT) is placed into the service ticket if the Service Princi-
pal Name (SPN) is included in the Ticket Granting Server (TGS) request."

Source: https://www.petri.com/understanding-kerberos-delegation-in-windows-server-active-di-
rectory

 This is how it looks like when Unconstrained Kerberos Delegation is configured.

<<DMS.DocIdFormat>>
 Ensure no unauthorized users have ''Full control'' on computer objects otherwise, they
could enable Unconstrained Delegation on a server.

By default, Account Operators has ''Full control'' and is allowed to do so.

 Here we can see that Alice has ''Modify permission'' on SRV02 – Which means she could
leverage to ''Full control'' permission and enable Unconstrained Delegation on SRV02.
This is a finding, since ''Full control'' is rarely needed on Computer objects.

<<DMS.DocIdFormat>>
 Ensure that Domain Admins are the owners of the server (computer) objects, otherwise
unauthorized users could leverage to Full control and enable unconstrained delegation

Here we can see that DnsAdmins is the owner of the object. This is a finding, because
otherwise DnsAdmins can leverage to SRV02 or enable unconstrained delegation

<<DMS.DocIdFormat>>
 Here is the OU ''Servers'' where all the server objects are stored.

 Here we can see that Support Engineers has ''Full control'' on the OU ''Servers'' and it could
modify the permission to enable unconstrained delegation. Do you want this? – Why do
they need ''Full control''?

<<DMS.DocIdFormat>>
 SeEnableDelegationPrivilege
 Here we can see at the Default Domain Controlers Policy (GPO) allowed ''Helpdesk'' to
have the ''Enable this computer for delegation'' rights, so they can enable Unconstrained
Kerberos Delegation on all the servers.

 Misuse of the Enable computer and user accounts to be trusted for delegation user right
could allow unauthorized users to impersonate other users on the network.

Ensure that only ''Administrators'' are allowed to enable Unconstrained Delegation

(SeEnableDelegationPrivilege)

 Users or groups with Full control on computer objects, such as the servers. Are allowed to
log on those servers, but without Local Admin. This is, because Full control, includes the
''Allowed-to-authenticate'' permission.

<<DMS.DocIdFormat>>
 Verify who can make changes to the AD Schema

Schema Admins group is a privileged group in a forest root domain. Members of the Schema
Admins group can make changes to the schema, which is the framework for the Active Directory
forest. Changes to the schema are not frequently required.

In my opinion, this group should be rarely used and nobody should be part of it, but is Schema
Admins the only group that can make changes to the Schema?

As you can see, Schema Admins is the only privileged group that has Read/Write on the Schema.

<<DMS.DocIdFormat>>
 Ensure that no unauthorized users/groups have been added to the DACL of Schema,
because otherwise they can also make modification to the Schema.

 Ensure that ''Schema Admins'' is the owner of Schema.

Here we can see that Helpdesk is the owner of Schema. This is a finding

<<DMS.DocIdFormat>>
 Verify the AdminSDHolder is clean

 Ensure that the AdminSDHolder is in a clean state, which basically means. Make sure no
users or groups have been added to the group, because AdminSDHolder can be used for
persistence in the network.

Here we can see that Paul West has been added with Full control. This is a finding.

<<DMS.DocIdFormat>>
 Verify dsHeuristics has not been modified

DS-Heuristics attribute in Active Directory can be used to make global changes to the behaviour
of Active Directory and Active Directory controllers throughout the entire Active Directory forest.

dsHeuristics can be modified and if it that is the case. dsHeuristics can be used to exclude groups
from the AdminSDHolder, such as Account Operators, Backup Operators, Print Operators and
Server Operators. So they aren't a protected object anymore.

<<DMS.DocIdFormat>>
 These are all the values to exclude certain kind of groups from the AdminSDHolder

Ensure that the dsHeuristics attribute has not been modified

 Ensure that only Domain Admins & Enterprise Admins can modify the dsHeuristics

<<DMS.DocIdFormat>>
 Verify sIDHistory has been removed after migration

"SID history helps you to maintain user access to resources during the process of restructuring
Active Directory domains. When you migrate an object to another domain, the object is assigned a
new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the
user loses access to that resource until you can reassign permissions."

Source: https://blog.thesysadmins.co.uk/admt-series-3-sid-history.html

 Ensure that after you have completed your migration. You take an AD snapshot, and then
remove all the sIDHistory in the domain or otherwise attackers can use this attribute to
escalate their privileges

 Reference: https://itfordummies.net/2015/12/09/remove-sidhistory-powershell/

<<DMS.DocIdFormat>>
 Verify SID Filtering is enabled

SID Filtering protects trusting domains from attackers.

Attackers might inject SIDs of an elevated user or group in the trusting domain to the sIDHistory
of a user in the trusted domain.

When SID Filtering is disabled, attackers can successfully inject the sIDHistory and gain
privileged administrative access to resources in the trusting domain. Domain Admins & Enter-
prise Admins can enable SID Filtering.

 To verify SID filter quarantining from the trusting domain

1. Open a command prompt.

2. At the command prompt, type the following syntax, and then press ENTER:

netdom trust <TrustingDomainName> /domain: <TrustedDomainName> /quarantine

/userD: <domainadministratorAcct> /passwordD: <domainadminpwd>

 To verify SID filter quarantining from the trusting forest

1. Open a command prompt.

2. At the command prompt, type the following syntax, and then press ENTER:

netdom trust <TrustingDomainName> /domain: <TrustedDomainName> /enablesidhistory

/userD: <domainadministratorAcct> /passwordD: <domainadminpwd>

 To verify SID filter quarantining from the trusted domain

1. Open a command prompt.

2. At the command prompt, type the following syntax, and then press ENTER:

netdom trust <TrustingDomainName> /userO:<domainadministratorAcct> /pass-

wordO:<domainadminpwd> /domain:<TrustedDomainName> /quarantine

 To verify SID filter quarantining from the trusted forest

1. Open a command prompt.

2. At the command prompt, type the following syntax, and then press ENTER:

netdom trust <TrustingDomainName> /userO:<domainadministratorAcct> /pass-

wordO:<domainadminpwd> /domain:<TrustedDomainName> /enablesidhistory

<<DMS.DocIdFormat>>
 Verify no unauthorized users have been added to DNS Server
object

Ensure that no users or groups have been added to the DACL on the DNS server object, because a
security researcher discovered last year that users or groups with Write properties on the DNS
server object could run code as SYSTEM on the Domain Controller, and elevate their privileges to
Domain Admins.

 By default only the following groups have ''Write'' permission: DnsAdmins, Domain
Admins, Enterprise Admins, Administrators and ENTERPRISE DOMAIN Controllers

Here we can see that Helpdesk has ''Full control'' on the DNS server object. This is a
finding, and it is also rarely that someone needs to make changes on the DNS server
object.

<<DMS.DocIdFormat>>
 Verify who can modify GPO's and who has the ownership on it

 Ensure that no unauthorized users or groups have been added to the DACL of a GPO, such
as the Default Domain Controllers GPO.

 Ensure that Domain Admins has the ownership on critical GPO's.

Here we can see that Ben Smith is the owner of the GPO. Which is a finding!

<<DMS.DocIdFormat>>
 Read/Write GPO is also modifying GPO

Here we can see that Dumfries is added to the Default Domain Controllers Policy with the allowed
permissions as ''Custom''

 If a user has ''Write all properties'' permission. It is also possible for the user or group to
modify the GPO settings. Look close who has what permission on GPO's.

<<DMS.DocIdFormat>>
 Who else can modify GPO's through SYSVOL?

I WILL TRY TO MAKE IT SIMPLE FOR YOU!

SYSVOL is simply a folder which resides on each and every domain controller within the domain.
It contains the domains public files that need to be accessed by clients and kept synchronised
between domain controllers.

SYSVOL contains logon scripts and group policy data. This can be discovered on the Domain
Controller and is stored in the following location.

Location: C:\Windows\SYSVOL\sysvol\contoso.com\Policies

THIS LOCATION IS STORED ON THE DOMAIN CONTROLLER!!

<<DMS.DocIdFormat>>
 This is the Default Domain Controller Policy (GPO)

 Which can be discovered here|

<<DMS.DocIdFormat>>
 Here we can see it looks exact the same like the Default Domain Controllers Policy.
Dumfries is visible here as well

 Now let's add a random user, and see if it will be visible on the Default Domain
Controllers Policy GPO?

<<DMS.DocIdFormat>>
 Here we can see that when you look at Group Policy Management Console. Ben Smith is
not visible…

 Now Ben Smith has the permissions to modify the GPO, but you might overlook it.

 Location: C:\Windows\SYSVOL\sysvol\contoso.com\Policies\LONG GPO NAME\MA-

CHINE\Microsoft\Windows NT\SecEdit

<<DMS.DocIdFormat>>
 What happens when you double click on GpTmpl?
 This looks complex, right?

 GpTmpl folder is actually the User Right Assignment you have looked at
SeBackupPrivilege = Back up files and directories

<<DMS.DocIdFormat>>
 Recommendation
 Now in our case. Ben Smith could modify the GPO settings as well through SYSVOL.

 Don't overlook what kind of permissions has been set on the SYSVOL Policies as well that
are stored on the Domain Controller.

<<DMS.DocIdFormat>>
 Verify - Account Operators, Print Operators and Server Operators
is empty

 Ensure that Account Operators, Print Operators and Server Operators are empty,
because these groups have wide permissions in the domain and could elevate their
privileges. All of them have log on rights to the Domain Controller
 Ensure that Backup Operators group is very limited to users that are dedicated to backing
up AD & DC.

 Here we can see that Helpdesk is part of Account Operators, which is a finding.

<<DMS.DocIdFormat>>
 Ensure that only Domain Controllers are part of the group
''Domain Controllers''

 Ensure that only Domain Controllers are part of the Domain Controllers group. Since
members of Domain Controllers have the elevated rights to synchronize credentials
remotely from the DC.

Here we can see that Paul is member of the Domain Controllers group. This is a finding

<<DMS.DocIdFormat>>
 Ensure that you don't have more than four Domain Admins

Domain Admins is often not required for many tasks, but only for promoting a DC. Just for small
tasks, which you do not do every day.

Microsoft recommends to only having one Domain Admin, but I know nobody will listen to
Microsoft, so let's make a limit. If you have more than four Domain Admins. It is a finding.

 Ensure that you delegate tasks, because all tasks of an AD admin can be delegated without
being Domain Admin. Such as authorizing & unauthorizing to DHCP servers, create
GPO's and link it to an OU, Reading event logs on the DC, Managing Certificate
Authority.
 Please take a look at: https://www.slideshare.net/HuyKha2/enforcing-leastprivilege-in-ac-
tive-directory

Here we can see that we have more than four Domain Admins. This is a finding!

 Also, make sure that Enterprise Admin is super limited, by only having one user max or
just zero. Besides of that. Reduce down users in Administrators.

<<DMS.DocIdFormat>>
 Ensure (Default) settings of Domain Controller has changed

The following settings at the GPO of the Domain Controllers needs to be changed, because the
default settings are not secure, such as allowing Account Operators, Server Operators and Print
Operators having access to the DC. So why is this bad?

A Domain Controller has the NTDS.DIT, which is the AD database that contains all the
information including the credentials of users.

Since Server Operators & Backup Operators have the rights to log on the DC and back up &
restore all files and directories, they also could do the same for the NTDS.DIT file.

Example:

 Back up files and directories

 Restore files and directories

<<DMS.DocIdFormat>>
All the settings in RED – Needs to be changed ASAP!

1.

<<DMS.DocIdFormat>>
2.

<<DMS.DocIdFormat>>
Recommendation:

Create a new GPO and link it to the OU ''Domain Controllers'' with the following settings at Local
Policies -> User Right Assignment

<<DMS.DocIdFormat>>
 Ensure (Default) User Right Assignment is changed on clients

There needs to be a GPO created that prevents Domain Admins logging on the clients their
workstations or otherwise their credentials will be exposed on the connected device, since
Windows will cache credentials in memory duo their SSO mechanism.

However, that is not the only thing, a few additional settings at Local Policies -> User Right
Assignment needs to be changed as well. Such as blocking Backup Operators for having access to
the workstation to be able to back-up it. Since this group is only allowed to back-up the AD/DC,
and nothing else.

1.

<<DMS.DocIdFormat>>
2.

<<DMS.DocIdFormat>>
Recommendation:

First thing to do is create a new OU, where you put the computer objects of the Domain Admins in
it, because we do not want to lock them out of course.

Here as you can see, we have two OU's.

Admin workstations contains all the computer objects of the Domain Admins

Users workstations contains the rest of the workstations from users.

1. Now create a new GPO and link it to ''OU'' Users workstations

2. Go to Local Policies -> User Right Assignment
3. Tweak the following settings

4. Change it to the following settings:

<<DMS.DocIdFormat>>
5. Change the rest of the additional settings!

Access this computer from the network Everyone, Administrators, Users

Add workstation to domain Administrators
Allow log on locally Administrators, Users
Backup files and directories Administrators
Log on as a batch job Administrators
Restore files and directories Administrators

<<DMS.DocIdFormat>>
 Ensure LOCAL Backup Operators is empty on workstations

- What can Backup Operators actually do?

In the previous areas – We know that Backup Operators can log on the DC and restore
''ALL'' files on a computer, regardless of the permission that protect those files.

This means that Backup Operators can back-up the NTDS.DIT on the Domain Controller.
Which is the AD database. Besides of that, Backup Operators can also log on workstations,
and we just tweaked those settings that we do not allow Backup Operators having access to
a client workstation.

1. Open Computer Management -> Local Users and Groups-> Groups ->
Backup Operators

2. Verify LOCAL Backup Operators is empty

<<DMS.DocIdFormat>>
 Ensure insecure parameters are not used

A few parameters that you need to look for in your environment and fix them. Do NOT use this
kind of configurations. Again, don't fucking use it.

<<DMS.DocIdFormat>>
Recommendation:

 Scan for these insecure parameters and ask why?

<<DMS.DocIdFormat>>
 Verify which users can link or unlink an (arbitrary) GPO

 Look for all the users who are able to create a GPO first.
 Group Policy Creator Owners
 Look also at Group Policy Objects container in Group Policy Management Console

Here we can see that Domain Admins & Group Policy Creator Owners are allowed to create
GPO's. We are more interested in Group Policy Creator Owners this time.

Group Policy Creator Owners can't be weaponized immediately if it is only allowed to create
GPO's, but what if it has GenericAll / GenericWrite, WriteDacl, WriteOwner on certain OU,
where the Domain Controller or servers are stored.

Which allows her to modify the gPLink attribute and link an (arbitrary) GPO to it.

<<DMS.DocIdFormat>>
Here we can see that Alice is part of Group Policy Creator Owners.

Alice has ''Full control'' on the OU ''Domain Controllers''

<<DMS.DocIdFormat>>
This allows Alice to be able to modify the gPLink attribute, which means she can link her
(arbitrary GPO) to the Domain Controllers.

Recommendation

 Look who can create GPO's in the domain

 Look who has delegated rights on critical OU's, such as the servers, workstations and
domain controllers.
 Unlinking an GPO that contains security settings can weak a system!

<<DMS.DocIdFormat>>
 Ensure Domain Admins is removed from LOCAL Administrators
on clients

This is more of a best practice, but it does not cost much time to do it, so you also should remove
Domain Admins from the LOCAL Administrators group.

<<DMS.DocIdFormat>>
 Ensure "Account is sensitive and cannot be delegated" is enabled
on AD admins

'Account is sensitive and cannot be delegated', ensures that an account's credentials cannot be
forwarded to servers that support Unconstrained Delegation. If you have servers that supports
those, you need to enable this ASAP on your AD admins, but besides of that. Enable it as a best
practice, even if you do not have servers with those configurations.

<<DMS.DocIdFormat>>
 Ensure AD admins are in Protected Users

Protected Users is a global security group and its primary function is to prevent users' credentials
being abused on the devices where they log in.

This is a group that exist on Windows Server 2012 R2+

 Ensure that Administrators, Domain Admins, Enterprise Admins are in Protected Users.

<<DMS.DocIdFormat>>
 Ensure that Administrator, DefaultAccount, Guest are disabled.

 Do not use the Built-in Administrator account.

 Ensure that this account is disabled.

This is like a god account in Active Directory that has all the permissions, which are barely
needed. If this account is used and enabled, this is a finding IMO. However, it us up to you
what you are doing with it.

 Recommendation
 DefaultAccount & Guest needs to be disabled as well.
 Alert when someone is enabling or authenticating with the following accounts
 Administrator, DefaultAccount and Guest.
 DefaultAccount & Guest have an empty password and can log on without password.

<<DMS.DocIdFormat>>
 Ensure Domain Admins is removed from Local Administrators on
servers with Unconstrained Delegation

Unconstrained Kerberos Delegation can be exploited, when an attacker tricks a user to

authenticate to the server, so they will leave their TGT behind in memory.

Attackers do need to have Local Admin to dump the TGT from memory, so my advice is to
look at the servers that are configured with Unconstrained Delegation and do the following:

- Remove Domain Admins from the LOCAL Administrators group.

- Reduce down the amount of Domain Admins on those servers. Do they really need to log
on those servers?

<<DMS.DocIdFormat>>
 Rotate the password of KRBTGT every 4 months

KRBTGT is an account that act as a service account for the Key Distribution Center.

KRBTGT handles all the Kerberos tickets in the domain, and is responsible for encrypting and
signing all those tickets.

Attackers may use the KRBTGT account to create Golden Tickets and remain persistent on the
network. It is incredible difficult to detect this attack, so you will have to rely on prevention.

 Recommendation
 Change the password of the KRBTGT twice, when an AD admin leaves or after four
months. Microsoft Recommends to do it every year, but this is how I do it. It is again, up
to you.
 Log on the DC and reset the krbtgt account password once. Wait 24 hours to ensure that
the replication has been completed. Log on the DC again and do the second reset
password.
 If you do it rapidly, you might break some Kerberos services.

<<DMS.DocIdFormat>>
 Rotate the password of the Built-in Administrator every <up to
you> months.

Despite that, you absolutely should not use this account. I would recommend to set a strong
password on it as well, because you ''never know'' ' *wink*

<<DMS.DocIdFormat>>
 Remove servicePrincipalName and revoke all group membership
for the Built-in Administrator

Since the Built-in Administrator should not be used, because it is a god account. You should
ensure that the servicePrincipalName has been removed from it.

In some environment. This account is used for daily tasks, which is bad, but what's more risky is
the fact that it has a default SPN value. Every attacker could request the service ticket from the
Administrator account and crack it offline, because it has an SPN value.

<<DMS.DocIdFormat>>
 Make sure the Built-in Administrator is disabled

 Remove the servicePrincipalName – Attribute should be empty

<<DMS.DocIdFormat>>
 Revoke group membership for the Built-in Administrator
 Built-in Administrator should only be part of Domain Users

<<DMS.DocIdFormat>>
 Set a password for DefaultAccount & Guest and rotate it
<every half up to you> months.

DefaultAccount & Guest accounts are disabled by default, but do contain an empty password.
Everyone who is able to enable those two accounts. Can log on to the domain without any
password and query AD for example.

 Recommendation:
 Restrict account logon on denied for those accounts.
 Set a strong password for those accounts and make sure it is disabled.

<<DMS.DocIdFormat>>
 Rotate the password of HelpAssistant & Support_388945a0

For the ones that are working with Active Directory for a long time. Like, since 2005. There are
two accounts that might still exist in your environment and those accounts are the following:

 HelpAssistant
 SUPPORT_3388945a0

It is also a best practice to reset the password of those accounts, since they might be forgotten as
well.

<<DMS.DocIdFormat>>
 Monitor SVC_ADFS account and ensure it is not a Domain
Admin

If you have or are planning to install an ADFS server. There will be an account created called
SVC_ADFS that has Domain Admin privileges. After the installation has completed. You should
remove it from Domain Admin.

<<DMS.DocIdFormat>>
Recommendation:

 After the installation of ADFS is completed. Please ensure SVC_ADFS is not a Domain
Admin.
 Ensure no one is logging on this account. Alert when someone decides to log on that
account.

<<DMS.DocIdFormat>>
 Restrict logon rights on default Exchange accounts

If you used to install Exchange in the past. You would always get a few built-in accounts during
the installation of Exchange with those crazy long usernames.

Did you know that you actually can set a password for those accounts and enable it, and then
authenticate with it?

<<DMS.DocIdFormat>>
Here you can see that I have logged on one of those accounts and can now query AD for example.

 Recommendation
 Restrict logon access on all those (default) Exchange accounts
 Verify that all of them are disabled and alert when someone logs on those.

<<DMS.DocIdFormat>>
<<DMS.DocIdFormat>>
 Deploy Microsoft LAPS

All the Local Administrator password of every domain joined computer is often the same, because
duo the image that is deployed by default and nobody is actually bothered to change the password
of every domain joined computer manually.

If the password of every domain joined computer is the same. An attacker can re-use the
credentials of a compromised machine to laterally move around across the network and
authenticate against other systems. The following attributes on computer objects will tell you if
you have deployed LAPS:

 ms-Mcs-AdmPwd

 ms-Mcs-AdmPwdExpiration

References:

https://www.microsoft.com/en-us/download/details.aspx?id=46899

http://www.alexandreviot.net/2015/05/26/security-local-administrator-password-solution-laps/

<<DMS.DocIdFormat>>
 Deploy Microsoft ESAE Model

Red Forest is the project name for Enhanced Security Administrative Environment or ESAE. It is
an architecture design that helps organization to mitigate credential theft by having a 3-layer tier
model, only allowing Domain Admins logging on DC's, Server Admins logging on servers, and
helpdesk logging only on workstations

So how would ESAE model actually looks like in AD?

- How can I implement this as well?

I have made a draft presentation about how you can do it in your TEST environment first,
but I did not included everything what Microsoft recommended, such as Credential Guard.

If you were curious how it would look like in AD:

https://www.slideshare.net/HuyKha2/active-directory-esae-model-149736364

<<DMS.DocIdFormat>>
Recommendation

 Look at my presentation to get an idea: (I am not claiming it is immediately good, but this
is how I would do it, feel free to do it a bit different than me)
 If you want to deploy ESAE. Test it first in your TEST environment.
https://www.slideshare.net/HuyKha2/active-directory-esae-model-149736364

Here a few screenshots of the slides in the presentation if you are curious.

<<DMS.DocIdFormat>>
 All IT employees needs to have an second account

Imagine you as Domain Admin browsing all day on the internet, reading all your (phishing) mails
and opening every poisoned attachment.

Yes, that's bad. Every IT user has many rights in a network, so a second account is required for
their work. If an IT employee does not have a second account. This is a finding!

 IT user needs to have a second account that is used to perform their duties, without having
internet access, mail, etc.
 Other account is a low-privileged user which can have internet and mail of course.

<<DMS.DocIdFormat>>
 Everyone & Anonymous needs to be removed from
Pre-Windows 2000 Compatible Access

"The Pre-Windows 2000 Compatible Access group was created to allow Windows NT
domains to interoperate with AD domains by allowing unauthenticated access to certain
AD data. The default permissions on many AD objects are set to allow access to the Pre-
Windows 2000 Compatible Access group. Implementation in a Windows forest in which
Windows NT domain controllers are still deployed could result in operational problems
including denied access to authorized users. When the Everyone or Anonymous Logon
groups are members of the Pre-Windows 2000 Compatible Access group, anonymous ac-
cess to many AD objects is enabled. Anonymous access to AD data could provide valua-
ble account or configuration information to an intruder trying to determine the most ef-
fective attack strategies."

Source: https://www.stigviewer.com/stig/active_directory_domain/2014-01-07/finding/V-8547

<<DMS.DocIdFormat>>
 Service account (with SPN) in Domain Admins is a finding

This is just terrible bad, and you should feel bad for listening to the vendor.

Sorry, not sorry. I just do not want to explain the story, because you already know it.

Well, if not.

Service account or just normal regular accounts that have a servicePrincipalName are vulnerable
for a so-called attack called ''Kerberoasting''

An attacker with just Domain User privileges could request service tickets from accounts with an
SPN value and crack it offline without to worry for lock-out policies or detection.

So, again. Every account that has a servicePrincipalName and is part of groups, like Domain
Admins, Enterprise Admins or Administrators is vulnerable for a brute force attacks.

In this case, the risk would be. An attacker brute force a service account. Since the vendor re-
quired you to make it Domain Admin. Means that the attacker could become Domain Admin,
because a weak password was chosen.

<<DMS.DocIdFormat>>
 Additional security settings for DC

All of these settings can be found at Local Policies -> Security Options

If this policy setting is enabled, a user might use the well-known Administrators SID to get the
real name of the built-in Administrator account, even if the account has been renamed. That
person might then use the account name to initiate a brute-force password-guessing attack.

This is by default enabled on the DC.

Recommendation:

 Microsoft recommends to ''Disabling'' this setting on the DC.

<<DMS.DocIdFormat>>
Network access: Do not allow anonymous enumeration of SAM accounts

An unauthorized user could anonymously list account names and use the information to perform
social engineering attacks or attempt to guess passwords. If this setting is disabled.

Recommendation:

 Microsoft recommends to ''Enable'' this setting

<<DMS.DocIdFormat>>
Network access: Do not allow anonymous enumeration of SAM accounts and shares

An unauthorized user could anonymously list account names and shared resources and use the in-
formation to attempt to guess passwords or perform social-engineering attacks.

Recommendation:

 Microsoft recommends to enable this setting

<<DMS.DocIdFormat>>
Devices: Allowed to format and eject removable media

Users could move data on removable disks to a different computer where they have administrative
privileges. The user could then take ownership of any file, grant themselves full control, and view
or modify any file.

 Recommendation
 Configure the Devices: Allowed to format and eject removable media setting to
Administrators.

<<DMS.DocIdFormat>>
Devices: Prevent users from installing printer drivers

A malicious user could install inappropriate printer drivers in a deliberate attempt to damage the
computer, or a user might accidentally install malicious software that masquerades as a printer
driver.

Recommendation:

 Enabled

<<DMS.DocIdFormat>>
Domain controller: Allow server operators to schedule tasks

Tasks that run under the context of the Local System account can affect resources that are at a
higher privilege level than the user account that scheduled the task.

Recommendation:

 Disabled

<<DMS.DocIdFormat>>
 Inactivity of high-privileged users

All the high-privileged users, such as Domain Admins. Needs to be monitored on their logon
activity as well.

One of an example could be the following:

- Domain Admin did not log on for 3 months and the reason is unknown
First, restrict the account logon of that user
Second, wait until someone is complaining.
If nobody is complaining, disable the account as well.
Wait a few days.
If still nobody is complaining. Remove it from Domain Admins.

 Here we see Martin is a Domain Admin

<<DMS.DocIdFormat>>
 Here we can see that Martin never even logged on his account, but he is still a Domain
Admin?!

<<DMS.DocIdFormat>>
 Enterprise Key Admins & Key Admins

I have discovered in the past that Enterprise Key Admins & Key Admins are two default built-in
groups after you upgrade your domain to a Windows Server 2016.

<<DMS.DocIdFormat>>
In the past, Enterprise Key Admins used to be a group with Full control rights on the AD Root,
but this has been resolved. So, what kind of rights do they still have?

''Members of this group can perform administrative actions on key objects within the forest''

<<DMS.DocIdFormat>>
There is a default OU called ''Keys'' and both groups have Full control on that OU, which actually
makes sense though.

<<DMS.DocIdFormat>>
 What kind of rights does Enterprise Key Admins ''REALLY''
have?

Microsoft says that Enterprise Key Admins can do the following:

''Members of this group can perform administrative actions on key objects within the forest''

Well, that sounds a bit strange to me.

Since Enterprise Key Admins has Full control on the OU ''Keys'' it is allowed to create users,
groups, computer objects in that OU. It can configure accounts with an empty password for
example, which you maybe might not like.

<<DMS.DocIdFormat>>
 Example
I added myself as a normal Domain User to the Enterprise Key Admins group and created
an user in the OU ''Keys''

 After I have created the TestAccount with my user ''Test'' – This is what I get, when
looking at the DACL of TestAccount.

 Test (myself) became owner of the object.

 Enterprise Key Admins & Key Admins have ''Full control'' on the created account.

<<DMS.DocIdFormat>>
Recommendation:

Make sure that the groups Enterprise Key Admins & Key Admins are empty, because it has ''Full
control'' on the OU ''Keys'' only, and could create accounts with empty passwords for example.

I would not rate it at this moment as an high-privileged group, but it is something that you should
look for. Maybe it has more permission than I described.

Also, make sure that the OU ''Keys'' is empty.

<<DMS.DocIdFormat>>
 Local Users and Groups – Who can Run As Administrator?

 Make sure that the following Local Groups are empty on both workstations and servers.
 When was the last time that you have checked who had Local Admin on your workstation
or server?

<<DMS.DocIdFormat>>
 Tools to audit AD

 BloodHoundAD: https://github.com/BloodHoundAD/BloodHound
 PingCastle: https://pingcastle.com/download/
 Reset KRBTGT Password script: https://gallery.technet.microsoft.com/Reset-the-krbtgt-
account-581a9e51
 GoldFinger: https://www.paramountdefenses.com/free-active-directory-audit-tool.html
 Grouper2: https://github.com/l0ss/Grouper2

<<DMS.DocIdFormat>>