HTBA : Active Directory Intro

Why AD ?

AD is a directory service for Windows networks; it is made for centralized management of users, computers, groups, network devices, file shares, group policies, devices, trusts. It provides authentication and authorization within a domain. Its security flaws come from its backwards-compatibility, AND the fact that everything is not secure by default.Is is basically a read-only database accessible to everyone - anyone can enumerate a directory.

95% of companies run AD, making it a prime target. Any vuln on AD is interesting and exploiotable, since a simple AD user account allows enumerating the whole domain.

The goal here is to learn the foundations of AD enumeration and attack. We will get to know the structure and function of AD, its objects, user rights, tools, processes, etc.

History

Comes from the X.500 directory (same as LDAP !). Introduced in the 90s and came to be with WinServ 2000. LDAP and Kerberos were adopted later. WinServ 2003 added forests, allowing admins to create containers for domains, users, etc. ADFS came with WinServ 2008 to provide SSO - users can access applications with a single login across organizational boundaries. ADFS is claim-based identity, meaning it identifies users by a set of claims related to their identity, which are then packaged in a token.

Winserv 2016 brought cloud migration, security enhancement, user access monitoring... And also Group Managegement Service Accounts (here) which offers a more secure way to run automated tasks - often recommended against "kerberoasting". It also saw the release of AAD Connect, pushing more and more towards the cloud.

AD and its companions (Exchange...) suffer regularly from misconfigurations and flaws. Running AD in an org requires to stay up-to-date and is a lot of work (I know about it !). AD is hard to maintain and a requirement for a lot of people, especially on-prem.

Over the years

Since 2014, many tools relating to AD in the research emerged. AD and AzureAD form a large surface; flaws are being discovered regularly such as noPac in dec. 2021.

A few important tools when it comes to AD and security, taken from the timeline (from oldest to newest), would be:

• Responder - used for poisoning, obtaining password hashes, perfom SMB relay attacks, etc.
• Impacket is a collection of Python classes used for working with network protocols, which is a staple in pentesting. Useful with AD.
• Bloodhound for visualizing attack paths.
• ACL attacks
• Rubeus toolkit for attacking Kerberos
• PingCastle for auditing
• More kerberoasting
• ZeroLogon attack (2020) allowing DC impersonation.
• PrintNightmare - remote code execution; Shadow Credentials - privilege escalation; noPac - gain domain control. All three from 2021

Structure

A directory Service such as ADDS (AD Domain Services) gives an org ways to store data and make them available. AD stores information and manages the rights needed to access them. AD flaws and misconfigurations can often be used to get a foothold in an infra, move laterally and vertically within a network, gain access to protected resources.

A basic AD user with no added privileges can enumerate most objects within AD, including :

• Computers
• Users
• Group Information
• OUs
• Default Domain Policy
• Functional Domain Levels
• Password policy
• GPOs
• Domain Trusts
• ACLs

We must understand the basics of set up and admin of AD before attacking.

AD is a tree structure with a forest at the top, containing one or more domains. Domains can have nested subdomains. A forest is the security boundary in which all objects are under administrative control; each forest containing one or more domains. A forest has built-in OUs, such as Domain Controllers, Users, Computers... and admin-made OUs. OUs contain sub-OUs and objects, allowing for Group Policies.

Here is a simplistic example:

INLANEFREIGHT.LOCAL/
├── ADMIN.INLANEFREIGHT.LOCAL
│   ├── GPOs
│   └── OU
│       └── EMPLOYEES
│           ├── COMPUTERS
│           │   └── FILE01
│           ├── GROUPS
│           │   └── HQ Staff
│           └── USERS
│               └── barbara.jones
├── CORP.INLANEFREIGHT.LOCAL
└── DEV.INLANEFREIGHT.LOCAL

Here, INLANEFREIGHT.LOCAL is the root domain and contains subdomains (ADMIN, CORP, DEV), as well as other objects. It is common to see multiple domains or forests linked via trust relationships in orgs that perform a lot of acquisitions. It is often quicker to add a trust relationship to a newly acquired domain than recreating everything. Domain trusts introduce a lot of security issues if improperly administered.

2 forests can have a bidirectional trust relationship, meaning they both can access the other's resources. Each forest can have child domains.

Here, the 2 forests have a bidirectional trust between their roots; inlanefreight.local can access freightlogistics.local's resources, and vice-versa. But the child domains from forest A do not necessarily have a trust relationship with the forest B's children. A user from admin.dev.inlanefreight.local could not authenticate as such on dev.freightlogistics.local.

