Step 9: Introduction to Active Directory

Hello again everyone. I’m currently in work, but it’s so quiet I’ve brought my laptop in and been spending my days practising easy boxes and doing some academy work.

Just finished the retired boxes Grandpa and Granny. I did Granny first but the boxes are identical so I didn’t really even bother messing around once the nmap scan was the same. Maybe I missed something but they felt like carbon copies of each other.

I literally did the same initial foothold exploit, then the same privilege escalation (shout out to kitrop0d). Boom, root access and both flags.

I really wanna spend some time fleshing out the fundamental modules in academy regardless at this point if they are directly involved in the bug bounty career path list on academy, so here we go!

Reminder: If you are doing academy yourself there will be SPOILERS FOR THE TASKS. I am doing these blog posts largely for my own benefit remember as a note-taking exercise and writing/log of my progress (minus the boxes I hack, I just Obsidian notes of varying levels of detail there depending how easy it is).

Why Active Directory?

It is a distributed, hierarchical structure that allows for centralized management of an organization’s resources, including users, computers, groups, network devices, file shares, group policies, devices, and trusts. AD provides authentication and authorization functions within a Windows domain environment.

Many of its features are easy to misconfigure due to its backwards compatibility and a lot of the default options are not actually secure. Active Directory (AD) can be generally thought of as a sizeable read-only database accessible by all users in a domain, irrespective of privilege level.

Source: HTB Academy

Roughly 95% of Fortune 500 companies run AD… juicy. Randsomware hackers are increasingly favouring AD as a main avenue of attack as they are easily leverageable into critical AD flaws like PrintNightmare (CVE-2021–34527) and Zerologon (CVE-2020–1472) .

AD Fundamentals

AD Structure

Active Directory Domain Services (AD DS) gives an organisation a way to store directory data, making it available to both standard and admin users within the same network.

AD is a hierarchical tree structure:

INLANEFREIGHT.LOCAL is the root domain with sub-domains of ADMIN.INLANEFREIGHT.LOCAL, CORP.INLANEFREIGHT.LOCAL, and DEV.INLANEFREIGHT.LOCAL.

It is common to see multiple domains (or forests) linked together via trust relationships in organizations that perform a lot of acquisitions. It is often quicker and easier to create a trust relationship with another domain/forest than recreate all new users in the current domain. As we will see in later modules, domain trusts can introduce a slew of security issues if not appropriately administered.

Graphic displaying permissions relationships of two forest (domains)

Task: AD Structure (American Spelling Strikes Again!)

AD Terminology

Object — ANY resource in an AD environment

Attributes — Every object has attributes associated with it. For example, a computer with have a hostname and DNS attribute. All attributes will have an LDAP name used for performing LDAP queries.

Scheme — think of this as the blueprint. Defines what types of objects can exist in an AD environment and their associated attributes.

Domain — group of objects with logical, tree-like connections. Domains operate completely independent of each other but can be linked with trust relationships.

Forest — collection of domains.

Tree — collection of AD domains beginning with a single root domain.

Container — hold other objects or have a defined place in a directory hierarchy.

Leaf — contained at the end of a subtree hierarchy

Global Unique Identifier (GUID) — unique 128-bit value assigned when a domain user or group is created, similar to a MAC address.

Security principles — security principles are domain objects that can manage access to other resources within the domain

Security identifier (SID) — is used as a unique identifier for a security principal or security group. Every account, group, or process has its own unique SID, which, in an AD environment, is issued by the domain controller and stored in a secure database. A SID can only be used once. Even if the security principle is deleted, it can never be used again in that environment to identify another user or group. Here are some well known SIDs.

Distinguished Name (DN) — describes full path to an object in an AD.

sAMAccountName — user’s logon name.

userPrincipleName — another way to identify users in AD. This attribute consists of a prefix (the user account name) and a suffix (the domain name) in the format of bjones@inlanefreight.local. This attribute is not mandatory.

FSMO Roles — Flexible Single Master Operator Roles. I don’t feel like summarising this as it all feels important so quote time:

