Clip source: https://infosecwriteups.com/you-got-domain-admin-now-what-aab749c4200d

Typically when you’re starting out on your red teaming journey, a goal on an Internal Penetration Test or maybe even the ultimate goal is to compromise the Windows Active Directory Domain. Getting to that goal is always fun and the “boss” feeling of doing it is unexplainable, particularly if it is your first time achieving it. But does it end there? We achieved the big bad so surely the engagement is basically over, right? Pack it up, go home and get that report done? WRONG!

It is always essential to keep thinking and always mapping out attack paths or scenarios to impose as much “damage,” okay maybe that isn’t the best word to use but I think you can understand where I am going with this.

So let’s look at one such attack scenario you should explore once you have domain admin:

Attempt to “own” the client’s Azure cloud space

What is better than following up with a complete “ownage” of the respective Azure AD Cloud space of a client? It’s one of the ultimate flexes in an engagement. Let’s get right into it. The first thing we do is to determine if they even have one. Let’s use this simple GET request to determine if we get a valid tenant ID returned to us:

https://login.microsoftonline.com/[domainnamehere]/.well-known/OpenID-configuration

GET Request to determine an Azure Instance

Okay, maybe there is a much easier way. Try to log in with one of the emails that belong to the client in question and observe how the azure portal responds. Keep in mind this is a hit and miss as some users may just not have the rights to log into the portal. You can’t go wrong with just using the tenant ID method.

Unsuccessful:

Unsuccessful logging in of a user account

Successful:

Successful login of a user account

Okay! Now that we have confirmed that they have an Azure space. Let’s go hunting!

So let’s pull up Powershell and we will be using a tool called AADInternals. In short, this is one of the ultimate tools to use for Azure and Microsoft 365 hacking. So let’s install and import the necessary modules:

Install-Module AADInternals

Import-Module AADInternals

AADInternals

Let’s go ahead and do some enumeration at the start on an example target so we can get some real-life data to see how things look in the beginning. We are trying to pull the tenant's name and other information:

Get-AADIntLoginInformation

Now we pull the tenant ID. If you remember, at the beginning of this blog we got it earlier from our GET request:

Tenant ID

Now that we have an idea of how the unauthenticated side of things works, let’s now carry our authenticated enumeration from the domain admin we compromised from the get-go. Below we will see the necessary commands to become authenticated:

$password = ConvertTo-SecureString “password” -AsPlainText -Force

$creds = New-Object System.Management.Automation.PSCredential(“username”,$password)

Connect-AzureAD -Credential $creds

Once we pass the necessary parameters we are logged in and we are met with the Account, Environment, and other information which you see below:

Crafting credentials to establish authenticated access

AADInternals is a very robust tool but we’ll focus on the commands that will help in taking us straight to our goal.

So we need to find the Server that hosts Azure AD Connect. In short, this is an application from Microsoft that deals with a Hybrid Identity setup. Typically AD Connect creates service accounts within Azure and also on the On-Premise Active Directory. They usually have the following syntax:

Azure AD: Sync_<server name>_<random string>@<tenant name>.onmicrosoft.com

On-Premise AD: MSOL_<ranomized string>@<domain name>

If you would like to know more about Azure AD Connect in detail, you can read more here.

So! Let’s find that server.

We run the below command to get the Sync Configuration information:

Get-AADIntSyncConfiguration:

Sync Configuration Information

As you can see we are seeing the Azure AD Sync agent beside the “DirSyncServiceAccount.” Let’s ping that machine, get the IP and try to remote in with the domain admin credentials to log in.

NB. We have to be on the server in question to get detailed information on the sync account.

So we are now on the server. Now let us pull up AADInternals on that system and run the below command and hope we get credentials in plain text:

Get-AADIntSyncCredentials:

Sync Account Password in plain text

Perfect! So we got the AADUser password in plain text.

Now let us visit the Azure Portal and try these credentials:

Accessing the Azure Portal with the sync account

And just like that we are in!

In some instances, there are cases where the account does not have many rights within the portal. In my next blog post, I will touch on hunting for Azure AD global admin credentials in LSA secrets if your user only has read access. Until next time, happy hacking!

References: