Leveraging PowerShell During Exploitation
Scenario
You have been tasked by an organization to conduct a penetration test. Suppose that the organization's internet-facing machine is accessible at demo.ine.local. There is another machine (fileserver.ine.local) which is not directly accessible.
Task: Perform remote exploitation and post-exploitation tasks on vulnerable systems, gain access to both machines and retrieve the flag!
Learning Objectives
Identify vulnerabilities from a remote exploitation perspective.
Exploit discovered vulnerabilities.
Obtain access to machines (that are not directly accessible)
Use PowerShell and related tools for tasks where applicable.
Recommended tools
Empire
Smbexec
Nmap
Metasploit
Tasks
Task 1: Identify a vulnerability in an internet-facing System. Use that vulnerability to obtain access and execute remote commands
One of the systems accessible on demo.ine.local contains a vulnerability or misconfiguration. Identify the vulnerability or misconfiguration and obtain access to the vulnerable target with the ability execute commands.
Task 2: Use Empire to obtain a connection from the target via an Empire Agent
Using your ability to execute remote commands on the vulnerable system, use Empire to generate a PowerShell-based stager and obtain an agent connection from the target, and furthermore conduct some recon about the system and internal network using Empire modules.
Task 3: Exploit a second system that is not directly accessible.
Use the compromised system as a pivot to exploit the fileserver.ine.local machine.
Solutions
Below, you can find solutions for each task for the Remote Exploitation and Post-Exploitation tasks. Remember though that you can follow your own strategy (which may be different from the one explained in the following lab).
Note: The IP addresses of lab machines are different for every invocation. So, please check the IP addresses of the lab machines before performing activities.
Task 1: Identify a vulnerability in an internet-facing System. Use that vulnerability to obtain access and execute remote commands
Step 1: Using Nmap, we conduct a port scan on demo.ine.local
From the scan, we observe a lot of open ports.
The attempt to reach fileserver.ine.local machine from Kali machine, will fail.
So, it is verified that as per the challenge, Kali machine can't access the fileserver.ine.local machine directly.
Step 2: Run a scan for all 65535 TCP ports of demo.ine.local machine to start our enumeration process.
Most of the time, scanning all ports will take a lot of time. So, it is a good idea to scan smaller ranges at a time e.g. scanning first 5000 ports, then next 5000 and so on.
The port scan reveals several common ports, but more importantly, there are several which catch our attention due to being unknown, or unidentified at this point in the engagement. In particular, we'll focus on port 4983 since after enumerating several of the others, returned nothing particularly fruitful.
A service scan reveals that this is potentially an HTTP port, we can we can see with the banner returned by an nmap version scan.
Step 3: Our next step, is to see if we can gain any more additional insight as to the purpose of this port, we can browse to it.
A set of credentials are present on the web page. It appears that these credentials are of this same machine.
Now that we've obtained some credentials, we can try and use those credentials to execute commands using the "smbexec.py" tool (part of the impacket toolkit). We know the system is exposing NetBIOS ports, so we will attempt to exploit those ports with our newly obtained credentials.
Step 4: We use smbexec to get a semi-interactive shell on the target (possible since we found a privileged set of credentials):
Note: A quick note about smbexec.py. Every so often, if you exploit the machine with the above method, and it fails, or disconnects for whatever reason, due to the way smbexec creates a BTOBTO service, it may fail to delete the created service causing re-exploitation to fail. This may require a machine reset if in the rare case you need to re-exploit the machine using that specific attack vector.
We have a shell on the demo.ine.local machine. Check the current user.
Check the interfaces and IP addresses associated to the compromised machine
Lets try to ping the second machine fileserver.ine.local
The ping is working from this machine. So, we can attack the fileserver.ine.local machine by using this machine as a pivot.
Task 2: Use Empire to obtain a connection from the external target via an Empire Agent
Our next task is to obtain a connection from the system back to an Empire listener.
Step 5: Start the powershell empire server in a new terminal.
Once the server is ready, we can start the client.
Before doing that, open a new terminal tab to check the IP address of the Kali machine and make a note of it. We will need it multiple times.
Similarly, you can use ping commands to check IP addresses of both target machines i.e. demo.ine.local and fileserver.ine.local.
Note: The IP addresses are different for every lab. So, please make sure that you are using the correct IP addresses and not the one mentioned in this manual.
Step 6: Start the powershell empire client in a separate new terminal.
At the (Empire) > prompt, configure a new "http" listener by issuing the "uselistener" command followed by "http," which will put us in the http listener configuration area:
Set the "Host" option with IP address of our Kali machine and also set port.
Once that is complete, we use the "execute" command to initialize our listener:
Step 7: Now that our listener is up and "listening," we'll want to generate a "stager." The "stager" is the code we're going to run on our target once we generate it. We can generate a stager by first exiting out of the "Listener" area back to the "main" section by executing the "main" command and then typing the "usestager" command. If we type "usestager " we should get a listing of all available stagers:
We'll select the "multi/launcher" stager by issuing the "usestager multi/launcher" command:
And again, we'll configure the necessary options, which is typically just telling the stager which listener to connect back to. We use the "set Listener " command here. In this Example, our listener name was "http":
Once our stager is configured with the name of the listener, we can once again type the "Execute" command to have Empire generate our stager code:
At this point, Empire has generated a PowerShell encoded command. We then copy and paste the Empire-generated PowerShell code, to our smbexec shell and press .
Upon doing so, we should receive an agent connection back to our Empire listener:
If we now type the "agents" command within Empire, we can confirm our agent has phoned-home to the Empire C2 and is currently active via the "powershell" process on the target system:
We have an powershell empire agent running on the demo.ine.local machine.
Step 8: Interact with the agent and run a few empire modules on it. Empire also supprts command autocompletion feature.
Try checking "computerdetails" module with the "usemodule" command:
The information about the system is shown by the agent.
Lets perform a scan on the second machine i.e. fileserver.ine.local. Do not use the URL directly in RHOSTS as it might not work if the DNS/hosts entry is not there on the compromised machine. Figure out the IP address of the machine by using ping command on the Kali machine and use that.
Port 80, 3389, 445, 139, 135, 49152, 49154, 49153 are open on the second machine.
Task 3: Exploit a second system on the internal Network
Now that we can reach the second machine i.e. fileserver.ine.local, and have identified open ports, let's move onto pivoting from our current host to the new one.
Since we're going to need some additional tools (Metasploit) to accomplish the next task, we need to transfer our existing Empire Agent over to Metasploit. We can use the Empire "invoke_metasploitpayload" module for this. The module, as its name implies, allows us to execute a Metasploit payload, which will effectively send our empire agent to a listener we have configured within Metasploit.
Our first step is to generate a payload we can feed to the Empire agent. We'll use Metasploit's "web_delivery" module for this. The web_delivery module will allow us to generate a powershell payload URL, which we will then provide to the empire agent via the "invoke_metasploitpayload" module.
Step 9: Run Metasploit and prepare the "web_delivery" module.
Next, we set the "target" option to "2" in order to use a compatible powershell payload:
We then configure our SRVHOST IP address option. This is the IP address of Kali machine.
Lastly, we configure a payload option and our LHOST IP for the payload. We'll use a windows meterpreter reverse_tcp payload:
And finally, we run the "exploit" command to initialize our handler, and generate our PowerShell Payload URL:
We're going to use the URL identified by the "Using URL:" message in the above web_delivery module output.
http://10.10.15.2:8080/E8tlUIOl
Back at our Empire C2, in order to pass our agent to metasploit, we need to load the "invoke_metasploitpayload" module.
We then configure the "URL" value to be that of our metasploit web delivery URL and assign the stager to an Active agent in Empire, and finally, when that is complete, we can use the "Execute" command.
Upon doing that, our Metasploit handler has now received a connection from the agent.
The session can be listed with sessions command.
We can continue with our task of pivoting and exploiting the second machine.
Note: If you were not able to establish a Meterpreter session, please kill any current Metasploit jobs (jobs -K) and try again with a x64 listener and payload. It will work just fine!
Step 10: Now that we've transferred our agent to Metasploit, we'll first want to run the "autoroute" module on our new meterpreter session. This will add the necessary routes to the Metasploit routing table that will allow us to pivot to the 10.0.28.181 machine:
Now that our routes to the 10.0.16.0/24 network are in place, we can use the socks_proxy module to proxy through demo.ine.local machine and conduct additional recon:
We'll then set our proxy SRVHOST value to be that of our Kali machine IP address, and run the module:
Step 11: Next, after configuring the socks proxy module, we need to configure our browser to use our socks5 proxy.
Open Settings in the Firefox browser and search for proxy.
Then select Network Settings to open the connection settings. Select SOCKS Host and provide IP address of the Kali machine and port as 1080.
Open another tab in the firefox. We should able to browse to fileserver.ine.local machine and we observe that BadBlue enterprise edition is running on the remote machine.
Step 12: Search for badblue related modules in Metasploit.
There are two modules related to badblue. We will select the second one. Set the RHOSTS and PAYLOAD.
Once everything is ready, run the exploit.
This results into a meterpreter connection to the fileserver.ine.local machine. Check the PWD (Present Working Directory) and change to C:\
List the contents of the C:\ directory
We can observe flag.txt file in the list of contents. Print the contets of the flag.txt file.
Last updated