The Forest Is Under Control. Taking over the entire Active Directory forest

Active Directory is a phenomenon that comes about quite often during the security testing of large companies. It is all too common to come across not a single domain in a single forest, but rather a more interesting structure with more branches. So today we are going to focus on how to perform reconnaissance and study forest structures. We will also look at possibilities for increasing privileges. Then we will conclude by compromising an enterprise's entire forest!

The subject of today's discussion

It's no secret that many, if not the majority, of large companies use Active Directory catalog services from the well-known MS. The reason is rather evident.
This approach helps automate a number of things, integrate everything into one coherent structure, and make life easier for both the IT team and the rest of the staff.
As a rule, if the institution is rather large, as it grows it can acquire other (smaller) companies, initiate mergers, expansions, and enjoy other benefits of being a large business. All of that is reflected on the structure of the AD forest, which gets new trees and grows in size and nature. It's exactly this branched structure that is our focus today. As per tradition, we will begin with a short theoretical introduction.

In the deep AD forests

Let's quickly run through the key concepts of an Active Directory that we will return to time and again in what is to follow. Let's start from the smallest structural unit of an AD – the domain.

Domain is a logical group (of users, hosts, servers, etc.) that supports centralized administration.

Tree is a set of domains that use a common name space (similarly to a regular DNS). It is important that the subdomain automatically receives a dual-sided trust relationship with the parent domain.

Trust is an agreement of sorts between two domains that sets access permissions to certain objects or resources.

In turn, the forest is the largest structure in the Active Directory composed of all the trees. As a result, all trees in the forest are usually linked by dual-sided trust relationships, which allow users in any tree to get access to resources in any other tree if they have the corresponding permissions and rights.

By default, the first domain, created in the forest, automatically becomes its root domain.

Now that the theory is clear, we can now proceed to the practical part; so let's begin. We can assume that basic access with a few user privileges has already been granted. We can also presume that social engineering has yielded its fruit, and somebody has already opened the document contained in the specially prepared letter that we sent (with the attached document, for instance), and in return we got back the shell.

Checking the ammunition

Before we head off to battle, it's advisable to first check our tool kit to see what we can use. PowerShell is currently the most convenient tool to research the Windows environment. Why? Well, because it's installed everywhere (starting from Windows 7/2008R2), it lets regular users work and execute various commandlets, and it's deeply integrated in the OS.

The default policy, which prohibits the execution of third-party (unsigned) PowerShell scripts, is not an adequate means of protection. It simply protects against accidental launches by double-clicking and is easily bypassed. PowerShell is essentially an entire framework for the post-use of Windows. Naturally, for this reason it has already been being used by pentesters for several years, and a lot of different modules (scripts) that help automate actions have been created.

We will only use one of these modules, PowerView, which is part of the [PowerTools] set ( It was initially developed as part of the infamous Veil project, but now recently after the release of the impressive PowerShell Empire framework (which evolves rather dynamically and deserves its own separate article) was moved and is now a subproject of the PS Empire.

PowerView is at once a replacement for all console "net*" commands in Windows and an AD research tool. It should be noted separately that most options are available with regular user rights.

Proceeding to the starting position

I should remind readers that we have basic access and, for purposes of simplicity, we will consider that we have a Meterpreter shell with regular domain user rights. This year, working with PS in Metasploit has become significantly more user-friendly and several specialized payloads have popped up that we are going to be using. In order to not lose the current session, let's create a new one by using the payload_inject mechanism.

To do this, let's execute:

We select, of course, powershell as the payload:

Now here we can indicate the module that needs to be imported if the launch is successful:

I will also note that if you want to give the full address to GitHub, then in our case PowerView will be downloaded by the victim directly from the attacker's host.

As the final touch we need to indicate the number of the currently available session:

Launch for execution (result on fig. 1).

Fig. 1. PowerShell session

Fig. 1. PowerShell session

Situational awareness

Now that we have the interactive PowerShell we can study the situation in more detail. First off we need the two following commands:

  • Get-NetForestDomain — reveals all domains in the forest (fig. 2);
  • Get-NetDomainTrust — reveals the trust relationships of the domain we are in now (fig. 3).

Fig. 2. A fragment of the Get-NetForestDomain roll-out

Fig. 2. A fragment of the Get-NetForestDomain roll-out

Fig. 3. Get-NetDomainTrust results

Fig. 3. Get-NetDomainTrust results

As our forest is quite large and the domain list we obtained doesn't clearly reveal its structure, we might try and create a clear-cut visual map.

To do this, let's first save the map of trust relationships in a CSV file:

This commandlet at first studies the current domain and then it makes a recursive run through every trust relationship with each domain it can reach.
The result is saved in a CSV file where every domain and relationship is described. Then we can get the file (or its text content) in any way most convenient for us.

Now we need the DomainTrustExplorer script. Let's launch it and transfer the CSV file as a parameter:

We get back an unusual type of shell; all commands can be seen by typing in help. We are interested in its most useful feature, or the ability to save the collected data as a GraphML. It runs with a single command:


As a result we get a file called trusts.csv.graphml, and this format can be opened in the yEd free editor. However, some actions need to be executed here in order to obtain a pleasing diagram. After opening the ".graphml" file, we need to immediately proceed to Edit -> Properties Mapper. We will then see a settings window where we need to select New Configuration (Node) on the left and then press the green plus button on the right (see fig. 4)

Fig. 4. yEd settings

Fig. 4. yEd settings

Press the Apply button and select the New Configuration (Edge) section in the same window; using the same procedure now we need to add a new entry by pressing the green plus button on the right (see fig. 5).

Fig. 5. yEd settings, continued

Fig. 5. yEd settings, continued

Press Apply again and then OK to close the window. The last step is to go to the Tools -> Fit Node to Label menu. Now we can select any mode we like in the Layout menu, for instance Hierarchical or Tree. With each and every change the diagram is readjusted automatically. In our case we end up with fig. 6.

Fig. 6. AD scheme

Fig. 6. AD scheme

The diagram gives a clear view of the entire forest. I will remind you now that we have domain user privileges in the DEV.HIGH-SEC-CORP.LOCAL domain. From here on out we will be using made-up domain and subdomain names, so all coincidences are accidental. Now we have at our disposal a graphical map of the forest and information about trust relationships. Our target is the root of the forest, so it is high time to start elevating our privileges little by little.


Red vs Blue: "Modern Active Directory Attacks & Defense" is the most remarkable report on AD attacks given recently, and was presented by Sean Metcalf at DerbyCon this year.

Video of the presentation

The enemy's manpower

Because we have our current PowerShell session (with the imported PowerView module), we can perform detailed research on domain groups and domain users.

Let's take a look at who is in the group of domain administrators in our current domain:

Please subscribe to read full article

1 year

for only $300

With subscription you are free to read all of the materials of
Read more about the project

Please subscribe to view comments

Only subscribers can participate in the discussions. You may login in to your account or sign up to Hackmag and pay a subscription to access the discussions.