Introduction to Active Directory

So this is pretty important if you want to be a penetration tester, as around four in five big organisations use it, around 90% of Fortune 500 companies use it - and these are the sorts of clients with massive infrastructures that need the likes of you trying to break in and confirm their stability.

The reason a technology exists, for the most part - is because there is a massive demand for a certain functionality or objective , so what's all the fuss about Active Directory ? Well, imagine I'm the director of a multinational corporation that's got offices scattered over the world, with many different departments in each office and we have a mixture of remote employees, contractors, interns etc. Essentially we have a gargantuan "tree" of users, who belong to groups , and they belong to departments - under a specific function. This tree on the main server - which is called the domain controller, will be relayed to the local domain controller servers (present for each "domain" - be it office or department etc). The tree will get updated locally and then it gets replicated onto the other trees if the update was successful and approved.

Each particular directory , representations of data about an entity and its surrounding domain , will have corresponding permissions. We as the administrator should make it so the permissions follow the ideas of least-privilege - giving users just the right permissions to do their job without any side-effects. Permissions relative to the group also need to be taken into consideration so that the group as a whole has sufficient functionality.

Objects, which are the fundamental things AD collects , manages and stores data on - can be classified either as a resource - so a printer, scanner , server etc - whereas a security principal is the user or group account which has particular permissions , SSH keys , passwords etc.

Background

Active Directory tries to answer the question above, as it aims to be a service which has an oversized phone-book (directory) which has painstakingly organised them into the relevant categories that we defined. AD is based on the older X.500 protocol - which was designed to:

develop an electronic directory of people in an organization so that it can be part of a global directory available to anyone in the world with Internet access.The idea is to be able to look up people in a user-friendly way by name, department, or organization. Many enterprises and institutions have created an X.500 directory. Because these directories are organized as part of a single global directory, you can search for hundreds of thousands of people from a single place on the World Wide Web.

The ideas of that protocol continued into AD , of which it is an implementation of that standard.

In the LDAP brief - of which was an old implementation of X.500 (and many concepts continued into AD), the idea of a directory is agreed to be "a collection of open systems cooperating to provide directory services" - such as querying, addition , deletion etc. The information held in the Directory is collectively known as the Directory Information Base (DIB) . The DIB hosts all the data - which I mentioned earlier was in the shape of a tree to reflect the corporation's structure - more formally, the composed hierarchical set of entries is known as the Directory Information Tree (DIT).

An entry into the tree could be anything, it could be a new user , a new group , new device etc. The entry will always be focused on adding some sort of object though - where the entry is the representation of that object. Some attributes in the entry will reflect user information, aptly named user attributes whilst others will represent operational/administrative information and are called operational attributes.

When naming an entry , it should have a name unique from it's subordinates and superiors, but each entry will be named relative to its immediate superior. What I mean by this is, the entry will probably reflect the fact it belongs to a certain domain. For example, an example attribute I could use to name an entry would be the Organisational Unit - to denote the department a user is in, what office etc. The unordered set of attributes used to name an entry (making note of its place relative to its superior) is called the Relative Distinguished Name (RDN). More precisely , the set of attributes is really a set of Attribute Value Assertions (AVA)'s - consisting of an attribute description with zero options and an attribute value. These AVAs are chosen to match attribute values (each a distinguished value) of the entry.

The following are examples of string representations of RDNs
[RFC4514]:

UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores

The last is an example of a multi-valued RDN; that is, an RDN
composed of multiple AVAs.

To have a fully qualified name, a Distinguished Name (DN) then we must take into account the RDN (the entries own set of AVAs) in addition to the immediate superior's DN. Moreover this DN will include the DN of the last - making each entry distinguished and hence a find-able entry in the DIT. A Distinguished Name unambiguously refers to an entry in the tree.

Example of DN of an entry
 
UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US

An Organisational Unit (OU) defines a section for users, groups and devices, and each domain can house an OU , but each user/object in a domain must be unique which may impact your design choices.  

Containers are similar to OUs, but Group Policy Objects (GPO) cannot be applied or linked to container objects.

