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:
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.
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.
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.
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.
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!
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
Why it gets flagged:
Known msfvenom stub
Static PE signature
Very widely fingerprinted
This one:
Uses standard metasploit loader
Reverse shell stub is signatured
Defender deletes it almost instantly
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:
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
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
This code was then cross-compiled into a Windows DLL using MinGW:
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.
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.
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.
Last updated