In the early days of AD, if you had multiple DCs in an environment, they would fight over which DC gets to make changes, and sometimes changes would not be made properly. Microsoft then implemented “last writer wins,” which could introduce its own problems if the last change breaks things. They then introduced a model in which a single “master” DC could apply changes to the domain while the others merely fulfilled authentication requests. This was a flawed design because if the master DC went down, no changes could be made to the environment until it was restored. To resolve this single point of failure model, Microsoft separated the various responsibilities that a DC can have into Flexible Single Master Operation (FSMO) roles. These give Domain Controllers (DC) the ability to continue authenticating users and granting permissions without interruption (authorization and authentication). There are five FMSO roles: Schema Master and Domain Naming Master (one of each per forest), Relative ID (RID) Master (one per domain), Primary Domain Controller (PDC) Emulator (one per domain), and Infrastructure Master (one per domain). All five roles are assigned to the first DC in the forest root domain in a new AD forest. Each time a new domain is added to a forest, only the RID Master, PDC Emulator, and Infrastructure Master roles are assigned to the new domain. FSMO roles are typically set when domain controllers are created, but sysadmins can transfer these roles if needed. These roles help replication in AD to run smoothly and ensure that critical services are operating correctly. We will walk through each of these roles in detail later in this section.

Global Catalog (GC) — Domain controller that stores copies of all objects in a forest. This partial storage of objects in other linked branches allows for object search and authorisation.

Read-Only Domain Controller (RODC) — No AD passwords cached here. Also contains a read only DNS server.

Service Principal Name (SPN) — unique identifier for service instance used by Kerberos authentication.

Group Policy Objective (GPO) — virtual collections of policy settings, each with a unique GUID.

Access Control List (ACLs) — ordered collection of Access Control Entities (ACEs) that apply to an object.

ACEs — identifies a trustee and identifies access rights.

Fully Qualified Domain Name (FQDN) — complete name for a computer or host.

Tombstone — container object in AD that holds deleted objects.

SYSVOL — 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).

dsHeuristics — attribute is a string value set on the Directory Service object used to define multiple forest-wide configuration settings.

NTDS.DIT — 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.

Task: Key Terms/Definitions

AD Objects

Task AD Objects

Random note: This is boring (but important I know). I’m gonna go try hacking a box, then One Piece and ice cream. It’s the weekend for me as of writing! Self-care folks…

We’re back. It’s 10am Friday morning, my last Friday in Qatar actually as I’ll be flying back to England one week today! Although I suspect I’ll probably be back in Qatar transiting through flying to Vietnam. For anyone interested, I’m pretty much ready to go. Just need to throw the stuff I have not sold/thrown away into a suitcase(s) and I’m good. Not sure what date we’re flying over to Vietnam just yet, that’ll get confirmed Monday I’m told. But up to now it’s been said somewhere between the 10th-13th is likely.

AD Functionality

Trusts are used to establish a domain-domain or forest-forest authentication. Trusts create a link between the authentication systems of two domains.

This section was largely review of previously mentioned definitions and relatively impractical on a day to day basis information.

Task: AD Functionality

AD Protocols: First up Kerberos

AD requires lightweight directory access protocols (LDAP). Default authentication protocol since Windows 2000. Stateless protocol based on tickets rather than usernames and passwords being transmitted across a network.

Kerberos authentication effectively decouples users’ credentials from their requests to consumable resources, ensuring that their password isn’t transmitted over the network (i.e., accessing an internal SharePoint intranet site). The Kerberos Key Distribution Centre (KDC) does not record previous transactions. Instead, the Kerberos Ticket Granting Service ticket (TGS) relies on a valid Ticket Granting Ticket (TGT). It assumes that if the user has a valid TGT, they must have proven their identity. The following diagram walks through this process at a high level.

Note Kerberos protocol can be enumerated as it uses port 88 (TCP and UDP). This is an easy way to enumerate domain controllers.

DNS

DNS is used to resolve hostnames to IP addresses and is broadly used across internal networks and the internet. Private internal networks use Active Directory DNS namespaces to facilitate communications between servers, clients, and peers.

Forward DNS Lookup

Let’s look at an example. We can perform a nslookup for the domain name and retrieve all Domain Controllers' IP addresses in a domain.

