Enumerating AD [Legacy Notes]
Enumerating AD Using Legacy Windows Tools
List Domain Users
To start gathering user information, we will use the net.exe binary, which is installed by default on all Windows operating systems. More specifically we will use the net user sub-command. While we can use this tool to enumerate local accounts on the machine, we'll instead use /domain to print out the users in the domain.
C:\Users\stephanie>net user /domain
The request will be processed at a domain controller for domain corp.com.
User accounts for \\DC1.corp.com
-------------------------------------------------------------------------------
Administrator dave Guest
iis_service jeff jeffadmin
jen krbtgt pete
stephanie
The command completed successfully.
Administrators often add prefixes or suffixes to usernames that identify accounts by their function.
Gather Information On Individual User
List Groups in Domain
List Group Members for Domain Group
Enumerating with PowerShell & .NET
There are several tools we can use to enumerate Active Directory. PowerShell cmdlets like Get-ADUser work well but they are only installed by default on domain controllers as part of the Remote Server Administration Tools (RSAT). RSAT is very rarely present on clients in a domain and we must have administrative privileges to install them. While we can, in principle, import the DLL required for enumeration ourselves, we will look into other options.
In order to enumerate AD, we first need to understand how to communicate with the service. AD enumeration relies on LDAP. When a domain machine searches for an object, like a printer, or when we query user or group objects, LDAP is used as the communication channel for the query. In other words, LDAP is the protocol used to communicate with Active Directory.
LDAP is not exclusive to AD. other directory services use it as well and LDAP communication with AD isn ot always straight-forward, but we'll leverage an Active Directory Services Interface (ADSI) as an LDAP provider.
According to Microsoft, we need a specific LDAP ADsPath in order to communicate with the AD service. The LDAP path's prototype looks like this:
We need three parameters for a full LDAP path:
Hostname : the hostname can be a computer name, ip address or a domain name. Note that a domain may have multiple DCs, so setting the domain name could potentially resolve to the IP address of any DC in the domain. While this would likely still return valid information, it might not be the most optimal enumeration approach. To make our enumeration as accurate as possible, we should look for the DC that holds the most updated information. This is known as the Primary Domain Controller (PDC). There can only be one PDC is a domain. To find the PDC, we need to find the DC holding the PdcRoleOwner property.
PortNumber : the port number for the LDAP connection is optional according to Microsoft's documentation. However, if we come across a domain using non-default ports, we may need to manually add this.
DistinguishedName : a distinguished name (DN) is a part of the LDAP path. the DN is a name that uniquely identifies an object in AD, including the domain itself. If we aren't familiar with LDAP, this may be somewhat confusing so let's go into a bit more detail.
DistinguishedName In Detail
In order for LDAP to function, objects in AD (or other directory services) must be formatted according to a specific naming convention. To show an example of a , we can use an example domain user stephanie. We know that stephanie is a user within the corp.com domain. With this, the DN may look something like this:
CN: Comon Name, specifies the identifier of an object in the domain
DC: Domain Component, represents the top of an LDAP tree
When reading a DN, we start with the Domain Component objects on the right side and move to the left.
Building An Enumeration Script
In Microsoft .NET classes related to AD, there is the System.DirectoryServices.ActiveDirectory namespace. While there are a few classes to choose from here, we'll focus on the Domain Class. It specifically contains a reference to the PdcRoleOwner.
This output reveals the PdcRoleOwner property, which in this case is DC1.corp.com.
Enumerating AD with PowerView
The PowerView PowerShell script has many valuable functions to improve the effectiveness of our enumeration.
PowerView Usage
Install/Import PowerView
If you run into the error that PowerView.ps1 cannot be loaded because it is not digitally signed. Run the following line in powershell:
Domain Information
List All Domain Users
List Groups in Domain
Manually Enumerating Active Directory
Enumerating Operating Systems
In a typical pentest, we use various recon tools to detect which operating system a client or server is running.
There are many important attributes, but the one we are interested in this case is the operatingsystem attribute.
It's a good idea to grab this information early in the assessment to determine the relative age of the systems and to locate potentially weak targets. According to the information we've gathered so far, the machine with the oldest OS appears to be running Windows 10. Additionally, it appears we are dealing with a web server and a file server that will require our attention at some point as well.
So far in our enumeration we have obtained a nice list of all objects in the domain as well as their attributes. In the next section, we will continue using this information to determine the relationships between the various objects in search of potential attack vectors.
Permissions and Logged On Users
It is important to focus on the relationships between as many objects a possible while enumerating AD. These relationships often play a key role during an attack, and our goal is to build a map of the domain to find potential attack vectors.
For example, when a user logs in to the domain, their credentials are cached in memory on the computer they logged in from.
If we are able to steal those credentials, we may be able to use them to authenticate as the domain user may even escalate our domain privileges.
Sometimes during an AD assessment we may not always want to escalate our privileges right away. It is also important to establish a good foothold and to at the very least maintain our access. If we are able to compromise other users that have the same permissions as the user we already have access to, this allows us to maintain our foothold. If, for example, the password is reset for the user we originally obtained access to, or the system administrators notice suspicious activity and disable the account, we would still have access to the domain via other users we compromised.
When an attacker or penetration tester improves access through multiple higher-level accounts to reach a goal, it is known as a chained compromise.
Scan Network To Determine Administrative Permissions on Domain Computer for Current User
This command relies on PowerView and the OpenServiceW function, which will connect to the Service Control Manager (SCM) on the target machines. The SCM essentially maintains a database of installed services and drivers on Windows computers. PowerView will attempt to open this database with the SC_MANAGER_ALL_ACCESS access right, which requires administrative privileges, and if the connection is successful, PowerView will deep that our current user has administrative rights on the target machine.
What Computers Are Currently Signed In To By Users
The Get-NetSession command uses the NetWkstaUserEnum and NetSessionEnum APIs.
Can add the Verbose flag if you are receiving no output:
Another tool that can be used is the PsLoggedOn application from the SysInternals Suite:
Check Permissions Over A File
Enumeration Through Service Principal Names
Applications must be executed in the context of an operating system user. If a user launches an application, that user account defines the context. However, services launched by the system itself run in the context of a service account.
In other words, isolated applications can use a set of predefined service accounts, such as LocalSystem, LocalService, and NetworkService.
When applications like Exchange, MS SQL, or Internet Information Services (IIS) are integrated into AD, a unique service instance identifier known as Service Principal Name (SPN) associates a service to a specific service account in Active Directory.
We can obtain the IP address and port number of applications running on servers integrated with AD by simply enumerating all SPNs in the domain, meaning we don't need to run a broat port scan.
Enumerating SPNs using setspn.exe
Enumerating SPNs using PowerView Get-NetUser
Get IP Address from SPN
Object Permissions Enumeration
An object in AD may have a set of permissions applied to it with multiple Access Control Entries (ACE). These ACEs make up the Access Control List (ACL). Each ACE defines whether access to the specific object is allowed or denied.
Example:
A domain user attempts to access a domain share (which is also an object). The targeted object, in this case the share, will then go through a validation check based on the ACL to determine if the user has permissions to the share. This ACL validation involves two main steps. In an attempt to access the share, the user will send an access token which consists of the user identity and permissions. The target object will then validate the token against the list of permissions (the ACL). If the ACL allows the user to access the share, access is granted. Otherwise the request is denied.
List of Interesting Permissions
Enumerate ACEs with PowerView
While there are many properties that could be potentially useful, we are primarily interested in the ObjectSID, ActiveDirectoryRights, and SecurityIdentifier properties.
Convert SID to Name PowerView Module
The ActiveDirectoryRights property describes the type of permission applied to the object. In order to find out who has the ReadProperty permission in this case we need to convert the SecurityIdentifier property.
This output implies that the object belongs to a default AD group named RAS and IAS Servers.
Select Interesting Properties with Get-ObjectAcl
Convert the SIDs to readable names
Enumerating Domain Shares
PowerView's Find-DomainShare function allows you to find all shares in a domain. We can add the -CheckShareAccess flag to display shares only available to us.
Some of these are default domain shares, we should investigate each of them in search of interesting information.
In this examples we'll focus on SYSVOL as it may include files and folders that reside on the domain controller itself. This particular share is typically used for various domain policies and scripts. By default, the SYSVOL folder is mapped to %SystemRoot%\SYSVOL\Sysvol\domain-name on the domain controller and every domain user has access to it.
During the assessment, we should investigate every folder we discover in search of interesting items.
Exploiting ACL Permissions
Last updated