So just to make it clear , a Relative Distinguished Name (RDN) is just the set of attributes for that object, and is to do with the naming of the "leaf node", it won't specify the entire path of the object like a DN will - as a DN is composed of the RDN (the description of the object itself) + the DN of its parent , then the path is complete.

There is another concept called a principal which is - according to the Active Directory spec:

A unique entity (user account, a computer account, or a thread or process that runs in the security context of a user or computer account) identifiable by a security identifier (SID) that is typically the requester of access to securable objects or resources. It often corresponds to a human user but can also be a computer or service. It is sometimes referred to as a security principal.

The SID is a value of variable length, used as the unique identifier for a user or group, it can never be used to identify another user or group.

So we can have Service Principals - which are service accounts - like things for SQL, FTP, Apache etc.

To see all available (Service Principal Names) SPN's on a system do:

setspn -l hostname (e.g controller/administrator) - found by whoami,if you're on the PC

Directory Schema

The Directory Schema is a set of definitions and constraints concerning the structure of the DIT, the possible ways entries are named, the information that can be held in an entry, the attributes used to represent that information and their organisation into hierarchies to facilitate search and retrieval of the information and the ways in which values of attributes may be matched in attribute value and matching rule assertions.

What Active Directory offers

To help companies handle all these machines , users and their subsequent data - AD comes with a variety of services to streamline the process, including:

• Active Directory Domain Services (AD DS) which is where the technical administrator of an entire office (who watches over all employee machines, be they in separate domains or not) can set the authentication policies (Kerberos?) , define the rules , stored data and attributes of objects and the group policies. An administrator account with such regulatory power is called the domain controller, and their computer has the Windows Server Operating System installed, with the AD DS running which allows them to get the domain up and running. For the creation of new domains, maybe per department or however the organisation wants to partition their structure, they would have to create a new domain server. Three is also Active Directory Lightweight Domain Services (AD LDS) which is a simplified version of the former. Like I mentioned, there are multiple domain controllers along the hierarchy - the first one at the root, following all the way down into locally scoped domains like departments of a particular country...
• Certificate Services generate, manage and share certificates. A certificate uses encryption to enable a user to exchange information over the internet securely with their issued public key.
• Federation Services is what allow a single user to not have to sign in to access each resource each time, they login once at the domain server and then they proceed to request for any resource within their level.
• Rights Management Services allow us to define information rights, what gets encrypted what doesn't what procedures need this form of encryption etc.

A domain is a collection of objects - which don't have to be on the same network , but they have all been grouped together and have their own DNS structure built up. So you can ask for a resource by its Distinguished Name and not have to know the IP, due to the specificity of this naming the directory can map the name given to the IP used when the account was signed up. Due to the nature of tree having levels, denoting Top-Level-Domains , the tree is broken up into the same sort of structure as a URL - so a DNS server is possible.

A tree is one or more domains grouped together, which may reflect an office block. Trees can only be built when there is a high-degree of trust between the two domains, so as to allow them to communicate. Depending on the structure , if one domain is a subset of another, then the hierarchical nature of this would allow a third domain which sits atop both to transitively trust the first domain, as it trusts the second. A forest then is a collection of trees, which must contain shared catalogues , directory schemas - noting the structure of each tree, application information and domain configurations. So for each conceptual layer we go up - the more abstract it gets - likewise the more we need to know to form such a connecting backbone. In addition, global catalogue servers provide a listing of all the objects in a forest. According to Microsoft, the forest is Active Directory's security boundary.

Physical Active Directory

Right, starting from the bottom now, what are the prerequisites to having an AD infrastructure set up? Well, we need the domain controller server(s), the storage server(s) , domain user machines and all subsequent resources. So basically think everything besides the software. You should be having flashbacks to the OSI model,where for now I'm talking about the equivalent to the physical layer - level one.

Domain Controllers

A domain controller is a Windows server that has Active Directory Domain Services (AD DS) installed and has been promoted to a domain controller in the forest. Domain controllers are the center of Active Directory - they control the rest of the domain, be it the last domain before ending with leaf nodes, or including further subdomains . I will outline the tasks of a domain controller below:

• holds the AD DS data store
• handles authentication and authorisation services
• replicate updates from other domain controllers in the forest
• Allows admin access to manage domain resources

The Active Directory Data Store holds the databases and processes needed to store and manage directory information such as users, groups, and services. Below is an outline of some of the contents and characteristics of the AD DS Data Store:

• Contains the NTDS.dit - a database that contains all of the information of an Active Directory domain controller as well as password hashes for domain users
• Stored by default in %SystemRoot%\NTDS
• accessible only by the domain controller

That is everything that you need to know in terms of physical and on-premise Active Directory. Now move on to learn about the software and infrastructure behind the network.

The %SystemRoot%\NTDS also contains the following related files:

• chk. This file is a checkpoint file. Checkpoint files are commonly used in a transactional database system to keep track of which log file entries have been committed to the database. This is useful during a system crash to avoid data loss.
• log. There are typically multiple log files starting with edb such as edb0013A.logand edb0013B.log. Additionally, there is the edb.log file which is the active log file. These logs are the transaction logs used to record changes made in AD DS. All changes are first written to a transaction log and eventually make their way into the database a short time later.
• edb. As the name implies, this file is a temporary file used to track transactions that are taking place. It is also used when you run a database compaction job.
• log and res2.log or edbres00001.jrs and edbres00002.jrs. These log files are each 10MB in space and used in a situation where you are critically low on disk space on the system volume. In older versions of Windows Server, the res1.log and res2.log files are used. Since Windows Server 2008, the edbres naming is used, along with a new file extension of .jrs.

The Active Directory database is based on Microsoft’s Joint Engine Technology (JET) which is a database engine that was developed in 1992. Microsoft Access is also based on the JET technology.

Domain Services and Authentication

The Active Directory Domain Services are the core functions of an Active Directory network; they allow for management of the domain and the imposition of security certificates, LDAPs onto each one. This is how the domain controller decides what it wants to do and what services it wants to provide for the domain.

Domain Services are exactly what they sound like. They are services that the domain controller provides to the rest of the domain or tree. There is a wide range of various services that can be added to a domain controller, but these are the ones that come with the initial setup:

• LDAP - Lightweight Directory Access Protocol; provides communication between applications and directory services
• Certificate Services - allows the domain controller to create, validate, and revoke public key certificates
• DNS, Local Link Multi-cast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS) - Domain Name Services for identifying IP hostnames. We can listen to ports LLMNR (UDP 5455) or NBT-NS (UDP 137) as they broadcast their results ... Something like NBT-NS is a fallback for when a service like AD or SMB doesn't have a particular host known on their system so they check that table (in the case of AD it might be populated with hosts, in the case of SMB maybe shares).

Domain Authentication Overview -

The most important part of Active Directory – as well as the most vulnerable part of Active Directory – is the authentication protocols set in place. There are two main types of authentication in place for Active Directory: NTLM and Kerberos:

• Kerberos - The default authentication service for Active Directory uses ticket-granting tickets and service tickets to authenticate users and give users access to other resources across the domain.
• NTLM - default Windows authentication protocol uses an encrypted challenge/response protocol

The Active Directory domain services are the main access point for attackers and contain some of the most vulnerable protocols for Active Directory, this will not be the last time you see them mentioned in terms of Active Directory security.

Forests

The forest is what defines everything; it is the container that holds all of the other bits and pieces of the network together – without the forest all of the distant trees and domains would not be able to interact.

Forest consists of:

• Trees - A hierarchy of domains in Active Directory Domain Services
• Domains - Used to group and manage objects
• Organisational Units (OUs) - Containers for groups, computers, users, printers and other OUs
• Trusts - Allows users to access resources in other domains
• Objects - users, groups, printers, computers, shares
• Domain Services - DNS Server, LLMNR, IPv6
• Domain Schema - Rules for object creation

Users and Groups

The users and groups that are inside of an Active Directory are up to you; when you create a domain controller it comes with default groups and two default users: Administrator and guest. It is up to you to create new users and create new groups to add users to.

Users Overview -

Users are the core to Active Directory; without users why have Active Directory in the first place? There are four main types of users you'll find in an Active Directory network; however, there can be more depending on how a company manages the permissions of its users. The four types of users are:

• Domain Admins - This is the big boss: they control the domains and are the only ones with access to the domain controller.
• Service Accounts (Can be Domain Admins) - These are for the most part never used except for service maintenance, they are required by Windows for services such as SQL to pair a service with a service account
• Local Administrators - These users can make changes to local machines as an administrator and may even be able to control other normal users, but they cannot access the domain controller
• Domain Users - These are your everyday users. They can log in on the machines they have the authorisation to access and may have local administrator rights to machines depending on the organisation.

Groups Overview -

Groups make it easier to give permissions to users and objects by organising them into groups with specified permissions. There are two overarching types of Active Directory groups:

• Security Groups - These groups are used to specify permissions for a large number of users
• Distribution Groups - These groups are used to specify email distribution lists. As an attacker these groups are less beneficial to us but can still be beneficial in enumeration

Default Security Groups -

There are a lot of default security groups so I won't be going into too much detail of each past a brief description of the permissions that they offer to the assigned group. Here is a brief outline of the security groups:

• Domain Controllers - All domain controllers in the domain
• Domain Guests - All domain guests
• Domain Users - All domain users
• Domain Computers - All workstations and servers joined to the domain
• Domain Admins - Designated administrators of the domain
• Enterprise Admins - Designated administrators of the enterprise
• Schema Admins - Designated administrators of the schema
• DNS Admins - DNS Administrators Group
• DNS Update Proxy - DNS clients who are permitted to perform dynamic updates on behalf of some other clients (such as DHCP servers).
• Allowed RODC Password Replication Group - Members in this group can have their passwords replicated to all read-only domain controllers in the domain
• Group Policy Creator Owners - Members in this group can modify group policy for the domain
• Denied RODC Password Replication Group - Members in this group cannot have their passwords replicated to any read-only domain controllers in the domain
• Protected Users - Members of this group are afforded additional protections against authentication security threats. See http://go.microsoft.com/fwlink/?LinkId=298939 for more information.
• Cert Publishers - Members of this group are permitted to publish certificates to the directory
• Read-Only Domain Controllers - Members of this group are Read-Only Domain Controllers in the domain
• Enterprise Read-Only Domain Controllers - Members of this group are Read-Only Domain Controllers in the enterprise
• Key Admins - Members of this group can perform administrative actions on key objects within the domain.
• Enterprise Key Admins - Members of this group can perform administrative actions on key objects within the forest.
• Cloneable Domain Controllers - Members of this group that are domain controllers may be cloned.
• RAS and IAS Servers - Servers in this group can access remote access properties of users

Trusts + Policies

Trusts and policies go hand in hand to help the domain and trees communicate with each other and maintain "security" inside of the network. They put the rules in place of how the domains inside of a forest can interact with each other, how an external forest can interact with the forest, and the overall domain rules or policies that a domain must follow.

Domain Trusts Overview -

Trusts are a mechanism in place for users in the network to gain access to other resources in the domain. For the most part, trusts outline the way that the domains inside of a forest communicate to each other, in some environments trusts can be extended out to external domains and even forests in some cases.

There are two types of trusts that determine how the domains communicate. I'll outline the two types of trusts below:

• Directional - The direction of the trust flows from a trusting domain to a trusted domain
• Transitive - The trust relationship expands beyond just two domains to include other trusted domains

The type of trusts put in place determines how the domains and trees in a forest are able to communicate and send data to and from each other when attacking an Active Directory environment you can sometimes abuse these trusts in order to move laterally throughout the network.

Domain Policies Overview -

Policies are a very big part of Active Directory, they dictate how the server operates and what rules it will and will not follow. You can think of domain policies like domain groups, except instead of permissions they contain rules, and instead of only applying to a group of users, the policies apply to a domain as a whole. They simply act as a rule-book for Active Directory that a domain admin can modify and alter as they deem necessary to keep the network running smoothly and securely. Along with the very long list of default domain policies, domain admins can choose to add in their own policies not already on the domain controller, for example: if you wanted to disable windows defender across all machines on the domain you could create a new group policy object to disable Windows Defender. The options for domain policies are almost endless and are a big factor for attackers when enumerating an Active Directory network. I'll outline just a few of the many policies that are default or you can create in an Active Directory environment:

