Hack Smarter Security
Can you hack the hackers?
This work by Manav G Krishna is licensed under CC BY-NC 4.0 
Machine IP: 10.10.112.96
Nmap Scan:
From the scan we straight away notice that there is Anonymous FTP Login and we can also see the listing.
Connecting to the FTP Server:
Command :
We can connect with the Name being anonymous and the Password can be left empty or we can use anonymous.
Downloading the files from the server:
We notice that the stolen-passport.png didn't get transferred correctly. This is cause image files are usually stored in binary format. ASCII mode is the default for the majority of FTP servers and to transfer image files without any corruption we switch to the Binary mode.
Switching to Binary mode :
Now the .png file has downloaded successfully.
Checking out the files:
The first file - Credit-Cards-We-Pwned.txt has some credit card information:
There are more lines in that file in a similar fashion.
The second file - stolen-passport.png :
We can run exiftool to see if we get some metadata from the image:
Command:
No good information in here.
Checking out port 80:
We can see what Wappalyzer tells us:
We now know that the web server running is IIS.
We have a contact form here:
Testing out a basic XSS Payload:
Now let's set up a netcat listener on port 80. If the above payload works we should be getting a connection back on our listener which basically shows that the server has reached out to our machine. The IP specified in the payload is the tun0 interface IP.
But unfortunately we don't get any connection on the listener.
We can now do some directory busting to see if we get any juicy paths:
Command:
Nothing interesting here either.
Checking out port 1311:
SpeedGuide tells us that this port is used by Dell OpenManage HTTPS .
Upon googling - port 1311 vulnerability, we come across this result from tenable:
Let's keep this aside for now and check out the website:
The certificate didn't have anything much in it.
We are presented with a Dell OpenManage Server Administrator (OMSA) login page. Dell EMC OpenManage Enterprise is a unified systems management console designed to take complexity out of the IT administration experience.
Note:
Accessing the port over HTTP gave us this: Bad Request This combination of host and port requires TLS. This basically shows that we had to access it via HTTPS which is what we had done.
The stuffs present in the tenable research blog matches with what we see in the login page. We have the exact dialog boxes as mentioned in the blog. It is a CVE and it says - An unauthenticated remote attacker can login to OMSA as admin without knowing a correct OS username and password on that system
This indeed sounds juicy, let's give it a try.
Following the POC:
But this didn't work as expected as it gave us a Login failed error:
Moving on.
We notice there is an About section. Let us check it out:
And now we have the version: 9.4.0.2
Note: The About page does take some time to load, so just wait it out.
Now let us use this version to find exploits:
Upon googling - dellemc 9.4.0.2 exploits we get this result from Rhino Security Labs:
It is a file read vulnerability in Dell OpenManage Server Administrator (OMSA).
The blog explains the vulnerability really well and there is also a POC in there:
Usage:
Command:
We know from before that the web server running is IIS and also from the Nmap Scan we can see ports: 22 (SSH) & 3389 (RDP) open. Keeping all this in mind the main file that we could try to read is the web.config file. It is an XML file containing rules for a particular site (or directory) on a web server.
This file is located within the C:\inetpub\wwwroot which is the default root directory for websites hosted on IIS.
In our case the name of the website hosted on the IIS web server is - hacksmartersec. We can see this in the Nmap Scan under the 1311 port information (commonName=hacksmartersec)
The exact location: C:\inetpub\wwwroot\hacksmartersec\web.config
Let us read this file now:
We can see that we have a password for the username - tyler
We can now SSH in as this user:
Command:
We can find the user flag in the Desktop folder of tyler.
Checking if we are part of any interesting groups or if we have any juicy privileges:
Command:
There is nothing of interest.
Checking if Defender is active:
Command:
And yes, we can see that the STATE is RUNNING.
We can still try to execute scripts like winPEAS.ps1 , PrivescCheck.ps1 etc. to find vulnerabilities if any:
Also tyler had Full Control (F) on the Desktop folder:
Command:
Full Control (F) refers to the highest level of permissions that can be granted to a user or group in a Windows security context. When a user or group is assigned Full Control permissions, they have complete control over the object to which the permissions apply.
So we can put our scripts in the Desktop folder.
Executing winPEAS.ps1:
Upon trying to run the script post sending it via wget (After setting up a python server on port 4545 - python3 -m http.server 4545), Defender was flagging it as a virus. Also any port can be used to serve the file.
Command:
We can now try to do an AMSI Bypass. For more information check this out:
The script now starts running without any issues.
Note:
Running WinPEAS was taking so much time and it wasn't giving me any good information. I then decided to switch to PrivescCheck. Also the .exe of WinPEAS and a few other scripts that I tested were getting flagged even after running the command that could bypass AMSI. I have shown only the one's that worked for me in this writeup.
Executing PrivescCheck.ps1:
When trying to run it, it did without any issues. It wasn't getting flagged by Defender. This is actually one of the few scripts that usually don't get flagged. This time I set up a python server on port 4646.
Command:
Command:
Now we just wait for it to find something worthy that could help us in rooting the machine.
It has found a vulnerability that is rated High that let's us Privilege Escalate as this service is running under the SYSTEM account and we can start and stop the service:
Explanation:
Name: Indicates the name of the service or process, which in this case is spoofer-scheduler.
ImagePath: Specifies the path to the executable file (spoofer-scheduler.exe) associated with the service. It's located in the directory C:\Program Files (x86)\Spoofer.
User: Indicates the user account under which the service is running. In this case, it's running under the LocalSystem account, which is a built-in Windows account with high privileges.
ModifiablePath: Specifies the path where the service's files and configurations are stored. In this case, it's located in the directory C:\Program Files (x86)\Spoofer.
IdentityReference: Specifies the security principal or group that has permissions to access or manage the service. In this case, it's the Users group (BUILTIN\Users).
Permissions: Lists the specific permissions granted to the Users group for this service. These permissions include WriteOwner, Delete, WriteAttributes, Synchronize, ReadControl, ListDirectory, AddSubdirectory, WriteExtendedAttributes, WriteDAC, ReadAttributes, AddFile, ReadExtendedAttributes, DeleteChild, and Traverse.
Status: Indicates the current status of the service. In this case, it's Running, meaning the service is currently running.
UserCanStart: Specifies whether users have permission to start the service. It's set to True, indicating that users can start the service.
UserCanStop: Specifies whether users have permission to stop the service. It's also set to True, indicating that users can stop the service.
Privilege Escalation to SYSTEM:
Firstly let us get into the folder where the spoofer-scheduler.exe is located:
From the PrivEscCheck output we know that the service - spoofer-scheduler is currently running.
Thinking Process:
Since we know the service is running under the SYSTEM account and that we have Write permissions on that folder where the spoofer-scheduler.exe is located (based on the PrivEscCheck output), we can remove and replace that binary with our reverse shell binary having the same name. Since the service is currently running, we would have to stop it first to remove the file and once replaced, post starting the service we should be getting a shell as SYSTEM.
Confirming that we can write into the folder:
Command:
The user that we have a hold on - tyler if we recollect is part of the BUILTIN\Users group and member of this group has Full Control (F) on the Spoofer folder where the binary is located and that users belonging to this group can manage the service.
Stopping the spoofer-scheduler service:
Command:
Confirming the same:
Command:
We can see that the Status is Stopped.
Now we can remove the original spoofer-scheduler.exe:
Command:
Now we can make use of a tool called powercat for the shell:
Command:
This basically creates a reverse shell.
This PowerShell script has to be converted to an .exe format. To do this we will be using this online tool:
Now we send the spoofer-scheduler.exe containing the shell to the machine. The python server being used to serve the file is the one on port 4545 itself:
Command:
Setting up a netcat listener on port 4444:
Command:
Starting the spoofer-scheduler service:
Command:
Let us go back and check our listener:
We have successfully got a shell as SYSTEM . The shell will die pretty soon here.
The last answer we can find in this path:
C:\Users\Administrator\Desktop\Hacking-Targets\hacking-targets.txt
Note:
Now I will be showing an other script or method that I used to bypass Defender to get a SYSTEM shell which doesn't die.
Go Script to Bypass Defender:
We have to firstly clone the repo:
Command:
Once that is done, we can start to get it working:
Command:
This basically starts the main engine and it generates the payload or the implant along with a few other files that it needs to function as intended and it also sets up a HTTP server to serve the needed files:
Out of the attack files that it generates, the update_script.go is the payload file. It also sets the listening port as 443 by default which helps in evading any detections in place most of the times.
So we set up a netcat listener on port 443:
Command:
Compiling the .go file to an .exe file:
Command:
This generates a file named - update_script.exe:
Now we have to change the file name from update_script.exe to spoofer-scheduler.exe as that was the binary in question based on the PrivEscCheck output:
This file must be now served or sent to the machine. This time I set up a python server on port 4848 and before we send the file we have to start the spoofer-scheduler service which is stopped at the moment (Apparently since starting it triggered the shell previously, the service was actually in the STOPPED state after the shell died). Since spoofer-scheduler.exe is already present on the machine from what we had done when using powercat, it must be removed and replaced with the new one.
Command:
Starting the spoofer-scheduler service:
Let us now start the service. For starting the service in PowerShell check the command mentioned in the Privilege Escalation section.
We can also start it in cmd like this:
Command:
The moment we start it, we can see the files that the Go script needs to work as needed, being served from the HTTP server that the script had set up initially:
Checking out our listener:
Yet again we have a SYSTEM shell. This shell doesn't die like how the powercat shell did. The Nim shell that I have mentioned below also did die soon.
An other way to root this machine is by using a reverse shell written in Nim that goes undetected by Defender, like how powercat and the Go script generated payload went through without getting removed. Tyler himself has made a video on this, do check that out:
Room solved!!
Last updated