Active Directory
Active Directory Privilege Escalation
Last updated
Active Directory Privilege Escalation
Last updated
The /r/oscp subreddit recommended adPEAS as an excellent tool for automated enumeration of active directory environments.
User accounts created to be used as service accounts rarely have their password changed. Group Managed Service Accounts (GMSAs) provide a better approach (starting in the Windows 2012 timeframe). The password is managed by AD and automatically changed.
If you have access to a user account who has permissions to read the managed password, then you can do so like this:
WARNING: gMSADumper.py gets the password HASH. You can also get the actual password though, I think, using other tools.
You can also use a hash instead of a password with gMSADumper.
If you're not sure whether you can read managed passwords, then the attribute you need to look for in Ad is msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword). It stores the security principals that can access the GMSA password.
TrustedToAuthForDelegation
If an AD user has the TRUSTED_TO_AUTH_FOR_DELEGATION (constrained delegation) or ADS_UF_TRUSTED_FOR_DELEGATION (unconstrained delegation) field set in their userAccountControl, then they can request tickets on behalf of other users, without knowing their password.
Unconstrained - you can request a ticket for any service as any user that doesn't have ‘Account is sensitive and cannot be delegated’ enabled.
If a user cannot be delegated, then it has NOT_DELEGATED in its userAccountControl attribute
Constrained - you can request a ticket for a specific service as any user that doesn't have ‘Account is sensitive and cannot be delegated’ enabled.
Specifically, you can request a service ticket to any SPN specified in msds-allowedtodelegateto.
You could use PowerView’s -TrustedToAuth flag for Get-DomainUser/Get-DomainComputer. Look at harmj0y's post to see the full command.
Alternatively, if you dumped the active directory with something like ldapdomaindump, then you might also notice the TRUSTED_TO_AUTH_FOR_DELEGATION or ADS_UF_TRUSTED_FOR_DELEGATION flags.
Sources:
Exploit using Windows-based tools
Exploit using Linux-based tools
You can use BloodHound to find active directory attack paths.
You can download it from apt in kali. For the latest version, though, download the github repo:
Also download the executable from Releases (linux x64).
For instructions on how to set it up, take a look at Ippsec's video on HackTheBox Forest at ~46 minutes.
First, you have to start up the neo4j console.
Then, you can run the bloodhound GUI application.
Default credentials for neo4j are neo4j:neo4j (unless you changed them). If it's your first time running neo4j, you need to change the credentials.
To actually get the data into BloodHound, you need to run SharpHound.exe on a compromised windows machine.
Find the executable in your Linux machine:
For me it was in /usr/lib/bloodhound/resources/app/Collectors/.
Transfer sharphound to the compromised machine and run it.
Afterwards, send the generated file back to your linux box.
Open up a file manager and drag-and-drop the generated zip file into the bloodhound GUI. It will extract and import.
First, search for the user you have compromised in the top filter, right click it and mark the user as owned.
Open up the menu at the top and click on "Analysis" (may also be "Queries"). It's a tab in the Database Info menu. For example, you can do "Shortest Paths to domain admins from Kerberoastable Users" if you're looking to kerberoast something. If you're looking to go from an owned user to ad admin, then select "shortest path to domain admin from owned principals". The "all interesting paths" option is the useful query for the general term.
For each node connection, you can right click and click "info". That specifies what the permission does, as well as how to abuse it with copy-pastable commands (though you might have to tweak them to get them to work sometimes). Most of the commands use PowerView (the version from the dev branch!) - A link to powerview is provided in the References tab.
Use this command if you've got powerview downloaded to the machine:
Or this command to import the functions over HTTP:
Domain controllers need to replicate information between each other. If a user's password was changed, then that change needs to be replicated in every domain.
So, if we can get DCSync capabilities, then we can just ask another domain controller to replicate over a user's password data. The permission's name is "Replicating Directory Changes" and "Replicating Directory Changes All", and domain controllers have that permission. Those two permissions are the ones we need for this attack.
The main difficulty lies in getting those two permissions for the attack. The most common way is through the Microsoft Exchange Windows Permissions group. If you install MS Exchange, then it integrates with AD and adds a load of permissions. One of the things it adds is the group MS Exchange permissions. It grants that group permission to modify permissions on the root of this domain. If you can get into that group, then you will have permission to modify those permissions.
If you've managed to get the two permissions needed, then you can go forward with the attack.
Use Impacket's secretsdump script. In this example, the user "USER_NAME" has the two permissions needed. The script will ask you for the password.
The script gives you a list of all the users in the domain, along with their password hash (LM/NTLM). You can then use that hash for pass-the-hash.
