Nmap

Like always, I’m going to scan the IP Address by using nmap but I’m going to scan the full port first. Then, I’m going to scan the only open ports.

# Nmap 7.95 scan initiated Sun Feb  2 22:53:51 2025 as: /usr/lib/nmap/nmap -sCV -p135,139,3268,3269,389,445,464,47001,49152,49153,49154,49155,49157,49158,49165,49166,49168,53,5722,593,636,88,9389 -oN nmap/scripts.txt 10.10.10.100
Nmap scan report for 10.10.10.100
Host is up (0.042s latency).

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
| dns-nsid:
|_  bind.version: Microsoft DNS 6.1.7601 (1DB15D39)
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-02-02 14:37:32Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: active.htb, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: active.htb, Site: Default-First-Site-Name)
3269/tcp  open  tcpwrapped
5722/tcp  open  msrpc         Microsoft Windows RPC
9389/tcp  open  mc-nmf        .NET Message Framing
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49152/tcp open  msrpc         Microsoft Windows RPC
49153/tcp open  msrpc         Microsoft Windows RPC
49154/tcp open  msrpc         Microsoft Windows RPC
49155/tcp open  msrpc         Microsoft Windows RPC
49157/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49158/tcp open  msrpc         Microsoft Windows RPC
49165/tcp open  msrpc         Microsoft Windows RPC
49166/tcp open  msrpc         Microsoft Windows RPC
49168/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1, cpe:/o:microsoft:windows

Host script results:
| smb2-time:
|   date: 2025-02-02T14:38:27
|_  start_date: 2025-02-02T14:31:50
| smb2-security-mode:
|   2:1:0:
|_    Message signing enabled and required
|_clock-skew: -16m26s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Feb  2 22:55:02 2025 -- 1 IP address (1 host up) scanned in 71.08 seconds

The Nmap scan was completed, revealing a large number of open ports on the target machine. Based on the ports, it appears that this machine is part of an Active Directory environment.

Nmap also identified the domain name as active.htb, which I added to my /etc/hosts file.

SMB: Smbmap

Next, I enumerated SMB. The first step was to check share permissions using smbmap with anonymous access. It turned out that the Replication share had READ ONLY permissions.

SMB: Smbclient-ng

I connected to the share using smbclient-ng. Inside the share, I ran the tree command, which showed a large number of directories. To avoid manually browsing, I downloaded all the files using the get -r command.

Groups.xml

After examining the downloaded files, I found credentials in a file named Groups.xml. At first, I wasn’t sure what this file was for.

After some research, I came across this blog, which explained that it is a configuration file for domain-attached machines using Group Policy. The file contained a cpassword field with an encrypted string (Microsoft encrypts it using AES).

Gpp-decrypt

I continued researching and found a blog about decrypting GPP. Using gpp-decrypt, I successfully decrypted the password.

Now that I had valid credentials, I went back to SMB to check whether I could log in. Surprisingly, I was able to access many additional shares.

After enumerating all accessible shares, I didn’t find anything particularly interesting. However, I did find the first flag, which is user.txt.

LDAP: Ldapsearch

Since I found nothing valuable on SMB, I moved on to LDAP. I enumerated all users and found that there weren’t many accounts on the machine.

At this point, I got stuck. Since this machine was retired, I checked the official writeup, which showed that I could enumerate users using impacket-GetADUsers. As a reference for myself, here’s the screenshot:

Kerberoasting

I wasn’t familiar with kerberoasting, but I found this article explaining it. Based on my understanding (I could be wrong):

The official writeup showed how to find users with SPN using ldapsearch. I ran the following command:

ldapsearch -x -H 'ldap://10.10.10.100' -D 'SVC_TGS' -w 'GPPstillStandingStrong2k18' -b "dc=active,dc=htb" -s sub "(&(objectCategory=person)(objectClass=user)(!(useraccountcontrol:1.2.840.113556.1.4.803:=2))(serviceprincipalname=*/*))" serviceprincipalname | grep -B 1 servicePrincipalName

The results showed that the Administrator account was configured with an SPN. I used impacket-GetUserSPNs to request a TGS ticket and saved the output to kerberoast.hash.

However, I encountered an error: "KRB_AP_ERR_SKEW (Clock skew too great)". To fix this, I synchronized my machine’s time with the target using sudo ntpdate -u 10.10.10.100 command. After that, I reran the command, and it was successful.

PsExec

I cracked the hash using hashcat with the rockyou.txt wordlist. It successfully cracked the password.

Finally, I logged into the administrator account using impacket-psexec. I was now inside as NT AUTHORITY\SYSTEM.