I started with an nmap scan for all TCP ports and the top UDP ports. This one looks like an Active Directory Domain Controller.

Added target hostnames to /etc/hosts

Looking through the SMB shares, I found one “support-tools” that is not default. Looking into the share with guest access, I found some files and one non standard looking binary “UserInfo.exe.zip”.

I used the tool dnSpy to do code analysis on the binary. I found a password and a key.

I used this post to do this next step. This snippet is an interactive Python session that reverses a simple custom obfuscation to reveal a plaintext secret. It first base64-decodes pass_b64 into raw bytes, then XORs each byte with the corresponding byte from a repeating key (b"armando") using itertools.cycle, and finally XORs the result with the constant 223 (e ^ k ^ 223) to produce the original byte values. The bytes are then combined into a bytearray and decoded to UTF-8, yielding the plaintext credential nvEfEK16^1aM4$e7AclUf8x$RtWxPW01%lmz. This pattern (base64 + repeating-key XOR + fixed-value XOR) is a lightweight obfuscation method.

With the credentials gathered for the ldap account, I checked them with Netexec and they were good!

Ran the BloodHoundCE ingestor to collect Active Directory objects and relationships from the domain. The resulting graph exposed privilege paths and group memberships useful for privilege escalation planning.

I used ldapsearch with the confirmed credentials to pull user/group attributes and noted that additional useful data was stored in nonstandard fields (e.g., info). Those attributes helped reveal group memberships and service associations.

Found that the support account belongs to the Remote Management Users group, indicating elevated remote administration capabilities. That group membership informed which remote management vectors to attempt next.

Authenticated to the target with Evil-WinRM using the support account, giving an interactive Windows shell. This access provided a foothold for data collection and post-exploitation actions.

Analysis of ACLs and BloodHound output showed a GenericAll from the Shared Support Accounts group to the DC.SUPPORT.HTB computer object. This means we can abuse resource-based constrained delegation to elevate our access to domain admin.

I uploaded PowerView, Powermad, and Rubeus for the attack and ran PowerView and Powermad.

I created a machine account, crafted an ACL granting that machine SID delegation rights, wrote it into a target computer’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute, and thereby enabled the machine account to be trusted for Kerberos delegation to that target — allowing impersonation of users (including high-privileged accounts) domain takeover.

Collecting RC4 hash with Rubeus

Successfully obtained a usable Kerberos ticket for a privileged account, which then allowed authenticated access to otherwise-restricted services.

Decoded the Base64-encoded ticket into its binary .kirbi/.ccache form and then converted it to the format required by our tooling (e.g., ccache).

I then converted the ticket to (KRB5CCNAME) and used it with impacket-psexec -k -no-pass to authenticate to dc.support.htb as administrator@dc.support.htb, found a writable ADMIN$ share, uploaded a payload and created a service.
Service started successfully and elevated to NT AUTHORITY\SYSTEM, giving full system control on the domain controller.