Sideload
Challenge Lab (Hard) - by LainKusanagi
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
Objective / Scope
As a Red Team Operator, your objective is to establish initial access by compromising a critical Windows workstation. While this machine is currently in a workgroup and not domain-joined, it serves as a strategic machine for the engagement. Your task is to gain initial access and elevate your privileges.
Summary
Summary
In Sideload, we begin with external enumeration and uncover exposed SMB and RDP services, then leverage anonymous Guest access to readable shares and IPC$ RID brute forcing to enumerate valid users. By correlating a leaked penetration test report's weak password policy findings with username-derived wordlists, we successfully brute-force credentials for jade.moreno, gaining authenticated SMB access with write permissions to the IT share. From there, we identify a DLL sideloading opportunity in RDCMan.exe, use Spartacus and Procmon to generate a DWrite.dll proxy template, and weaponize it into a malicious sideload that preserves normal application behavior while covertly launching a custom in-memory Sliver stager. After planting the DLL in the writable share, the target executes it, causing lewis.hopkins to fetch our staged payload and return an mTLS C2 session. Finally, by recognizing that the compromised user is in the local Administrators group but restricted by UAC, we deploy the SspiUacBypass Sliver extension to elevate the session to NT AUTHORITY\SYSTEM, achieving full host compromise.
Recon
We use rustscan -b 500 -a sideload.hsm --top -- -sC -sV -Pn to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts -sC, service and version detection -sV, and treats the host as online without ICMP echo -Pn.
A batch size of 500 trades speed for stability, the default 1500 balances both, while much larger sizes increase throughput but risk missed responses and instability.
On the target machine we have SMB services 139/445 exposed. Remote access is also available via RDP 3389.
We enumerate the target using NetExec. Since we do not have any accounts available yet, we try the Guest user with an empty password. We are lucky - Access as Guest is granted and the $IPC share is readable, which would allow us to to enumerate additional users using rid brute force. Even better, there is also a share called IT where the Guest user has read permissions.
We connect to the share using impackets smbclient.py. Here we find a note, a eula, penetration test results, which can be extremely valuable and an executable called RDCMan.exe.
There is nothing in the Eual.txt nor in the notes.txt of use for us.
The penetration test report reveals some valuable insights, some of which we have already confirmed ourselves with the overly permisive file shares. The most interesting finding might be the 'Weak Password Policy' issue. No lockout was detected following a brute-force attempt, and passwords are easy to guess, such as a combination of a guessable words and a year are being used.
However, the other findings do not appear to be relevant to us at this point. The computer does not appear to be domain-joined, and our initial scan did not detect any MongoDB instances.
We note the following down:
We'll take a look at the RDCMan executable later.
First, we'll try to enumerate users. Since we have read access to the IPC$ share as the Guest account, we'll perform an RID brute-force attack using netexec, as mentioned earlier.
We run the RID brute force using NetExec and are able to determine two additional users.
We note them down.
Access as jade.moreno
We are following up on the first lead from the penetration test report and trying to determine the correct passwords for the users we have identified. We assume that we won't trigger a lockout, but we can't be completely sure.
Since we know two components of used password (a guessable word followed by a year) we create two lists. Then we combine them using the hashcat combinator tool.
As a basis for guessable passwords, we use the first and last names of the listed users and the ever-popular seasons of the year.
With the following command we combine both list and craft our wordlist.
We're trying to brute-force the RDP service using Hydra, but we're not getting any hits.
Let's run the command in verbose mode. We see that we do get a match, but the user doesn't have permissions for RDP. We could easily have overlooked that.
Alternatively, we can also use NetExec for brute-force attacks. We'll try this for both SMB and RDP. NetExec's output is very verbose, and with large lists, it can be easy to overlook hits. But by piping the output to grep, we get only what we want to see: the true-positive hits.
We see we have successfully authenticated as jade.moreno with one of the passwords of our wordlist.
We enumerate the shares again as jade.moreno, and see the same shares as with the Guest account. But this time we also have write permissions.
We can write to the share, but we can't replace the executable there. The first idea (assuming that the executable is run by the respective users using the share) is to replace it with an executable runnning a reverse shell.
Since we can't replace the executable, we can, however, try to influence what the executable loads at startup. The umbrella term for this is DLL Search Order Hijacking. Next follows a brief detour on DLL Sideloading (a specific case of search order hijacking) and DLL Proxying.
Detour
Dynamic Link Libraries (DLLs) are shared libraries in Windows that contain reusable code and resources. Instead of each application having its own copy of the same functionality, multiple programs can load and use a single DLL at runtime. This helps reduce memory usage and allows developers to update functionality in one place rather than modifying every application individually.
Applications load DLLs when they are needed, rather than embedding all functionality directly into the executable. When a program requests a DLL without specifying an absolute path, the Windows operating system uses a defined search order to locate the file.
DLL Search Order Hijacking
The concept of DLL Search Order originates from early Windows design decisions aimed at flexibility and backward compatibility. Developers were allowed to reference DLLs by name instead of full path, and Windows would resolve their location automatically. Over time, this convenience introduced security risks because attackers can abuse this concept.
DLL Sideloading
In DLL sideloading, the Windows DLL search mechanism is exploited to execute malicious code under the guise of the trusted application that is loading it. By placing a malicious DLL in a strategic location, the program is forced to load unauthorised libraries instead of the legitimate system DLLs.
When an application requests a DLL without specifying its full path, Windows follows a predictable search order to locate the file. This sequence determines which DLL gets loaded.
First, Windows searches the directory containing the executable; next, it checks C:\Windows\System32; then, it examines the main Windows installation directory, followed by the current working directory from which the application was launched. Finally, it searches all directories listed in the system path.
DLL Proxying
In DLL proxying, a malicious intermediary DLL is loaded that forwards the calls to the legitimate DLL after the malicious code has been executed. This maintains the legitimate functionality and is more stealthy. In general, in DLL hijacking, a malicious DLL is placed in one of the locations mentioned in the previous section, replacing the legitimate functionality entirely.
Further Resources
Shell as lewis.hopkins
As jade.moreno, we have write access to the IT share. So we could place DLLs there.
We move the executable to our own Windows instance to examine it further. RDCMan.exe is the Remote Desktop Connection Manager a Sysinternal tool to manage multiple RDP connections in one interface.
Preparation of DLL with Sideloading and Proxying capabilities
Spartacus is a tool for identifying potential DLL sideloading opportunities and generating code stubs that also handle the DLL proxying.
However, the tool also requires the Sysintenal procmon.exe.
We now have the Spartacus Project, Procmon, and RDCMan on our Windows host for exploit development.
We run Spartacus to find which DLLs are hijackable, exports their definitions and generates a cpp template that we can open with Visual Studio that won't break the specific PE when we DLL side-load.
--mode dllTells Spartacus to scan for DLL hijacking opportunities specifically--procmon .\Procmon.exeProvides the path to Process Monitor so it can capture runtime file activity--pml C:\Users\0xb0b\Documents\Data\logs.pmlUses the recorded Procmon log file as input for analysis--csv C:\Users\0xb0b\Documents\Data\VulnerableDLLFiles.csvOutputs discovered vulnerable DLL load paths into a CSV file--solution C:\Users\0xb0b\Documents\Data\SolutionsSaves generated Visual Studio–ready DLL proxy/source templates into this folder--verboseEnables detailed logging so you can see what the tool is doing step by step
Next, we need to run the RDCMan.exe.
After running RDCMan.exe we need to hit enter to terminate the process monitor and parse the output. A list of vulnerable DLL files will be created and several solution templates are generated.
We end up with a folder like the following:
We can identify several DLLs to hijack and use as a proxy. We chose the DWrite.dll.
We load the project and retarget it to the platform toolset.
We have the following dllmain.cpp infront of us. With the pragmas the proxying is performed by telling the linker to forward the export DWriteCreateFactory from your malicious DLL to the real implementation inside C:\Windows\System32\DWrite.dll, so our DLL exposes the same function (ordinal 1) and transparently proxies the call to the legitimate one while still letting us run our own code beforehand or after.
We are extending the code so that the calculator is executed when our DLL is loaded, while still preserving the functionality of the program via proxying to the original one via the pragma.
We build the projectect...
... and end up with a malicious DWrite.dll that will execute the calculator if loaded.
We place the DLL inside the the current working directory from which the application is launched.
Next, we run the RDCMan.exe and the calculator pops up while still preserving the functionality of the executable.
The idea now is to run our stager we crafted in Staged to establish a connection to our Sliver C2.
To do this, we are extending the PayloadThread function with the following code:
To download and execute our stager payload, we use PowerShell with the -WindowStyle Hidden flag to ensure that no terminal window is displayed. Instead of using system(), which would still cause a console window to briefly appear, we leverage CreateProcessW() for a more discreet execution for the victim running the executable.
Additionally, we made a small modification to the stagers compilation so that is a GUI application rather than a console application. This will be shown in the next section (Perparation of Stager).
It's pretty simple and bold but is enough to solve the lab.
This approach is noisy and easily detectable, violating Red Team Operations (RTO) principles because it uses obvious techniques like spawning PowerShell and making a clear-text web request to download an executable. It lacks stealth, proper evasion, and in-memory execution, which are core to maintaining operational security during engagements.
The DLL executes payload logic directly from DllMain, spawns a thread immediately and keeps the DLL "busy" while doing network and process creation.
The problems this causes are, that CreateProcess are unsafe here, we can deadlock or crash the host process and the host .exe stays tied to your payload execution.
Preparation Of Stager
Prepare a custom stager
First we need to prepare the stager.
The stager fetches raw shellcode from a chosen URL and loads it directly into memory as bytes. The payload is not embedded in the binary, allowing it to be changed without recompiling.
It calls VirtualAlloc to reserve and commit memory with execute, read, and write permissions, then copies the downloaded shellcode into that memory using unsafe pointer operations.
The execution is transferred to the allocated memory address using syscall.Syscall, handing control to the shellcode.
We compile the stager as follows on our exegol instance:
The addition of -ldflags="-H windowsgui" ensures that we compile it as an application and not a console app, so it wont spawn a terminal.
Generate shell code
During generation without the -G tag, which disables the encoder, no shellcode could be successfully generated. The resulting shellcode was always empty. This may be related to the underlying architecture on which I am operating, namely ARM:
Next, we need to generate the shell code insed our sliver instance. We do this as follows:
Execution
We run a web server from which the stager and the shellcode can be fetched.
Setup listener
We set up the listener in sliver as follows:
Next, we place our malicious DLL into the share and wait.
After arround 2-3 minutes we see that or stager is getting fetched. Shortly after the shell code is fetched and loaded.
We get a connection back to our listener in Sliver.
To interacte with the session received we issue sessions -i <id>.
We are lewis.hopkins.
The user flag can be found at /Users/lewis.hopkins/Desktop/user.txt.
Shell as Administrator
With sa-whoami in Sliver we can simulate a whoami /all commmand. Here we see we are memeber of the local administrators, but currently in a medium integrity shell.
We try to perfom a UAC Bypass. On our first research we stumble upon a Sliver extension for bypassing UAC via cmstp which is written in Rust. Unfortuntatley it fails.
We are looking for further UAC bypass modules for Sliver and have found the following:
It was found while researching arround the topic of DLL Sideloading, Proxying and general RTO tatics. Turns out to be pretty valuable resource for further research on different topics regarding RTO.
We follow the instructions to install the different UAC Bypass techniques for sliver. For this challenge we got successful with the SspiUacBypass. This forges a token from a fake network authentication though SSPI Datagram Contexts. It will then impersonate the forged token and use CreateSvcRpc.
Next we load the module.
We'll run our stager again using the bypass. We had to place it in C:\IT\0xb0b.exe, since it appears the user doesn't have access to C:\Windows\Temp.
After execution we receive another session. We interact with it and see we are NT AUTHORITY\SYSTEM. The final flag can be found at C:\Users\Administrator\Desktop\root.txt.
Recommendation
I came across the following blog while researching on how to solve the scenario, and I would recommend it for further use on other topics:
Last updated