Forward DNS Lookup

PS C:\htb> nslookup INLANEFREIGHT.LOCAL
Server:  172.16.6.5
Address:  172.16.6.5
Name:    INLANEFREIGHT.LOCAL
Address:  172.16.6.5

Reverse DNS Lookup

If we would like to obtain the DNS name of a single host using the IP address, we can do this as follows:

Reverse DNS Lookup

PS C:\htb> nslookup 172.16.6.5
Server:  172.16.6.5
Address:  172.16.6.5
Name:    ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
Address:  172.16.6.5

Finding IP Address of a Host

If we would like to find the IP address of a single host, we can do this in reverse. We can do this with or without specifying the FQDN.

Finding IP Address of a Host

PS C:\htb> nslookup ACADEMY-EA-DC01
Server:   172.16.6.5
Address:  172.16.6.5
Name:    ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
Address:  172.16.6.5

LDAP

Active Directory supports Lightweight Directory Access Protocol (LDAP) for directory lookups. LDAP is an open-source and cross-platform protocol used for authentication against various directory services (such as AD). The latest LDAP specification is Version 3, published as RFC 4511. A firm understanding of how LDAP works in an AD environment is crucial for attackers and defenders. LDAP uses port 389, and LDAP over SSL (LDAPS) communicates over port 636.

Two types of LDAP authentication:

1. Simple Authentication: This includes anonymous authentication, unauthenticated authentication, and username/password authentication. Simple authentication means that a username and password create a BIND request to authenticate to the LDAP server.
2. SASL Authentication: The Simple Authentication and Security Layer (SASL) framework uses other authentication services, such as Kerberos, to bind to the LDAP server and then uses this authentication service (Kerberos in this example) to authenticate to LDAP. The LDAP server uses the LDAP protocol to send an LDAP message to the authorization service, which initiates a series of challenge/response messages resulting in either successful or unsuccessful authentication. SASL can provide additional security due to the separation of authentication methods from application protocols.

LDAP authentication messages are sent in cleartext by default so anyone can sniff out LDAP messages on the internal network. It is recommended to use TLS encryption or similar to safeguard this information in transit.

MSRPC (Microsoft Remote Protocol Control)

Task: Kerberos, DNS, LDAP, MSRPC

NTLM Authentication

LM

LAN Manager (LM) hashes are the oldest password storage mechanism used by the Windows operating system. LM debuted in 1987 on the OS/2 operating system. If in use, they are stored in the SAM database on a Windows host and the NTDS.DIT database on a Domain Controller. Due to significant security weaknesses in the hashing algorithm used for LM hashes, it has been turned off by default since Windows Vista/Server 2008. However, it is still common to encounter, especially in large environments where older systems are still used. Passwords using LM are limited to a maximum of 14 characters. Passwords are not case sensitive and are converted to uppercase before generating the hashed value, limiting the keyspace to a total of 69 characters making it relatively easy to crack these hashes using a tool such as Hashcat.

Before hashing, a 14 character password is first split into two seven-character chunks. If the password is less than fourteen characters, it will be padded with NULL characters to reach the correct value. Two DES keys are created from each chunk. These chunks are then encrypted using the string KGS!@#$%, creating two 8-byte ciphertext values. These two values are then concatenated together, resulting in an LM hash. This hashing algorithm means that an attacker only needs to brute force seven characters twice instead of the entire fourteen characters, making it fast to crack LM hashes on a system with one or more GPUs. If a password is seven characters or less, the second half of the LM hash will always be the same value and could even be determined visually without even needed tools such as Hashcat. The use of LM hashes can be disallowed using Group Policy. An LM hash takes the form of 299bd128c1101fd6.

NTHash (NTLM)

NT LAN Manager (NTLM) hashes are used on modern Windows systems. It is a challenge-response authentication protocol and uses three messages to authenticate: a client first sends a NEGOTIATE_MESSAGE to the server, whose response is a CHALLENGE_MESSAGE to verify the client's identity. Lastly, the client responds with an AUTHENTICATE_MESSAGE. These hashes are stored locally in the SAM database or the NTDS.DIT database file on a Domain Controller. The protocol has two hashed password values to choose from to perform authentication: the LM hash (as discussed above) and the NT hash, which is the MD4 hash of the little-endian UTF-16 value of the password. The algorithm can be visualized as: MD4(UTF-16-LE(password)).