Terminology

A few common ones

• Object : any resource present in an AD : OU, printer, computer, etc
• Attributes : Every object in AD has a set of attributes used to define its characteristics. All attributes have a corresponding LDAP name that can be used (displayName for Full Name, for ex.)
• Schema : the schema is the blueprint of the AD environment : what types of objects can exists, and their attributes. Each object has mandatory and / or optional attributes to set. When an object is created from a class, it is "instanciated".
• Domain : logical group of objects. Domains can be idnependent or have trust relationships between them.
• Forest : Collection of domains. Topmost container and contains all AD objects.
• Tree : Collection of domains that begins with a root domain. A forest is a collection of AD trees. Each domain in a tree has a boundary with other domains in the tree, and the tree elements have a parent-child trust relationship.
• Container : objects that hold other objects and have a defined place in the subtree.
• Leaf : do not contain other objects and are at the end of the subtree.
• GUID : Globally Unique IDentifier. A unique 128-bit value assigned when a domain user or group is created. Unique across the org, like a MAC address. Every single object created by AD has a GUID, stored in the objectGUID attribute. When querying for an AD object, it is an attribute we can use in Powershell for example. Most precise value to use to look for smthing.
• Security Principals : anything the OS can authenticate, including users, computer accounts, and even threads that run in the context of a user or computer account (eg a service running with a service account). We can also have local users and groups, managed not by AD but by the SAM (Security Accounts Manager).
• SID (Security Identifier) : Unique identifier for a security principal or security group. Every account, group, process has one, issued by the DC and stored in a secure DB. SIDs are used only once; even if the security principal is deleted, this SID can't be reused. When a user logs in, the system creates a token containing their SID, rights, SIDs of their groups. This token is used to check the user's rights when performing an action. There are also well-known SIDs that are used to identify generic users and groups. These are the same across all operating systems. An example is the Everyone group.
• DN (Distinguished Name) : Full path of an object in AD (like LDAP), like " cn=bjones, ou=IT, ou=Employees, dc=inlanefreight, dc=local". Must be unique in their directory.
• RDN (Relative DN) : A DN is made of multiple RDNs (cn=bjones is an RDN). RDNs must be unique in their OU.
• sAMAccountName : user's logon name. Must be unique and < 20 characters : johnsmith for example.
• userPrincipalName : another way to identify a user in AD. has a prefix (account name) and suffix (domain). eg johnsmith@themmatrix.local
• Global Catalog (GC) : a DC that stores copies of ALL objects in the forest (full copy in their domain, partial with the rest of the forest). Standard domain controllers hold a complete replica of objects belonging to its domain but not those of different domains in the forest. GC allows finding info about any object in any domain of the forest. Must be enabled on the DC and allows authentication and object search.
• Read-Only DC (RODC) : An RODC has an AD database, but no AD account passwords are cached on it. No changes can be pushed through it, its SYSVOL, or DNS. They also are Read-Only DNS.
• Replication : happens in Ad when AD objects are updated and transferred.When a DC is added, connection objects are added by the KCC (Knowledge Consistency Checker - present on all DC) service to handle replication.
• Service Principal Name (SPN) : uniquely identifies a service instance. Used by kerberos for service to logon account association.
• GPO (Group Policy Object) : virtual collection of policy settings. Each GPO as a GUID. Can contain local or AD settings, can be applied to users or computers, or defined by OU.
• ACL : Collection of Access Control Entities (ACEs) that apply to an object
• ACE : identifies a trustee (user, group, logon session) and lists access rights that are allowed, denied, audited for the given trustee.
• Discretionary Access Control List (DACL) : DACLs define which security principles are granted or denied access to an object; it contains a list of ACEs. When a process tries to access a securable object, the system checks the ACEs in the object's DACL to determine whether or not to grant access. If an object does NOT have a DACL, then the system will grant full access to everyone, but if the DACL has no ACE entries, the system will deny all access attempts. ACEs in the DACL are checked in sequence until a match is found that allows the requested rights or until access is denied.
• SACL (System ACL) : Allows admins to log access attempts made to secure objects. ACEs specify the type of atttempts that are to be recorded.
• FQDN : Same as with DNS.
• Tombstone : AD Container holding deleted objects. A deleted object remains for a period know as "Tombstone Lifetime", with its isDeleted attribute set to TRUE. After that it is deleted. Generally between 60-180 days.If an object is deleted in a domain that does not have an AD Recycle Bin, it will become a tombstone object. When this happens, the object is stripped of most of its attributes and placed in the Deleted Objects container for the duration of the tombstoneLifetime. It can be recovered, but any attributes that were lost can no longer be recovered.
• AD Recycle Bin : First introduced in Windows Server 2008 R2 to facilitate the recovery of deleted AD objects. When the AD Recycle Bin is enabled, any deleted objects are preserved for a period of time, facilitating restoration if needed. Sysadmins can set how long an object remains in a deleted, recoverable state. If this is not specified, the object will be restorable for a default value of 60 days. The biggest advantage of using the AD Recycle Bin is that most of a deleted object's attributes are preserved.
• SYSVOL : The SYSVOL folder, or share, stores copies of public files in the domain such as system policies, Group Policy settings, logon/logoff scripts, and often contains other types of scripts that are executed to perform various tasks in the AD environment. The contents of the SYSVOL folder are replicated to all DCs within the environment using File Replication Services (FRS).
• AdminSDHolder : This object is used to manage ACLs for members of built-in groups in AD marked as privileged. It acts as a container that holds the Security Descriptor applied to members of protected groups. The SDProp (SD Propagator) process runs on a schedule on the PDC Emulator Domain Controller. When this process runs, it checks members of protected groups to ensure that the correct ACL is applied to them. It runs every hour by default
• dsHeuristics : string value set in the Directory Service object used to define multiple forest-wide configuration settings. One of these settings is to exclude built-in groups from the Protected Groups list. Groups in this list are protected from modification via the AdminSDHolder object. If a group is excluded via the dsHeuristics attribute, then any changes that affect it will not be reverted when the SDProp process runs.
• adminCount : attribute determining wether or not the SDProp process protects a user. If 0 or unspecified, the user is not protected.

