search
WINDOWS & ADABOUT ME
HackTheBoxActiveDirectoryWindowsVulnLabs

Support

Another easy AD box from HackTheBox

hashtag
Phase 1: Initial Reconnaissance & SMB Enumeration

The assessment began with a standard Nmap scan against the target IP 10.129.1.65, which revealed a typical Active Directory Domain Controller profile (DNS, Kerberos, RPC, LDAP, and SMB) for the domain support.htb

Unauthenticated SMB enumeration using smbclient -L \\10.129.1.65 -N uncovered a non-standard share named support-tools . Connecting to this share anonymously (smbclient \\10.129.1.65\support-tools -N) provided access to several portable executable files and zipped archives, most notably a custom binary named UserInfo.exe.zip

hashtag
Phase 2: Reverse Engineering & Credential Extraction

To understand what the custom binary was doing, UserInfo.exe was decompiled using a .NET reverse engineering tool (like dnSpy or ILSpy) .

Exploring the source code revealed a class named LdapQuery under the UserInfo.Services namespace, which establishes a connection to the domain's LDAP service . Digging deeper into the Protected class uncovered an obfuscated password string and a decryption method . The C# code handling the decryption looked like this:

Analyzing the getPassword() function revealed a two-step decryption process:

  1. The enc_password string is decoded from Base64 into a byte array.

  2. A for loop iterates through the array, performing a double XOR operation. Each byte is XOR'd against the corresponding byte of the key (armando), and the result is XOR'd again against the hex value 0xDF.

Instead of running the binary dynamically, a custom Python script was developed to replicate this decryption routine offline:

hashtag
Phase 3: LDAP Enumeration & Lateral Movement

The extracted ldap account credentials were confirmed as valid using nxc ldap to dump the domain groups .

With valid domain credentials, Apache Directory Studio was used to connect to the LDAP service and manually browse the directory tree . Inspecting the attributes of the support user object (CN=support,CN=Users,DC=support,DC=htb) revealed a plaintext password, Ironside47pleasure40Watchful, carelessly left inside the info attribute.

Now we can get shell using the credentialssupport:Ironside47pleasure40Watchful and get the user flag

hashtag
Phase 4: BloodHound Analysis & RBCD Attack Path

With the support user compromised, BloodHound was utilized to map out potential attack paths. The graph revealed that the support user is a member of the Shared Support Accounts group . Crucially, this group possesses GenericAll privileges over the Domain Controller (DC), opening the door for a Resource-Based Constrained Delegation (RBCD) attack .

hashtag
Phase 5: Exploitation (Ticket Forgery)

The RBCD exploit chain was executed in three distinct steps:

  1. Creating a Rogue Computer: Using Impacket's addcomputer.py and the support user's credentials, a new machine account named FAKE02$ with the password Password123! was cleanly added to the domain .

  2. Modifying Delegation Rights: Through an Evil-WinRM session, the Set-ADComputer PowerShell cmdlet was used to write the FAKE02$ account into the DC's PrincipalsAllowedToDelegateToAccount attribute .

  1. Forging the Service Ticket: With the backdoor set, Impacket's getST.py was used to leverage the FAKE02$ account to request a forged S4U2Proxy service ticket . This ticket successfully impersonated the Administrator user for the cifs service on the Domain Controller.

hashtag
Phase 6: System Compromise

The forged ticket was saved as an Impacket .ccache file. By setting the KRB5CCNAME environment variable to point to this ticket, it was loaded into the local Kerberos cache . Finally, wmiexec.py was executed with the -k and -no-pass flags, successfully consuming the ticket and granting an interactive SYSTEM shell on the Domain Controller .

hashtag
Phase 7: Vulnerabilities & Remediation

The complete compromise of the support.htb domain was not the result of a zero-day exploit, but rather a chained series of Active Directory misconfigurations and insecure operational practices. To secure this environment, the following remediation steps should be implemented immediately:

1. Unauthenticated SMB Access

  • Finding: The support-tools file share allowed anonymous, unauthenticated read access, leaking sensitive internal IT applications.

  • Remediation: Disable anonymous read access on all SMB shares. Apply strict Access Control Lists (ACLs) so that only authorized helpdesk or IT personnel can access support tools. 2. Hardcoded Credentials & Custom Cryptography

  • Finding: The UserInfo.exe binary contained the ldap service account password hardcoded into the source code. The developers attempted to hide it using Base64 encoding and a custom XOR routine, which was easily reverse-engineered.

  • Remediation: Never hardcode credentials in application source code. Transition to secure secrets management, such as the Windows Credential Manager, DPAPI (Data Protection API), or a dedicated enterprise vault (e.g., HashiCorp Vault, CyberArk). 3. Passwords Stored in Active Directory Attributes

  • Finding: The plaintext password for the support user was stored in the easily readable info attribute of their Active Directory object.

  • Remediation: Immediately remove the password from the info attribute and force a password reset for the support account. Educate IT staff that AD attributes (like description, info, and comment) are readable by any authenticated user and must never be used as a notepad for sensitive data. 4. Overly Permissive Active Directory ACLs

  • Finding: The Shared Support Accounts group was inappropriately granted GenericAll (Full Control) rights over the Domain Controller object. This allowed a lower-privileged user to modify the DC's delegation attributes.

  • Remediation: Audit and strip excessive permissions from the Domain Controller object. Enforce the Principle of Least Privilege and a Tiered Active Directory administration model. Only Tier 0 administrative accounts (e.g., Domain Admins, Enterprise Admins) should have modification rights over Domain Controllers. 5. Mitigating RBCD & Machine Account Quotas

  • Finding: The GenericAll permission was weaponized via Resource-Based Constrained Delegation (RBCD), which first required the attacker to create a new machine account (FAKE02$) in the domain.

  • Remediation: By default, Active Directory allows any standard authenticated user to add up to 10 computer accounts to the domain. Change the ms-DS-MachineAccountQuota attribute at the domain root level from 10 to 0. This breaks the first step of the RBCD attack chain for standard users.

PreviousCodePartTwoNextBaby

Last updated