Intelligence

Completed on Aug 31, 2021

Overview

From the Active Directory machines HTB content developers have created, there is always something to learn. Intelligence gives you another approach on how an AD miconfiguration can lead to a domain compromise. In this case, unconstrained delegation is the path to owning AD; something that should definitely be avoided if possible or at least asset lock down. I hope this write-up provides some insight to others as it did for me while working on this machine.

References:

Enumeration

Finding Open Ports

Just like we normally do, we will try to find out what services are exposed so we know how to proceed. In this box, we will expand the port scan to UDP ports as well.

Let's run nmap default scripts and service versioning against the TCP ports found.

This machine has the typical open ports from domain controllers along with NTP and UDP LDAP, but let's just go through the process and inspect each service and try to rely on low hanging fruits.

From the certificate information in LDAP and LDAPS, we see dc.intelligence.htb. Let's add this to the hosts file.

Inspecting Web Application

After inspecting the site, we see two PDF documents can be downloaded.

Capture of web application and document download links
HTML code referencing the PDF documents.

Let's download and inspect these documents:

Inspecting PDF Files

Using exiftool to inspect the PDF files:

From the content of these files, we now have a naming conversation for user accounts so let's create a users list including other possible combinations:

User Enumeration with Kerbrute

Using Kerbrute for user enumeration can help determine which ones are valid, and rule out what could be garbage:

Custom Scripting for PDF Content Extraction

Looking to see if there are more PDF files and to extract their information, we need to test the download and extract the metadata. For this, we created a script that will take care of the requests, creating a user list, extract the metadata while creating a file with the information from the found PDF files:

After running this script, we obtained a password along with a username from the PDF metadata:

The obvious next step is to test this password and attempt to use it with the PDF creator username.

Password Spraying

If we test with this credential set, this will not work but given the message in the PDF, doing some password spraying could lead us to a valid credential pair.

This confirms the user which this password works with. The credential set is:

  • User: Tiffany.Molina

  • Password: NewIntelligenceCorpUser9876

SMB and LDAP Enumeration with Enum4Linux

The header of this section doesn't pay tribute to what enum4linux does as it is more than just SMB and LDAP, but let's expand our enumeration to other services:

With this data, we gained some insight into how we can gain good information once we access the victim machine. For example, along with users we also have now a domain computer and what is possibly associated with the machine logon (intelligence\svc_int$).

Gaining Access

As we saw in the last step of our enumeration, three groups look interesting: dba, itsupport, and sysadmins. And we have the following:

As we can see, we can access the IT, Users, NETLOGON, and Sysvol shares, but nothing else. Let's try Users share and see what can we access.

And so looks like we got the user flag!

Along with this, we can tell who else to look at next...Ted.Graves, a member of itsupport.

Right from the IT share, we are able to get a powershell script:

This powershell script was developed to check the availability of any sites using a domain name that start with 'web'.

At this point, I think we can use Responder while the script runs locally on the victim machine, which seems to be used periodically to validate if the site is down. For this, we will use krbrelayx's dnstool to try and create a DNS record under intelligence.htb domain.

Manipulating DNS and NTLM Hash Capture

Given that the downdetector.py script is looking for any site starting with web, we can add a DNS record like that, so we will add 'webfoo.intelligence.htb' and then validate the DNS record was created.

On another terminal window, we run Responder and wait 5 minutes for the script to run to capture NTLM hashes when the powershell script is executed and webfoo.intelligence.htb is found:

Here we have an NTLM Hash from Ted.Graves:

[HTTP] NTLMv2 Hash : Ted.Graves::intelligence:64c89b9435433bdf:5D84FBE3CAB9ABBDFE2EB192A9F29E13:0101000000000000E370A91E8B9DD701285ACD78B7C17CCF00000000020008004C0038005600370001001E00570049004E002D004D004A004F00490052004300580057004A004C004C00040014004C003800560037002E004C004F00430041004C0003003400570049004E002D004D004A004F00490052004300580057004A004C004C002E004C003800560037002E004C004F00430041004C00050014004C003800560037002E004C004F00430041004C0008003000300000000000000000000000002000004EFD9984637182FF871938C959F49E0B019165C48A5DD2B56826A726A26BE57B0A001000000000000000000000000000000000000900380048005400540050002F0077006500620066006F006F002E0069006E00740065006C006C006900670065006E00630065002E006800740062000000000000000000

Privilege Escalation

Before proceeding, let's crack this NTLMv2 hash so we can use the password when needed.

Now the we have Ted.Graves password, let's try and see if we have access to the shares and what access.

Inspecting Permissions with BloodHound

Using 'Ted.Graves' does not give us much of a direct access to the platform, so given the LDAP information we obtained through enum4linux, we know there is more to it so let's try and gather more information through LDAP by using Bloodhound and its remote ingestor.

In Bloodhound, when using the 'Shortest Paths to Unconstrained Delegation Systems' query, we see the ITSUPPORT group can read GMSA (group managed service account) passwords. From our LDAP enumeration and BloodHound, we know 'Ted.Graves' and 'Laura.Lee' are members of this group.

Unconstrained Delegation Path

Dump GSMA Service Ticket

From all the different things we can attempt at this point, we can try to dump svc_int$ passwords readable by the user by using gMSADumper and then request the Kerberos Service Ticket.

The information we passed to the domain controller was not sufficient as the time has to be as close as possible to the Kerberos server and we needed to specify properly the Service Principal Name.

Notice, we are attempting to impersonate the Administrator user given the 'AllowedtoDelegate' permisions svc_int$ has, as shown in the BloodHound screenshot.

Now that we got the service ticket, we need to have it accessible so we can gain access as administrator. In this case, we will set it as the KRB5CCNAME environment variable in our system to then use it to access the victim machine as Administrator.

And we got the root flag!

Hope you notice how unconstrained delegation becomes a risk to an environment when the environment is not configured properly. What I mean with this is, even when the delegation is done right, if an account is given more rights than what it should have and that account gets compromised, you can move laterally by compromising another account with more privileges, compromising the rest of the environment.

Last updated

Was this helpful?