It seems like all these corporate types are using Active Directory. What is this “Active Directory”? And how can I use it to make my job as a Script Kiddie easier?
Active Directory (AD) is a directory service developed by Microsoft for Windows networks and computers. A directory service is a shared database for mapping network services and resources. It can be used for locating and managing resources and administering a network. In particular, AD stores information about objects and resources on the network and makes this information easy to find and use. It uses a structured data store to logically organize the information in a hierarchical way.
AD maintains a database of objects including shared resources, e.g., servers and printers, as well as account information and services. In addition to maintaining this database, it provides a directory service to access and administer these objects. This directory service is really a collection of Windows services/processes typically running on one or more servers known as domain controllers. The directory services include Domain Services, Lightweight Directory Services, Certificate Services, Federation Services, and Rights Management Services. The details of these are left for the more advanced Script Kiddies to discover on their own.
As mentioned previously, the objects in the AD are maintained in a hierarchical database. The hierarchy contains many levels including forests, trees, domains, and possibly multiple levels of organizational units. In addition to the global catalog of the objects themselves, AD contains a schema that defines the classes of objects and attributes. Another feature of AD is a replication service which ensures that all domain controllers/servers have a copy of the directory information. Finally, AD provides a query and index mechanism, so objects and their attributes can be found by network users and applications.
To fully understand AD, we would need to cover more about the logical structure of the directory itself, the different domain controller roles, the minutia of the AD schema, and do not even get me started on trusts. But as a Script Kiddie, what you really need to know is that AD contains all of the information you need about the network and even ways for managing/manipulating these network objects. Thankfully, AD is ubiquitous and easily accessible. There are many tools for accessing AD, and in fact there is an extremely useful Microsoft AD module for PowerShell. We will be using PowerView to demonstrate most of the tactics and techniques.
So, you are telling me Windows networks just makes all this information available for anyone on the network? Tell me more. I like free things. What can I grab?
AD does indeed contain everything that you would ever want to know about a Windows network. It is your phonebook, atlas, and Rolodex all in one (and you youngins ask a gray hair what a Rolodex is). Windows wants to make sure that all users and applications have the information they need to access the network and its resources, so they make it available for the pilfering. You just need to know where to look and how to ask. With the right tools and the right queries, you can get all kinds of information about the domain itself, computers, users, groups, policies, access controls, trusts, and much more.
First, we need the right tool. There are a variety of tools a Script Kiddie can use to interact with the AD service. Windows provides an AD module which is normally available on servers but can be downloaded and used on any Windows client (see https://github.com/samratashok/ADModule for a copy). One of the more common third-party alternatives is a collection of PowerShell scripts called PowerSploit which has a reconnaissance module called PowerView. The only drawback is that you need the ability and permissions to install this module, but once you do, you will have a variety of cmdlets for enumerating everything you would want to know, from domain and computer information to users and groups, to file shares and processes. You can even get group policy objects (GPO) and access control lists (ACLs) settings. The following sections list some of the cmdlets and what you can expect.
Domain and Forest
Now that we have the right tools, let’s start getting information about our AD. As mentioned, AD is laid out in a hierarchical manner with forests and domains at the top. We can get information about the forest and domain themselves. For this, PowerView has a variety of cmdlets. Here are a few to get started. After these commands, we will have some basic info about our domain, the domain controller, and the basic domain policy.
Get-Forest – Returns the forest object for the current (or specified) forest
Get-ForestDomain – Returns all domains for the current (or specified) forest
Get-Domain – Returns the domain object for the current (or specified) domain.
Get-DomainController – Returns the domain controllers for the current (or specified) domain.
Now that we have a basic understanding of the domain, let us look at some of the users on the domain. We can use PowerView to list all of the domain users or find information about a specific user. We can even use it to get a specific property of a user. For instance, we could look at the pwdlastset, badpwdcount, and/or logoncount of users to help separate legitimate users from potential honeypot/dummy users.
Get-DomainUser – Returns all users or specific user objects in AD.
Get-DomainUser -Properties – Checks the last time the password was set for all of the users.
First, we learned about the domain, and then the users on the domain. Next, let’s look at the computers on the domain. PowerView will let us list all of the computers and specific properties of the computers. It will even let us do a quick and dirty ping sweep.
Get-DomainComputer – Returns all computers or specific computer objects in AD.
Get-DomainComputer -OperatingSystem – Lists all Server 2016 systems (maybe we have a ‘sploit?).
Once we know about the users and computers, let’s figure out how they are organized. PowerView has cmdlets for listing groups and members of a group. This will help us identify potential targets.
Get-DomainGroup – Returns all groups or specific group objects in AD.
Get-DomainGroupMember – Returns the members of a specific domain group.
After identifying the different users, groups, and computers, we should identify the different domain policies applied to them. Group policies affect the configurations and restrictions applied to security settings, the registry, startup/shutdown/logon/logoff scripts, and software installation. PowerView lets us look at the overall Group Policy as well as
Get-DomainPolicy – Returns the default domain policy or the domain controller policy for the current domain or a specified domain/domain controller.
Get-DomainGPO – Returns all GPOs or specific GPO objects in AD.
Get-DomainGPOLocalGroup – Returns all GPOs in a domain that modify local group memberships through Restricted Groups or Group Policy preferences. It also returns their user membership mappings, if they exist.
Get-DomainGPOUserLocalGroupMapping – Takes a user/group name and optional domain, then determines the computers in the domain the user/group has local admin (or RDP) rights to.
Get-DomainGPOComputerLocalGroupMapping – Takes a computer (or GPO) object and determines what users/groups are in the specified local group for the machine through GPO correlation.
AD enumeration can also be used to determine the permissions of an object or user. AD uses access tokens to establish identity and privileges. These access tokens are used with security descriptors to determine the permissions that a user has over an object. The security descriptors are comprised of discretionary access control lists as well as some other information. ACLs are in turn comprised of access control entries (ACEs). In short, AD keeps helps determine what users can and cannot do to other AD objects. We can use PowerView to get a list of these permissions.
Get-DomainObjectAcl – Returns the ACLs associated with a specific AD object.
Invoke-ACLScanner – Finds object ACLs in the current (or specified) domain that have modification rights set to non-built-in objects
Trusts and Forests
In AD, users in one domain or forest can access resources in another domain or forest which have a trust relationship. This means if we can find out which domains or forests trust the domain or forest that we have access to, then we may have found another interesting place to explore. Thankfully, AD also makes this data available and PowerView has a cmdlet for that.
Get-DomainTrust – Returns all domain trusts for the current domain or a specified domain
Get-ForestTrust – Returns all forest trusts for the current forest or a specified forest.
Invoke-MapDomainTrust – Tries to build a relational mapping of all domain trusts.
In addition to all the other AD information we have already enumerated, there is so much more information available. We have just skimmed the surface of what AD makes available for users and administrators. There are a few more cmdlets of interest, but it does not stop here, especially if you’re a creative Script Kiddie.
Get-NetLoggedon – Returns users logged on the local (or a remote) machine. Note: Administrative are rights needed for newer Windows OSes.
Get-WMIRegLastLoggedOn – Returns the last user who logged onto the local (or a remote) machine.
With all of this information, we can do a more than enumerate; we can actively hunt. PowerView comes with a few cmdlets that will automate the discovery of some interesting AD entries.
Invoke-UserHunter – Finds machines on the local domain where specified users are logged in and can optionally check if the current user has local administrator access to found machines.
Invoke-ShareFinder – Finds (non-standard) shares on hosts in the local domain.
Invoke-FileFinder – Finds potentially sensitive files on hosts in the local domain.
So basically, Active Directory is the Hitchhiker’s Guide to Hacking? I just ask and it tells me everything I need to know? This is amazing. Why have I been so scared of the man behind the curtain? This will definitely make my Script Kiddie life easier.
Surely, you now have a better understanding of AD and how it can be used to facilitate your exploration and enumeration of the network. The primary goal of AD is to make information about network resources more readily available. AD is a database and set of services used by users and applications, and it can be used by you too. You just have to know what is available, how to ask for it, and what tools are available to help you. Now you can use these tools and insight to conquer the world! Or at least this domain… Just remember to always check your return values.