Manager
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 3000 10.129.52.107
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-22 20:53 +08
Nmap scan report for 10.129.52.107
Host is up (0.0069s latency).
Not shown: 65514 filtered tcp ports (no-response)
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
1433/tcp open ms-sql-s
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
5985/tcp open wsman
9389/tcp open adws
49667/tcp open unknown
49677/tcp open unknown
49678/tcp open unknown
49679/tcp open unknown
49716/tcp open unknown
57492/tcp open unknownLooks like an AD machine. Did a detailed scan as well:
A few things to note:
MSSQL is public-facing on port 1433
The domain name is
manager.htb, and the DC name isdc01.manager.htb, which I added to the/etc/hostsfile.
Web Enum -> Deadend
The web application shows a corporate page:

Running a gobuster directory and wfuzz subdomain scan nothing of interest. Moving on.
SMB -> User Brute Force
smbmap reveals that null sessions are allowed:
enum4linux also shows that SIDs can be enumerated without credentials.
As such, I tried to at least get a user list using crackmapexec and its RID brute force option, similar to the initial access steps for Rebound.
MSSQL Login -> Website Backup
There was one user that stood out obviously. Using crackmapexec again, we can try to brute force a username and password combination out for SMB and the MSSQL service. There were no credentials for the SMB service, but it did find one for the MSSQL server.
Afterwards, I logged in using mssqlclient.py:
Initially, I tried to enable xp_cmdshell, but our current user is unable to do so:
However, this does not stop me from using xp_dirtree and responder to grab a hash for the user.

However, this hash cannot be cracked. Since I couldn't find a hash, I can at least enumerate the file system using xp_dirtree. I knew there was a website, so I started there at the default file of C:\inetpub\wwwroot:
I found this .zip file. Within it, there's an .old-conf.xml file that contains some credentials:

Using this, I could evil-winrm in as the raven user.

Privilege Escalation
Basic Enumeration -> ESC7
This was an AD machine, so it was unlikely that the creator left behind a Windows / system exploit for the next step. I did the usual enumeration for:
Basic domain and kerberos enumeration via
PowerView.ps1.ACL Abuse via
bloodhoundcollectors.Certificate stuff using
Certify.exe.
The last one found something interesting.
Although no vulnerable templates were found, I noticed that the Raven user was given Allow ManageCA permissions. This is a misconfiguration that allows for the ESC7 attack.
The repository for certipy has all the commands needed to execute this attack. Take note that one of the commands is meant to fail in order to grab the private key.
Take note that these commands have to be entered FAST in order to prevent the machine from resetting halfway through and making the attack fail. Take note that <NUM> is to be replaced with the number in the private key file name (if it is called 13.key, then use 13 in the commands).
If done correctly, this will be the result:

Afterwards, I used certipy auth to grab the administrator user's hash.
Afterwards, I could evil-winrm in as the admin:

Rooted!
Last updated