Writeup by wook413

Recon

Nmap

I initiated the assessment with a comprehensive Nmap scan covering all 65,535 TCP ports. This was followed by a targeted service and script scan on identified ports and a UDP scan of the top 10 ports to ensure no common attack vectors were missed.

Initial Access

HTTP 80 7990

Nmap script enumeration on the identified HTTP services did not yield any interesting information.

HTTP 80

The main page on port 80 implies that the target machine is actually the Domain Controller.

image-20260201013600061

image-20260201013612596

Directory brute-forcing on port 80 using gobuster and feroxbuster yielded no significant results.

HTTP 7990

The Atlassian page on port 7990 provided a lead: a message informing employees of a migration to Github.

image-20260201013621992

A search for “Enterprise-THM github” led to a public Github organization: Enterprise.THM.

image-20260201013627754

Upon inspecting the Enterprise.THM Github organization, I identified a single member, Nik-enterprise-dev . HIs only repository, mgmtScript.ps1 , contained two commits; the initial commit revealed a set of sensitive credentials that had been subsequently removed in the next commit.

image-20260201013641977

image-20260201013648612

image-20260201013653969

SMB 139 445

SMB Null Authentication is allowed. However, I’ll come back to this later because I would like to test the credentials I found first.

I validated these credentials using NetExec , confirming that nik is a valid domain user.

Remote access via evil-winrm and xfreerdp failed for the user nik . This suggests that the account is not a member of the Remote Desktop Users group.

Kerberoasting

The valid set of credentials was sufficient to perform Kerberoasting attack. I identified the bitbucket as roastable.

The extracted has was cracked locally using hashcat and I got the plaintext password.

Shell as bitbucket

The bitbucket user was found to be a member of the Remote Desktop Users group. I established a session via xfreerdp and successfully retrieved the user flag from the desktop.

image-20260201013717793

Found user.txt

Privilege Escalation

whoami /priv showed that the account held SeAssignPrimaryTokenPrivilege . I attempted to escalate privileges using GodPotato, but the exploit failed with a Win32Error: 1314 .

While exploring the target host, I discovered two Office documents in C:\\WorkShare . Both files were password-protected. I extracted the hashes using office2john , but the cracking process was not yielding immediate results so I decided to move on to other enumeration methods.

image-20260201013727731

Bloodhound

BloodHound enumeration was performed to map out potential privilege escalation vectors. The results indicated that none of the owned users (nik, bitbucket, or contractor-temp) possessed direct paths to Domain Admins.

image-20260201013735407

PrivescCheck.ps1

I executed PrivescCheck.ps1 for automated analysis. The tool identified several high-risk vectors, with the most prominent being an Unquoted Service Path vulnerability.

Manual verification with icacls and accesschk confirmed that the current session has write access to the C:\\Program Files (x86)\\Zero Tier directory.

I also confirmed that the current user can restart the service to trigger the exploit.

I generated a reverse shell payload using msfvenom and specifically named it Zero.exe as it targets the first space in the unquoted service path.

I transferred the payload to the target machine and placed it within the C:\\Program Files (x86)\\Zero Tier\\ directory.

image-20260201013747934

Shell as SYSTEM

Upon restarting the service, the Windows executed my malicious Zero.exe binary, which triggered reverse shell callback to my listener, granting me a shell with SYSTEM privileges.

Found root.txt