Attackers often look for accounts with adminCount to 1 as a target.

• AD Users and Computers (ADUC) : GUI Console used for AD management (users, groups, computers, contacts). Can be replaced by Powershell commands.
• ADSI Edit : GUI tool used to manage objects in AD. More complete than ADUC, can be used to manipulate attributes, and manipulate objects. Use with caution !
• sIDHistory : attribute holding any SID that an object received in the past. Usually used in migrations so a user can maintain the same level of access when migrated from one domain to another. This attribute can potentially be abused if set insecurely, allowing an attacker to gain prior elevated access that an account had before a migration if SID Filtering (or removing SIDs from another domain from a user's access token that could be used for elevated access) is not enabled.
• NTDS.DIT : The NTDS.DIT file can be considered the heart of Active Directory. It is stored on a Domain Controller at C:\Windows\NTDS\ and is a database that stores AD data such as information about user and group objects, group membership, and, most important to attackers and penetration testers, the password hashes for all users in the domain. Once full domain compromise is reached, an attacker can retrieve this file, extract the hashes, and either use them to perform a pass-the-hash attack or crack them offline using a tool such as Hashcat to access additional resources in the domain. If the setting Store password with reversible encryption is enabled, then the NTDS.DIT will also store the cleartext passwords for all users created or who changed their password after this policy was set. While rare, some organizations may enable this setting if they use applications or protocols that need to use a user's existing password (and not Kerberos) for authentication.
• MSBROWSE : Microsoft Networking Protocol used in early versionof Windows-based LANs. It was used maintain a list of resources available on the network. Today, MSBROWSE is largely obsolete and is no longer in widespread use. Modern Windows-based LANs use the Server Message Block (SMB) protocol for file and printer sharing, and the Common Internet File System (CIFS) protocol for browsing services.

FSMO roles

When having mutliple DCs, they used to fight over which one makes changes, which was an issue. Then Microsoft implemented the system of having a master DC that made all the changes, which solved it but was a SPOF. To resolve it, they introduced Flexible Single Master Operation roles. They allow DCs to continue authenticating users and grant permissions without interruption. There are 5 roles:

• Domain Naming Master and Schema Master (1 of each per forest)
• Relative ID (RID) Master, 1 per domain
• Primary Domain Controller (PDC) Emulator, 1 per domain
• Infrastructure Master, 1 per domain.

These roles are assigned to the first DC in the forest root in a new forest. Each time a new domain is added to a forest, only the RID master, PDC emulator and Infra Master are assigned to the new domain. These roles help replication in AD run smoothly and ensure that critical services are operating. They can be transferred as needed. More on them later.