• Disable Windows Defender - Disables windows defender across all machine on the domain
• Digitally Sign Communication (Always) - Can disable or enable SMB signing on the domain controller

Active Directory meets the cloud

Microsoft has realised that many companies don't want a local site, that a cloud is much more secure, easier to manage and the cost is worth it. This is why their cloud service Azure has an Active Directory setup on the cloud for companies to fill with their data:

Azure AD Overview -

Azure acts as the middle man between your physical Active Directory and your users' sign on. This allows for a more secure transaction between domains, making a lot of Active Directory attacks ineffective.

Cloud Security Overview -

The best way to show you how the cloud takes security precautions past what is already provided with a physical network is to show you a comparison with a cloud Active Directory environment:

Reference this writeup:

https://fthcyber.com/2020/10/15/active-directory-basics-writeup-tryhackme/

Exploring Active Directory

Now that we have a pretty good idea of what Active Directory is, I'm going to give a brief tour on the Windows GUI first, using the machine given to us by the Active Directory Basics room on Tryhackme.

When we're on the domain controller we will be greeted with the Server Manager Dashboard - as we are a server - but this is too general, so click on Tools and we'll start by looking at Active Directory Users and Computers

And we're greeted with this,

Attacking Active Directory

Depending on the corporation, they may have some legacy infrastructure - so applications running older versions of Java, C which still wish to use the internet - and still wish to get some of the data that is within the Active Directory database. Old corporate behemoths may stick around, but are too old to load the clients which would do the work directly, so they required a middle man. This is something called NetBIOS which is an API running over the NBT protocol, (where we get NBT-NS from) and we can use that to perform the ordinary functions we would do on a directory - query users, add users, remove them etc. But NetBIOS provides that data, or the functions/computers that perform those functions for that legacy application - so they don't feel that they're missing out.

NBTScan is a command line tool used for scanning networks to obtain NetBIOS shares and name information. It can run on both Unix and Windows and ships with Kali Linux by default.

Let's see it in action against the Attack Active Directory room

- v option is for verbose
- h option is for human-readability

Now, we've been able to acquire the domain name - which tells us that this domain does cater to legacy applications , but now we want to see what devices are available. Remember, we are a pen tester just starting on this piece of architecture - and unless this is a grey box test or higher - we really don't have much of an idea about the users, the versions of the software and all the different domain services that this Active Directory setup is using. This last bit is crucial, Active Directory is a collection of domain services, hence AD DS - we see this whenever we do an nmap scan on the domain controller:

You can see a huge cluster of services that this server offers, and they all intertwine. Kerberos is on port 88 for authentication, port 135 is Microsoft's RPC (Remote Procedure Call) service , which provides a suite of functions for those legacy applications we talked about. They call the server and ask it to perform a particular function - god knows what, it could be literally anything , like a simple curl even - and the result is returned . More details on RPC are here.

For the legacy application to know where the domain controller is, or maybe the RPC server is at another IP it helps to run an nbtscan as finding the NBT-DS service will mean we can find all the servers which will be of aid - hence we need to usually include the CIDR notation when scanning to find the right IP - in this case we already know the IP of the NBT-DS server , which is the same as the domain controller. Port 389 is the conventional directory services that AD offers, and it follows in the ideas and conventions of LDAP so it figures why it'd be listed as that.

Port 445 we typically see for SMB , file sharing etc but the great thing about that protocol is that it can cater to any type of device which has an SMB client - be it Windows, Linux etc and so it's great for making it easier for those devices to authenticate as it will convert the packet and pass it on. For more on how SMB is integrated with AD see this Redhat series:

Port 464 is also for Kerberos, it's the name change service for which both UDP & TCP ports 464 are used by the Kerberos Password Change. This port in particular is used for changing/setting passwords against Active Directory - by which we can update the AD database. Obviously you need your credentials on hand to authenticate and so to get to this point we'll need to scavenge for some accounts !

