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  unknown

Looks 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 is dc01.manager.htb, which I added to the /etc/hosts file.

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 bloodhound collectors.

  • 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