NTLM Authentication Request

Rachel:500:aad3c435b514a4eeaad3b935b51304fe:e46b9e548fa0d122de7f59fb6d48eaa2:::

Looking at the hash above, we can break the NTLM hash down into its individual parts:

• Rachel is the username
• 500 is the Relative Identifier (RID). 500 is the known RID for the administrator account
• aad3c435b514a4eeaad3b935b51304fe is the LM hash and, if LM hashes are disabled on the system, can not be used for anything
• e46b9e548fa0d122de7f59fb6d48eaa2 is the NT hash. This hash can either be cracked offline to reveal the cleartext value (depending on the length/strength of the password) or used for a pass-the-hash attack. Below is an example of a successful pass-the-hash attack using the CrackMapExec tool:

NTLM Authentication Request

AWildRavenclaw@htb[/htb]$ crackmapexec smb 10.129.41.19 -u rachel -H e46b9e548fa0d122de7f59fb6d48eaa2
SMB         10.129.43.9     445    DC01      [*] Windows 10.0 Build 17763 (name:DC01) (domain:INLANEFREIGHT.LOCAL) (signing:True) (SMBv1:False)
SMB         10.129.43.9     445    DC01      [+] INLANEFREIGHT.LOCAL\rachel:e46b9e548fa0d122de7f59fb6d48eaa2 (Pwn3d!)

Domain Cached Credentials (MSCache2)

