Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ADSTG v2.0 - Guidance


Published on

Enforcing Least-Privilege document was accidentally removed.
Here it is:

Active Directory Security Testing Guide - v2.0
ADSTG v2.0 has been released with more in-depth details and the list of exposures has been improved as well, but it still remains as basic for organizations that aren't much mature yet.

ADSTG is more focused on getting the basic done, such as deny workstation-to-workstation communication, deploying Microsoft LAPS, reducing the amounts of Local/Domain/Enterprise Admins, etc.

Published in: Engineering
  • Be the first to comment

ADSTG v2.0 - Guidance

  1. 1. ADSTG – V2.0 Author: Huy Kha Email:
  2. 2. TABLE OF CONTENT 1) Introduction 2) About the guide -------------------------------- 3) Improving the security settings of Domain Controllers 4) Change the default password policy in the environment 5) Do not allow Domain Admins, Enterprise Admins, Schema Admins logging into users workstation 6) Ensure that no unauthorized users can modify GPO settings 7) Look for (exploitable) ACL permissions that has been set on an object 8) Check if AD root has insecure delegated permissions on it. 9) Scan for insecure account options in the domain 10) Scan for Unconstrained Kerberos Delegation and who can enable this setting 11) Ensure that high-privileged users, such as Administrators & Domain Admins have the "Account is sensitive and cannot be delegated" checkmark enabled. 12) All high-privileged users, such as Administrators & Domain Admins needs to be in Protected Users 13) Rotate the password of the Built-in Administrator once a year 14) Rotate the password of the KRBTGT twice a year 15) All service accounts with a servicePrincipalName needs to have a 25+ password length 16) Only allow service accounts logging into the specific servers that is required 17) Ensure that the following groups are empty: Account Operators, Server Operators, Print Operators 18) Ensure that the Pre-Windows 2000 Compatible Access is empty 19) Ensure that the Domain Controllers group only have have DC’s listened. 20) Remove the adminCount attribute from former privileged users 21) Reduce the following high-privileged groups: Enterprise Admins, Domain Admins, Administrators 22) Reduce the following groups: Group Policy Creator Owners, Remote Desktop Users, DnsAdmins 23) Reduce the amount of Local Admins on workstations 24) Ensure that no unauthorized users or groups have GenericWrite on the DNS Server object. 25) Ensure the AdminSDHolder has not been modified 26) Ensure that the dsHeuristics attribute has kept default 27) Remove all sIDHistory attributes if migiration has been successful finished 28) Detect malicious behaviour in AD 29) Disable legacy protocols 30) Deploy Microsoft LAPS across every domain joined computer
  3. 3. 31) Deny workstation-to-workstation communication 32) Ensure that Inheritance permission is enabled on all non-privileged users and objects
  4. 4. 1 – Introduction Active Directory is (currently) the core identity platform for many business enterpris- es around the world that provides access to all the resources on a network. By compromising an Active Directory. An attacker would be able to access all re- sources that is connected on a network. AD is an asset that has been overlooked in the shadows for years, because of the complexity and often underrestimated, since it is pretty easy to manage AD on a insecure way, without knowing about it. Which can introduce different cracks, such as Domain Admins logging into a lower trusted workstation on the network, and his/her credentials are then stored on the connected machine, because Windows caches credentials in memory. For many years the focus has been set on the network perimeter, that big chinese wall that needs to block intruders from getting into the network. But what would happened if I told you that this is already happening? Attackers have found different ways on how to bypass the perimter that we’re now forced to assume breaches and have to admit. ‘’An attacker will get inside, so my goal is to make his/her life harder” At the end of the day, (not always). In many cases. Attackers are trying to leverage to Active Directory to access the crown jewels on the network. Having a insecure Active Directory means that you’re leaving your valuable network very vulnerable for attackers. It’s time to act now!
  5. 5. 2 – About the guide In ADSTG v1.0 – There was a lot room for improvement such as explaining the details a bit more further and having more list of exposures. Besides of that, There were some specific details that has been missed, and yes. I am pretty sure that in this guidance there will be things that I have been overlooked or wasn’t aware of. At the end of the day. Nothing is perfect, please keep that in mind. Sorry, I’m just a human ;-) ADSTG is a guidance to help security professionals or system administrators to improve the security of Active Directory. It is a reference on how to spot insecure configurations before attackers are doing it. This is not a compliance document, but more of a reference for a secure AD. Despite following these kind of best practices. I don’t claim that you won’t be breached by attackers. There is always a chance. Just admit it. The only thing we’re doing is mitigating different attack paths and giving the attacker a hard time.
  6. 6. 3 – Improve the security settings of Domain Controller(s) Description: A domain controller is the server that manages the authentication of users in the domain. It is a server that holds all the data organized and ‘’secured’’ - Read carefully it holds ‘’all data’’ in an organization! Since a DC contains the AD database (NTDS.DIT) which has all the information of users credentials, computers, group policies etc. It is a server that attackers might go after, be- cause it holds the keys to the kingdom in Active Directory. So by default we need to limit access to the DC, and also keep our DC clean in a good shape, because you don’t want someone being able to run code on the DC or puts an USB stick into the DC, right? This looks complex. don’t worry. It’s the GPO, which contains the settings of a DC.
  7. 7. Summary By default different groups such as Account Operators, Server Operators, Print Op- erators and Backup Operators can log on locally to the Domain Controller. Many of these groups can also elevate their privileges, such as back-up the AD database, which by default Server & Backup Operators is allowed to do so. And what about Print Operators shutting down the DC and loading device drivers on your DC? All the stuff in RED needs to be changed.
  8. 8. Recommendation (1) Create a new GPO and link it to the OU ‘’Domain Controllers’’ with the following set- tings down below. This settings can be changed at User Right Assignment NOTE: I’ve added Backup Operators to it, but you should only use this group to back-up AD & DC, nothing else. Access to this computer from the network Administrators, Authenticated Users, Enterprise Domain Controllers Allow log on locally Administrators, Backup Operators Allow log on through Remote Desktop ser- vices Administrators, Backup Operators Back up files and directories Administrators, Backup Operators Change the system time Administrators, Local Service Deny access to this computer from the net- work Guest, Local account Deny log on as a batch job Guest Deny log on through Remote Desktop ser- vices Guest, Local account Force shutdown from a remote system Administrators Load and unload device drivers Administrators Manage auditing and security log Administrators Restore files and directories Administrators, Backup Operators Shut down the system Administrators
  9. 9. Recommendation (2) Like mention before, you don’t want users loading any device on your Domain Controller or put an USB stick into the DC, and last but not least. Also not unauthorized users run- ning a schedule tasks on the DC. The following settings in the RED needs to be changed. Devices: Allowed to format and eject remov- able media Administrators Devices: Prevent users from installing print- er drivers Enable Domain Controller: Allow server operators to schedule tasks Disable Network access: Do not allow anonymous enumeration of SAM accounts Enable
  10. 10. Network access: Do not allow anonymous enumeration of SAM accounts and shares Enable
  11. 11. 4 – Change the default password policy Description: By default this is the password policy of an stock installed AD. Attackers love it when you have a weak password policy, because it allows them to have a higher chance rate for performing attacks such as ‘’Password spraying’’, which they load an amount of password attempts against users to trying to crack their passwords. An password spraying attack through PowerShell
  12. 12. Recommendation The default password policy should be changed, but it is hard to tell what’s a good pass- word policy. So this in my opinion, and no-one needs to fully agree with it. The only thing I want to tell you is that you absolutely need to change it to a stronger policy. Change the following settings at the Default Domain Policy (GPO) Minimum password length 12-14 Maximum password age 180 days Minimum password age 1 day Password must meet the complexity re- quirements Enable Account lockout threshold 5-10 Account lockout duration 15 min Reset account lockout counter after 15
  13. 13. 5 – Do not allow Domain Admins logging into lower trusted workstations By default Domain Admins, Enterprise Admins, Schema Admins, and Local account are allowed to log on lower trusted workstations in the domain. The reason that this is bad is because of the following: Windows is caching credentials in memory after someone has logged into a workstation. This is to duo the SSO mechanism in windows. So a realistic scenario would be a Domain Admin logging in a lower trusted workstation in the domain, and that workstation gets compromised by an attacker. And that means that the attacker could also leverage to account of the Domain Admin. When are the credentials stored in memory?
  14. 14. Recommendation First you need to create a new OU and place all the computer objecs of the Domain Ad- mins, Enterprise Admins and Schema Admins into it. Otherwise you might lock them out. All the workstations of the Domain Admins etc are stored in the Admin workstations OU. All the other domain users their workstations are stored in the User workstations OU. Now you need to create a new GPO and roll it out on the OU ‘’Users workstations’’ with the following settings: Deny access to this computer from the net- work Domain Admins, Enterprise Admins, Schema Admins, Local account Deny log on as a batch job Domain Admins, Enterprise Admins, Schema Admins Deny log on as a service Domain Admins, Enterprise Admins, Schema Admins Deny log on locally Domain Admins, Enterprise Admins, Schema Admins Deny log on through Remote Desktop Ser- vices Domain Admins, Enterprise Admins, Schema Admins
  15. 15. 6 – Ensure no unauthorized user can modify GPO settings A GPO contains different settings that system administrators can create. These settings can be applied on workstations, servers or domain controllers for example. If an unauthorized person is able to modify a GPO or link a new exisiting GPO to it. All bets are off for those workstations, servers or DC’s. Here we can see that Dumfries can modify the GPO settings of a Domain Controller
  16. 16. But there’s also another way, which is not editing a GPO, but linking a new (arbitrary) GPO to an OU. Users in Group Policy Creator Owners or just adding a user to the Group Policy Ob- jects container in GPMC. Allow us to create a new GPO, but that does not mean that we’re also inmediately can link it to an OU. Here we can see that a user Ben Smith can create new GPO’s in the domain. And here we can see that Ben Smith has GenericWrite permission on the Domain Con- trollers OU. So that means that Ben Smith is able to modify the gpLink attribute and can link his own created malicious GPO to the Domain Controller.
  17. 17. Recommendation First thing is to controll all your exisiting GPO’s and to look for who is able to modify the GPO settings of my Domain Controller and is he or she actually allowed to do so? This can be done by looking at the delegation tab of an GPO. The second thing is to control who’s in Group Policy Creator Owners or who’s in the Group Policy Objects in GPMC that is able to create a GPO. And then you need to scan all the ACL permissions that has been set on OU’s to see if the user has permissions such as: Full control, Write, Modify permission, Modify owner. Since all of these permissions can leverage to GenericWrite aka Write all properties and that is enough to link a new GPO to an OU. Look for the specific OU’s where all the servers, workstations and domain controllers has been stored.
  18. 18. 7 – Look for (exploitable) ACL’s on an objects  Which permissions can lead to an account take-over?  Which permissions can configure insecure account options?
  19. 19.  Which permissions can lead to modification of a group?  Which permissions can grant authentication access to computer ob- ject?
  20. 20.  What to look for? - Users - Groups - OU - Computers  Example of account take-over on an Domain Administrator Here we can see that Dumfries can reset the password of Martin and take-over the ac- count of Martin to become Domain Admin.
  21. 21. Not only Dumfries can take-over the account of Martin, but also Ben Smith. Ben has the ‘’Modify permission’’ on the object. This gives Ben the opportunity to grant himself every right, such as ‘’Reset password’’ or even ‘’Full control’’ to basically just take-over the account of Martin as well.
  22. 22.  Example of Shadow Admins Here we can see that Dumfries is not part of Domain Admins, but he has the Generic- Write permission that allows him to add/remove himself in the Domain Admins group.
  23. 23.  Who has the ownership of an object? Here we can see that Domain Users has the ownership of the Domain Admins group, and this means that everyone in the domain, can modify the group and add him/herselves into the group. But there’s another user with ‘’Modify owner’’ permission and can take-ownership of the object and become owner of it. In this case. Alice Ciccu could become owner of the object and modify the Domain Admins group.
  24. 24.  Who can take-over multiple accounts once? By having delegated permissions on an OU, which contains users or groups. Allows you to modify multiple objects that are stored in the OU Adam his permission has been delegated on the Users OU, which contains the ‘’Reset password’’ permission on descedant user objects. Allowing him to reset everyone his password in the OU, except from a high-privileged group, such as Domain Admin.
  25. 25.  Who can modify the membership of multiple groups? Here we can see the OU ‘’Users’’, unfortunately someone with ‘’Modify permission’’ can modify the high-privileged groups, but the rest is possible. Here you can see that SDNMGT has ‘’Full control’’ on the OU ‘’Users’’ and can modify most of the groups in it.
  26. 26. Recommendation Use BloodHound to scan for exploitable ACL’s on objects, which may lead to different escalation paths that can lead to Domain Admin for example. Monitoring different ACL’s is very important, because these ACL’s can lead to account take-overs, group modification etc. And if you already busy with scanning different ACL’s. Also look for the different group nesting that can lead to Domain Admin.
  27. 27. 8 – AD Root & Delegated Permissions Ensure that the AD Root is kept by default and no modifications has been set on that ob- ject, like delegating permissions on the AD root for example. This is an example, which Exchange Trusted Subsystem has ‘’Modify permission’’ on the AD Root. Which means that every user in that group could change his permission and compromise the entire the domain through the DSRS protocol, which can be used to syn- chronize credentials remotely from a workstation. Modify permission can lead to  Replication Directory Changes  Replication Directory Changes All The permissions that are required to do an DCSync attack and synchronize every user his credentials in the domain.
  28. 28. Recommendation  Ensure that Administrators is the owner of the AD Root object.  Ensure that no user or group has been added to the AD Root object This is an example of an unauthorized users with the DCSync permissions on the AD Root. When a user has been added to this object. Look what’s the reason behind it, because it is very rarely that this needs to be happen. NOTE: Azure AD Connect account needs the following two permission above to make it work. This account is not a false positive then, but you need to protect it like an Domain Ad- min.
  29. 29. 9 – Scan for insecure account options The following parameters on accounts should be avoided, because they are insecure and are increasing a security risk, which can then be used to exploit it.  Store password using reversible encryption Storing encrypted passwords in a way that is reversible means that the encrypted pass- words can be decrypted. This is barely required, but there are legacy applications that require this. Please avoid using this kind of applications and especially the configura- tions. Legacy is often already vulnerable.
  30. 30.  Do not require Kerberos preauthentication Without Kerberos Pre-Authentication a malicious attacker can directly send a dummy request for authentication. The KDC will return an encrypted TGT and the attacker can brute force it offline. Upon checking the KDC logs, nothing will be seen except a single request for a TGT.
  31. 31.  Password not required This option needs to be changed at userAccountControl attribute and everyone with GenericWrite can do this. When the userAccountControl attribute has been set on 544. An user can reset his password to an <empty> password one. And even authenticate without having a pass- word.
  32. 32.  Password never expires The password of an user will never expire and could be against the password policy of an organization.
  33. 33.  Account is disabled and password is not required When changing the userAccountControl attribute to 546 an account will be disabled and password is not required.
  34. 34. Recommendation: Avoid using all of these insecure parameters, because it is increasing a security risk for your organization. Everything can be automated through PowerShell.
  35. 35. 10 – Unconstrained Kerberos Delegation A server that is trusted for Unconstrained Kerberos Delegation is allowed to imperson- ate almost any user to any service in the network. If a server that is trusted for Unconstrained Kerberos Delegation has been compro- mised by an attacker. He or she will have access to all the TGT’s of the users that have been using that service. This configuration means that a server is allowed to trust for Unconstrained Kerberos Delegation
  36. 36.  Who can enable servers for trusting Unconstrained Kerberos Delegation? By default users or groups with ‘’Full control’’ can enable this configuration.
  37. 37.  Who can enable multiple servers to Unconstrained Delegation? Here we can see that Paul West has ‘’Full control’’ and can enable this setting on all servers in the OU.
  38. 38. 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.
  39. 39. Recommendations  Avoid using Unconstrained Kerberos Delegation anymore  Ensure that all AD admins have the “Account is sensitive and cannot be delegat- ed” checkmark enabled.  Look for users & groups who can enable the Unconstrained Kerberos Delegation and see if you can remove the permissions from them.  Look at User Right Assignments to see if there have been granted the: Enable this computer for delegation
  40. 40. 11 – Ensure all Admins have “Account is sensitive and cannot be delegated” checkmark enabled 'Account is sensitive and cannot be delegated', ensures that an account's credentials can- not be forwarded to other computers or services on the network by a trusted application. This feature is used to protect high-privileged accounts from authenticating to servers that are trusted for Unconstrained Kerberos Delegation
  41. 41. Recommendation  Ensure that all AD admins have the ‘’Account is sensitive and cannot be delegat- ed” checkmark enabled on their accounts.
  42. 42. 12 – AD admins in Protected Users group 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. These are all the security features of Protected Users
  43. 43. Recommendation:  Make a start with adding user-by-user to the Protected Users group, but don’t add all of them immediately to the group. Test this slowly.
  44. 44. 13 – Rotate the password of the Built-in Administrator every year once This is more of an best practice that should be followed. In my opinion. Built-in Admin- istrator should be disabled, because it is by default part of Domain Admins, which is barely needed. But if you use the account. At least rotate the password once every year with a strong password.
  45. 45. Recommendation:  Rotate the Built-in Administrator account password once every year to a strong password.
  46. 46. 14 – Rotate the password of KRBTGT twice a year The KRBTGT is a local default account that acts as a service account for the Key Distri- bution Center (KDC) service. 99% of all the time. This account has never been resetted in an environment, and attack- ers are taking advantage of this, because of that. Attackers can use the KRBTGT to create Golden Tickets and remain persistence in the network. So even if you reset every account in the domain and you didn’t resetted the KRBTGT twice. An attacker would still have persistence.
  47. 47. Recommendation:  Rotate the password of the KRBTGT twice.  Log on the global DC  Reset the password of the KRBTGT once  Wait 24 hours for the replication, otherwise stuff might break  Log back to the DC and reset the password twice. KRBTGT will automatically reset the password to a strong one, so it does not really mat- ter, which password you pick.
  48. 48. 15 – Service accounts needs to have a 25+ password length Kerberoasting is an effective way to crack (service) accounts their password without hav- ing any elevated rights in the domain. An attacker can request service tickets from the DC of accounts with a servicePrincipal- Name and crack those passwords offline without any detection. This doesn’t need per se be an service account. It can also just a normal account that someone has set an SPN value on it. Users with GenericWrite on user objects can set SPN’s for example.
  49. 49. Recommendation  Everytime when a service account is created. An 25+ password length needs to enforced on it, otherwise an attacker can easily crack it offline if the password is weak.
  50. 50. 16 – Only allow service accounts logging on specific services Service accounts often have high-privileged in the domain, they may not immediately be a ‘’Domain Admin’’, but they have rights on SQL servers for example. If an service ac- counts logs into a lower trusted workstation. Credentials of the service accounts gets ex- posed in the memory of the connected system.
  51. 51. Recommendation:  Only allow service accounts to log on specific services, which can be done through the ‘’Log On To’’
  52. 52. 17 – Ensure Account Operators, Server Operators and Print Operators is empty The following groups that have been mention should not be used according to Microsoft “Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including those of users, lo- cal groups, and global groups, and members can log in locally to domain controllers.” “Members in the Server Operators group can administer domain servers. This group exists only on domain controllers. By default, the group has no members. Memebers of the Server Operators group can sign in to a server interactively, create and delete network shared resources, start and stop services, back up and restore files, format the hard disk drive of the computer, and shut down the computer. “ “Members of Print Operators can manage, create, share, and delete printers that are connected to domain controllers in the domain. They can also manage Active Directory printer objects in the domain. Members of this group can locally sign in to and shut down domain controllers in the domain.”
  53. 53. Recommendation  Don’t use the groups that have been listened above. If you have members in Ac- count Operators, Server Operators and Print Operators. This is a finding  If you have a lot of users in Backup Operators who are not dedicared to back-up AD & DC. This is also a finding  Ensure that no ‘’exploitable’’ ACL’s has been set on these groups that allows someone modify the group membership of it. NOTE: Keep Backup Operators limited and only allow users who are really dedicated to make AD/DC back-ups. Don’t use it to back-up workstations for example.
  54. 54. 18 – Ensure Pre-Windows 2000 Compatible Access is empty Members of the Pre–Windows 2000 Compatible Access group have Read access for all users and groups in the domain. This group is provided for backward compatibility for computers running Windows NT 4.0 and earlier. This group can bypass specific security measures that aren’t allowed to read for normal users. This is by default who the members of the group are. Leave it like this, and don’t touch it.
  55. 55. Recommendation:  Don’t add any user or group to the Pre-Windows 2000 Compatible Access
  56. 56. 19 – Ensure that Domain Controllers group only have DC’s lis- tened The Domain Controllers group includes all the Domain Controllers in the environment. By defaut this group has the DS-Replication-Get-Changes-All permission on the AD Root. If an user is added to this group. He or she will be able to do a DCSync attack and re- motely request all the NT(LM) hashes of users in the domain.
  57. 57. Recommendation  If a user is added to the Domain Controllers group. This is a finding  Here you can see that Paul West is part of the group, which means it is a finding, because only Domain Controlers should be member of the group.  Ensure that only DC’s are listened  Make sure that no users/group have been added to the DACL with exploitable ACL’s on this group
  58. 58. 20 – Remove the adminCount(=1) from former privileged us- ers Every user that is or was part of an high-privileged group, such as Domain Admin or Ac- count Operators for example will get his/her adminCount changed to 1. If that specific user has been removed from a high-privileged group. AdminCount(=1) still exist on the attribute of the user, so what would happened? If someone wants to apply certain settings on that user, it get’s blocked, because the in- herited permission is disabled on high-privileged user, because it is protected by the Ad- minSDHolder. If you change the attribute to 0 again for the user, inherited permission will still be disa- bled, but SDPROP knows that isn’t a high-privileged user anymore, and then you can apply the settings. It was something like that, not sure if I’ll explain it well, but feel free to correct me!
  59. 59. Recommendation:  Scan for all adminCount(=1) attribute in the environment and see if there are some non-privileged user that were part of DA in the past of the environment, still have their adminCount attribute set to 1.  Remove the adminCount(=1) from those users and change it back to 0
  60. 60. 21 – Reduce Enterprise Admins, Domain Admins, Administra- tors You pretty know that moment, when you have too much Domain Admins, because they need to do some AD admin related task? In Active Directory, you can delegate every permission in the domain, by granting non- admin user(s) the right privileges to do AD admin tasks, without being Domain Admin or Enterprise Admin. Here are a few examples of AD-admin tasks:  Managing and authorizing/unauthorizing to DHCP servers  Managing Certificate Authority  Reading event logs on the Domain Controller  Creating a Group Policy Object and linking it to an OU All of these related tasks can be delegated without having Domain Admin. Everyone wants to be DA, but this is a incredible high security risks.
  61. 61. Recommendation  Avoid using Domain Admin. You should not have more than 3, because this can pretty easy to delegate it.  It’s time to enforce least-privilege, instead of writing down that you do it.  Take a look at here on how you can do it: 
  62. 62. 22 – Reduce Group Policy Creator Owners, Remote Desktop Users and DnsAdmins The following groups have certain kind of permissions that can elevate their privileges.  Users who are part of the Group Policy Creator Owners and also have Write properties permission on an OU, can link an (arbitrary) GPO to it.  Users who are in Remote Desktop Users can log on most workstations and serv- ers.  DnsAdmins has GenericWrite permission on the DNS Server object and can ele- vate privileges to an Domain Admin user.
  63. 63. Recommendation: (Example)  If an user wants to authenticate to just one or two server, don’t randomly add it to the Local Admin group of those servers or add it in the Remote Desktop Users  Grant the user the ‘’Allowed-to-authenticate’’ permission to that server.  For all other examples on how you can delegate permission.  Take a look at here:  If you would add the user to the Remote Desktop Users group. It would have access to plenty of other servers and workstations as well, which does not follow the ‘’principle of least-privilege’’
  64. 64. 23 – Reduce Local Admin and other Local Groups There are some LOCAL groups on workstations that can be discovered through Comput- er Mangement → Local Users and Groups → Groups These groups that are in red can log on the workstation of Elise. It’s always recommended to reduce down Local Admins on a workstations, because it can increase a security risk, since they can log on to the workstations and run code on it for example. Same goes for Backup Operators. If you use the LOCAL, Backup Operators group. It can log on your workstation and back-up it. And who is able to RDP into your workstation? Take a look at the LOCAL, Remote Desktop Users group.
  65. 65. Recommendation  Reduce down the amount of Local Admins on a workstation.  Sure, you will need members being part of it to deploy software, but members such as SQL Admins have nothing to do on workstations.  Make sure that LOCAL ‘’Backup Operators’’ group is empty, because otherwise this is a finding  LOCAL ‘’Remote Desktop Users’’ should be limited as well.
  66. 66. 24 – Ensure no unauthorized users/group have GenericWrite on the DNS Server Object A researcher discovered that you could leverage from DnsAdmins to Domain Admins if you had Write permission on the DNS server object. Source: in-one-line-a0f779b8dc83 By looking at the CN=MicrosoftDNS The following groups have write permission on the DNS server object: Domain Admins, Enterprise Admins, Administrators, DnsAdmins, ENTERPRISE DOMAIN CONTROLLERS
  67. 67. Here we can see that DnsAdmins has the Write permission on the DNS Server object in AD. These are all the tasks that you can do on the DNS server object. After asking around to other security professionals they also told me that it is very rare that someone is doing all these tasks everyday.
  68. 68. Recommendation  Reduce DnsAdmin as it is rarely that someone is making changes on the DNS server objects etc.  Look for suspicious users or groups that have been added to the DACL of the DNS server object  Make sure that SYSTEM has the ownership of the DNS object.  Users often need to manage DNS records, and not being able to make modifica- tion to the DNS server object.  Take a look at this on how you can delegate permission, so users still can manage the DNS Records: 
  69. 69. 25 – Ensure that the AdminSDHolder is not modified AdminSDHolder object manages the access control lists of members of built-in privi- leged Active Directory groups. If an user has compromised a high-privileged user and adds the user or group to the Ad- minSDHolder object. It can be used to remain persistence. Via the SDPROP it will scan the environment every 60 minutes to see if any high- privileged user was modified, and if that was the case. It will restore it like it have always been. Example: A Domain Admin user gets compromised and the attacker adds the user to the Ad- minSDHolder object. If someone now removes that Domain Admin from the group, SDPROP will put the user back to the group in 60 min.
  70. 70. Recommendation  Remove suspicious users or group from the AdminSDHolder  If an user or group has GenericAll & GenericWrite on the AdminSDHolder object and you couldn’t explain why this was the case. You might have a trouble.
  71. 71. 26 – Ensure dsHeuristics has not been modified dsHeuristics is an attribute that can exclude high-privileged groups in Active Directory, so AdminSDHolder won’t protect those users anymore. This can be done on the following groups:  Account Operators  Backup Operators  Server Operators  Print Operators
  72. 72. Recommendation  Make sure this has been set to <not set>, but if you have an value that has been set. This is a finding
  73. 73. 27 – Remove all sIDHistory after migration SID History is an Active Directory (AD) user account object attribute that facilitates the authorization process when you migrate Windows domains. Source: Attackers can elevate their privileges and impersonate users by harvesting the sIDHistory attribute of users in the domain.
  74. 74. Recommendation  Take an AD snapshot first, before you make are going to remove all the sIDHistory attributes in the domain  Here is a tutorial on how you can remove all the sIDHistory after you have com- pleted your migiration 
  75. 75. 28 – Detect malicious behaviour in Active Directory In Active Directory, there are different use-cases that you should be alerting and monitor- ing in your SIEM. All of these changes can lead to exposure of your AD. A few use-cases: 1. Unconstrained Kerberos Delegation is enabled 2. ‘’Password is not required’’ parameter has been set on an user 3. ‘’Do not require Kerberos pre authentication’’ is enabled on an user for AS-REP Roasting. 4. User or group is added to the AdminSDHolder object 5. User is added to the Default Domain Controlers Policy GPO 6. User is linking an GPO to a OU 7. Password policy is modified 8. DefaultAccount & Guest are enabled 9. Monitor when a user is added to Domain Admin, Enterprise Admins, Schema Admins, Administrators
  76. 76. 28 – Unconstrained Kerberos Delegation is enabled Event ID 4742 Description A computer account was changed  User ''Dumfries'' enabled Unconstrained Kerberos Delegation on a server.  The SRV01 is the server that has been affected  The following attributes gives a sight that it has been enabled
  77. 77. 28 - “Password is not required” parameter has been set on an user object Event ID 4738 Description A user account was changed  User Dumfries modified the userAccountControl attribute of an user  Adam Barr is the affected user that was modified  The following attributes gives a sight that password was disabled for Adam Barr
  78. 78. 28 - “Do not require Kerberos pre authentication” is enabled AS-REP ROASTING Event ID 4738 Description A user account was changed  Dumfries enabled "Do not require pre Kerberos authentication"  Alice Ciccu is the affected user that was modified  Attributes that gives a sight it was enabled
  79. 79. 28 – User or group is added to AdminSDHolder Event ID 4662 Description An operation was performed on this object  Dumfries added himself in AdminSDHolder object for persistence  Here we can see that the object AdminSDHolder was affected  Here we can see that WRITE_DAC gives a sign that permissions were modi- fied on that object.
  80. 80. 28 – User is added to the Default Domain Controllers Policy GPO Event ID 4662 Description An operation was performed on an object  Dumfries modified the Default Domain Controllers Policy  Default Domain Controllers GPO has in every environment the same Object- GUID – And in the following screen. We are able to see that the Default Do- main Controllers policy was modified.  Here we can see the WRITE_DAC – Which means that the permissions has been modified on the GPO.
  81. 81. 28 – User is linking a GPO to an OU Event ID 4662 Description An operation was performed on an object  Here we can see that the OU=Domain Controllers has been modified  Write Property is listened, because the gpLink attribute gets modified.
  82. 82. 28 – Password policy is modified Event ID 4739 Description Domain Policy was changed  Dumfries modify the password policy on the AD Root  Password length is changed to zero.
  83. 83. 28 – DefaultAccount & Guest are enabled By default there are two accounts that have an empty password. Which are De- faultAccount & Guest Enabling these accounts – Allows someone log on those accounts and perform LDAP queries for reconnaissance for instance. These accounts are often overlooked, because enabling an account is not something you want to monitor, but you should make an exception for these two accounts.
  84. 84. Event ID 4772 Description A user account was enabled  LabAdmin enabled an account  Here the DefaultAccount has been enabled.  Now the attacker can log on DefaultAccount without password.
  85. 85. Event ID 4772 Description A user account was enabled  Here we can see the Guest account is enabled
  86. 86. 28 – User was added to the Domain Admins group Event ID 4728 Description A member was added to a security enabled group Ben Smith from the OU=Managed-Objects was added. Here we can see that Ben Smith was added to the Domain Admins group
  87. 87. 29 – Disable legacy protocols Legacy protocols on workstations should be disabled, because they are increasing a secu- rity risk.  LLMNR  NETBIOS  WPAD  WDIGEST Disable LLMNR on all the endpoints in the network, because otherwise attackers can harvest credentials with tools such as Responder
  88. 88. Disable NetBIOS on all workstations, because it’s super legacy and insecure as well. NetBIOS needs to be disabled on all adapters, but test this first on a workstation.
  89. 89. Disable WPAD on all workstations, because attackers can use this insecure protocol for MITM attacks.
  90. 90. Disable WDIGEST on all Windows 7 workstations, because this protocol had a design issue in the past that stores credentials in plain-text in memory.
  91. 91. 30 – Deploy Microsoft LAPS on every domain joined computer 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 an 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: solution-laps/
  92. 92. Recommendation  Deploy Microsoft LAPS on every domain joined computer  Only allow certain kind of users having read permission to those two attributes
  93. 93. 31 – Deny workstation-to-workstation communication It is highly unusual for network users to need to communicate with other users their workstations. Configure each workstation to use a local firewall to block incoming Windows network traffic (139/TCP, 445/TCP and 137/UDP) from any workstation subnet. Enabling workstation-to-workstation communication can allow a network intruder to easily spread to multiple systems and establish an effective “beach head” within the net- work. If the workstation from Elise can do a succesful ‘’Ping’’ request to the workstation from Bob. This is a finding, and you have a lateral movement problem. If Elise is doing a ‘’Ping’’ request to the workstation from Bob and she is receiving a ‘’Request timed out’’. This is good, because you don’t allow workstations to talk to each other.
  94. 94. Recommendation  You can block inbound SMB to endpoints, because workstations do not need to talk to each other.  But you can make an exception and that is enabling SMB for File servers
  95. 95. 32 – Ensure Inheritance permission is enabled on non- privileged objects Here we can see that the group Domain Admin – Inheritance permission has been disa- bled to prevent modification to the group.
  96. 96. Here we can see the group ‘’Key Admins’’ that has Inhertinace permission enabled So users with the right permission on the OU=Users can add users to the group for exam- ple. Now when we enable Inheritance permission on Key Admins. Users with the right per- mission on the OU of Users won’t be able to add someone to the group.
  97. 97. As you can see. Dumfries has Full control on the OU=Users. Despite his ‘’Full control’’ permission. He can’t add someone to Key Admins
  98. 98. Recommendation  Discover all objects that have Inheritance permission enabled and look if this was supposed to be right. Otherwise you can’t reset the password on User X if inher- itance was enabled for him or her.
  99. 99. 33 – Final conclusion There’s still a lot of legacy in Active Directory, such as the wrong delegated permissions in the past. Nobody were bothering to take a look at what kind of permissions has been set on objects, but it is time to do now. You can use tools such as BloodHound to discov- er escalation paths that might lead to AD admin. Besides of that, many companies still have way too much Domain Admins, just for only small daily tasks. Everything can be delegated in the domain, and it absoluely should. Take a look at the active-directory for in-depth examples on how you can realize this. Detecting malicious behavior is something that you should be aware as well. If you don’t detect any kind of stuff, you never will notice if an ‘’exposure’’ has been created, be- cause someone enabled unconstrained kerberos delegation for example. And last but not least, There are best practices that you need to follow and that is deploying Microsoft LAPS, deny workstation-to-workstation communication, reducing Domain/Local Admins etc.