For all the different ports that may be intertwined with AD, see this?redirectedfrom=MSDN) Microsoft Documentation. This blog also covers all the ports used in AD.

Right, back to the good stuff . We can continue our enumerative quest by using the enum4linux script which will check out as many ports on the system as possible and run standard checks - to see for default accounts, list shares etc.

There's quite a bit to scroll through , but we're getting a better picture of the SMB, RPC and LDAP services. But what about checking out Kerberos ? After all, it is only through this that we are granted access to Active Directory remember. So it is absolutely crucial we find a way to either exploit the service itself or find valid credentials.

Attacking Kerberos

In older versions of Kerberos you could start a session with a server and you wouldn't have to send a password straight away , request packets could be sent without a password - just the Principal Name - and it would allow authentication without a password if the account was configured poorly. This is as disastrous as it sounds, and from Kerberos version 5 a password is required - which is called Pre-Authentication. Much safer, and administrators have to turn this feature off (to go back to the old, awful way) by selecting

Does not require Kerberos Pre-Authentication

In a domain user's account settings.

What we want to test , is if there are any user or service accounts that have had this option ticked - and hence we wouldn't need a password - just the principal name.

Likewise, for all accounts where this Pre-Authentication is working and we need to provide the password (encrypted password hash + timestamp) then we could send the same empty packet with no password and it'll tell us - "Hey this account needs a password" and it'll prompt for Pre-Authentication - meaning the Principal Name we gave is valid.

This is the idea behind Kerbrute's userenum feature, it'll brute-force Kerberos for usernames and whenever the server prompts Pre-Auth we know it's valid. The brute-forcing works regardless whether it's on or off, as if it is on then we get the prompt-response and if it's off then it means we can grab a TGT with that username - so we'll know either way if that username does exist.

Installing Kerbrute on Kali is quite simple:

git clone https://github.com/ropnop/kerbrute

cd kerbrute

make all

cd dist

./kerbrute_linux_amd64 

;; or whatever your architecture is, and it should work
;; make sure you have golang installed ! 
;; go to the official website : https://golang.org/doc/install

Now let's use the wordlist we got from the room to brute-force some accounts . Bingo ! It seems all but one account didn't have Pre-Authentication installed and as I hypothesised earlier it wouldn't matter whether it was off or on, but in the case for the svc-admin account I only need the name and due to me "logging in" I was granted a TGT.

This is serious progress. Whilst we have this ticket we aren't in any position to crack it yet as I can only presume it hasn't been formatted ... I tried with hashcat and john but nothing. However, trying to grab a TGT with GetNPUsers (Get No-Pre-authenticated Users) then we can specify a format:

Within this ticket are the credentials of this user - as that is how the TGS server will authorise the user later when they ask for resources - so let's direct this tool to something like john or hashcat.

Less hassle with just using John ,

;; use the password list that comes with the room

john hash.txt --wordlist=passwordlist.txt

Now that we have some credentials we can log into the svc-admin account and Kerberos will authenticate us.

Since Kerberos is often used to achieve Single-Sign-On so I should be able to use smbmap to have a look around to see which share we could jump into with smbclient and the backup share looked accessible:

Now that we have some credentials we can log into the svc-admin account and Kerberos will authenticate us. I used smbmap to have a look around to see which share we could jump into with smbclient and the backup share looked accessible:

Using get to have the file on our machine, we can plug the code through cyberchef and see the underlying text

Now that is enough to have a look through this account , and being the backup account for the domain it is synced to any changes to any of the user accounts - which we can spot by having a look through the activity logs of this account:

We can see that we used the DRSUAPI method to get access to these changes, with more information on this see here.

With the administrator's hash we can use a tool called evilwinrm which makes use of the Windows Remote Management protocol, which is a SOAP protocol designed to create a language which makes it easier for systems - regardless of their hardware or operating system etc to communicate with Windows systems. It provides a way of logging in, and that's exactly what we'll do

And each flag will be in each user's respective Desktop folder.