Description
Active is a Windows Server 2008 R2 Active Directory Domain Controller. The attack path features a well-loved attack, Kerberoast.
Active is assigned IP 10.10.10.100.
Reconnaissance
We start every box by identifying the target and running a port scan against it.
Nmap (minus some extra Windows stuff)
# nmap -v -sC -sV -oA nmap/active 10.10.10.100
PORT STATE SERVICE VERSION
53/tcp open domain Microsoft DNS 6.1.7600 (1DB04001) (Windows Server 2008 R2)
| dns-nsid:
|_ bind.version: Microsoft DNS 6.1.7600 (1DB04001)
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2018-07-29 17:35: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)
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2, cpe:/o:microsoft:windows
Host script results:
| nbstat: NetBIOS name: DC, NetBIOS user: <unknown>, NetBIOS MAC: 00:50:56:b9:11:3f (VMware)
| Names:
| DC<00> Flags: <unique><active>
| ACTIVE<00> Flags: <group><active>
| ACTIVE<1c> Flags: <group><active>
| DC<20> Flags: <unique><active>
|_ ACTIVE<1b> Flags: <unique><active>
Active appears to be a Windows 2008 R2 Active Directory Domain Controller for the ACTIVE.HTB domain. Since this is a Windows computer, we should see if any shares are available to us from a null session.
Getting User
One of the first things to check on any Windows server is SMB null sessions. For this, we can use smbmap
.
SMBMap
Active does allow null sessions to connect to the Replication share. Enumerating further:
According to adsecurity, Groups.xml is a file that is distributed via Group Policy that can (among other things) create local users, set scheduled tasks, and change the local Administrator password. It may have very useful information.
It is possible to download the file using smbmap by setting the --download
flag followed by the full path to the file, in this case Replication\active.htb\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Preferences\Groups\Groups.xml
.
After downloading the file, we can view the contents (which I have formatted for easy reading):
Groups.xml
<?xml version="1.0" encoding="utf-8"?>
<Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}">
<User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}" name="active.htb\SVC_TGS" image="2" changed="2018-07-18 20:46:06" uid="{EF57DA28-5F69-4530-A59E-AAB58578219D}">
<Properties action="U" newName="" fullName="" description="" cpassword="edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ" changeLogon="0" noChange="1" neverExpires="1" acctDisabled="0" userName="active.htb\SVC_TGS"/>
</User>
</Groups>
Based on the Groups and User tags, this is modifying or distributing an account named active.htb\SVC_TGS, which is clearly a domain joined user. Under Properties, the cpassword
tag holds a password encrypted by an AES-256 private key.
This would be a problem, if Microsoft hadn't released the 32-byte key sometime before 2012.
Kali comes with the gpp-decrypt
utility, which is built specifically for this task. Running it on the encrypted password reveals the user account's password in plaintext.
So the password for SVC_TGS is GPPStillStandingStrong2k18. To test the credentials, we can run any utility that authenticates against AD, such as Impacket's GetADUsers.py
script.
GetADUsers.py
The credentials we have are valid, and Administrator appears to be the only account to target at the moment. We can attempt to run psexec.py
(also Impacket) on the target to get a shell, but the account doesn't appear to have write access to any shares.
psexec.py (no shell)
What we can do is access the Users share and read from the user's home directory and get the user flag in Users\SVC_TGS\Desktop
.
Getting Administrator
While searching for methods to escalate our privileges, it's likely that we would run Impacket's GetUserSPNs.py
.
It appears that a CIFS service is running on the Administrator account. We may be able to perform a Kerberoast attack on the service and gain access to the Administrator account.
There are plenty of excellent guides on what Kerberoasting is and how it works, so I will provide some resources and keep my own explanation brief.
Since the Administrator account is running a service (CIFS) on the machine, it has a SPN set on the account. Since we possess the ability to obtain a valid Kerberos TGT ticket, we may request a Kerberos TGS service ticket for any SPN from any domain controller we can authenticate to. Parts of the TGS we obtain will be encrypted with the password hash of the service account (in this case Administrator), meaning that we can brute force the credentials offline without ever knowing the actual password hash of the account.
Sunday Dinner, aka How I Kerberoasted Your Domain and You're Gonna Like It
To perform the attack from a non-domain joined computer, the easiest method is to use GetUserSPNs.py
to view any beef roasts SPNs we fancy (repeat image for continuity purposes).
If there are SPN's we like the looks of (such as that CIFS service on the Administrator account), we simply add the -request
flag and execute again:
Finally, take your silver ticket and throw it into your oven password cracker of choice. I use hashcat.
Now that we have the Administrator account password, we can use psexec.py
to execute commands and obtain a shell on the target system.
This concludes the guide of Active from Hack the Box.
Go Top