In an AD environment, the authentication methods mentioned in this section and the previous require the host we are trying to access to communicate with the “brains” of the network, the Domain Controller. Microsoft developed the MS Cache v1 and v2 algorithm (also known as Domain Cached Credentials (DCC) to solve the potential issue of a domain-joined host being unable to communicate with a domain controller (i.e., due to a network outage or other technical issue) and, hence, NTLM/Kerberos authentication not working to access the host in question. Hosts save the last ten hashes for any domain users that successfully log into the machine in the HKEY_LOCAL_MACHINE\SECURITY\Cache registry key. These hashes cannot be used in pass-the-hash attacks. Furthermore, the hash is very slow to crack with a tool such as Hashcat, even when using an extremely powerful GPU cracking rig, so attempts to crack these hashes typically need to be extremely targeted or rely on a very weak password in use. These hashes can be obtained by an attacker or pentester after gaining local admin access to a host and have the following format: $DCC2$10240#bjones#e4e938d12fe5974dc42a90120bd9c90f.

Task: NTLM Authentication

User Naming Attributes

Domain joined

Hosts joined to a domain have greater ease of information sharing within the enterprise and a central management point (the DC) to gather resources, policies, and updates from. A host joined to a domain will acquire any configurations or changes necessary through the domain’s Group Policy. The benefit here is that a user in the domain can log in and access resources from any host joined to the domain, not just the one they work on. This is the typical setup you will see in enterprise environments.

Non-domain joined

Non-domain joined computers or computers in a workgroup are not managed by domain policy. With that in mind, sharing resources outside your local network is much more complicated than it would be on a domain. This is fine for computers meant for home use or small business clusters on the same LAN. The advantage of this setup is that the individual users are in charge of any changes they wish to make to their host. Any user accounts on a workgroup computer only exist on that host, and profiles are not migrated to other hosts within the workgroup.

Task: User and Machine Accounts

AD Groups

Groups in Active Directory have two fundamental characteristics: type and scope. The group type defines the group's purpose, while the group scope shows how the group can be used within the domain or forest. When creating a new group, we must select a group type. There are two main types: security and distribution groups.

Three group scopes: domain local, global and universal

Domain local — only used to manage permission within the domain it was created. Local groups can be nested into (contained within) other local groups but not within global groups.

Global — used to grand access in other domains. Can only contain accounts from the domain where it was created. Global groups can be added to both other global groups and local groups.

Universal — kind of in the name really…

Group scopes can be changed, but there are a few caveats:

A Global Group can only be converted to a Universal Group if it is NOT part of another Global Group.

A Domain Local Group can only be converted to a Universal Group if the Domain Local Group does NOT contain any other Domain Local Groups as members.

A Universal Group can be converted to a Domain Local Group without any restrictions.

A Universal Group can only be converted to a Global Group if it does NOT contain any other Universal Groups as members.

Nested Group Membership

As mentioned previously, a Domain Local Group can be a member of another Domain Local Group in the same domain. Through this membership, a user may inherit privileges not assigned directly to their account or even the group they are directly a member of, but rather the group that their group is a member of. This can sometimes lead to unintended privileges granted to a user that are difficult to uncover without an in-depth assessment of the domain. Tools such as BloodHound are particularly useful in uncovering privileges that a user may inherit through one or more nestings of groups.

Important Group Attributes

Like users, groups have many attributes. Some of the most important group attributes include:

• cn: The cn or Common-Name is the name of the group in Active Directory Domain Services.
• member: Which user, group, and contact objects are members of the group.
• groupType: An integer that specifies the group type and scope.
• memberOf: A listing of any groups that contain the group as a member (nested group membership).
• objectSid: This is the security identifier or SID of the group, which is the unique value used to identify the group as a security principal.

Task: AD Groups

AD Rights and Privileges

Honestly this feels like a bunch of gratuitous over sharing of information I largely skimmed through.

Task: AD Rights and Privileges

Damn this is getting long… at what point do I split it into separate posts?

Security in AD

General AD Hardening Measures

LAPS — password rotation at a fixed interval.

Logging and Monitoring — used to detect an attacker or unauthorised employee adding a user or computer, modifying an object in AD, changing an account password, accessing a system in an unauthorised or non-standard manner, performing an attack such as password spraying, or more advanced attacks such as modern Kerberos attacks.

Update Management (SCCM/WSUS)

Proper patch management is critical for any organization, especially those running Windows/Active Directory systems. The Windows Server Update Service (WSUS) can be installed as a role on a Windows Server and can be used to minimize the manual task of patching Windows systems. System Center Configuration Manager (SCCM) is a paid solution that relies on the WSUS Windows Server role being installed and offers more features than WSUS on its own. A patch management solution can help ensure timely deployment of patches and maximize coverage, making sure that no hosts miss critical security patches. If an organization relies on a manual method for applying patches, it could take a very long time depending on the size of the environment and also could result in systems being missed and left vulnerable.

Group Managed Service Accounts (gMSA)

A gMSA is an account managed by the domain that offers a higher level of security than other types of service accounts for use with non-interactive applications, services, processes, and tasks that are run automatically but require credentials to run. They provide automatic password management with a 120 character password generated by the domain controller. The password is changed at a regular interval and does not need to be known by any user. It allows for credentials to be used across multiple hosts.

Account seperation is important for Admin accounts. One for day-to-day work and the Administrator account for Admin work.

Task: Security in AD

Examining Group Policy

A Group Policy Object (GPO) is a virtual collection of policy settings that can be applied to user(s) or computer(s). GPOs include policies such as screen lock timeout, disabling USB ports, enforcing a custom domain password policy, installing software, managing applications, customizing remote access settings, and much more. Every GPO has a unique name and is assigned a unique identifier (a GUID). They can be linked to a specific OU, domain, or site. A single GPO can be linked to multiple containers, and any container can have multiple GPOs applied to it. They can be applied to individual users, hosts, or groups by being applied directly to an OU. Every GPO contains one or more Group Policy settings that may apply at the local machine level or within the Active Directory context.

Task: Examining Group Policy

I’m actually going to stop this here and do the Guided Labs without all the notes etc. Decided I won’t do a write up of these, have to leave some mystery!

Honestly, I didn’t enjoy that one bit. I do, however have the utmost respect for the importance of people in charge of AD and all things associated with it. That was a LOT of boring but insanely important information.

Disclaimer: I’m not saying the author of this module sucks or it’s inferior content in anyway. I just didn’t enjoy going through it, although I understand how important it is to have an overview of AD.