Posted in Blog, Walkthrough

Basic Pentesting 2 Write-Up


It’s been awhile since I’ve done a CTF or boot2root, so time to work through another one. I’ll see how far I can get without looking at a walkthrough for a hint, but recognizing my time constraints, I have no problem going to a walkthrough when I get stuck. This is a step up from Basic Pentesting 1, so I’m curious what it’s going to look like. If you haven’t worked through Basic Pentesting 1, it would be good to do first if you are just starting out – my walkthrough for it is here.

Since there are some excellent detailed walkthroughs (a few listed below), this will not be a fully detailed walkthrough. I intend to provide basic steps and hints so that someone following along can get to the next step in the process but still have a bit to figure out independently. I like having the option of both types of walkthroughs when I’m stuck because it allows me to stretch where I can but not spend days chasing squirrels.



Pull down the necessary details for my Kali VM and scan the appropriate range for this lab. Netdiscover was being cranky and wouldn’t find anything for some reason. I may go back and try to figure out what at some point, but there are plenty of other tools available, so I’m not going to dwell on that now.

So on to fping -a -g <IP RANGE> to see what’s on the network. As expected, there are a few other hosts. Next up is nmap to identify which host is my target –

 nmap -sS -sV -O --osscan-limit IPRANGE -T5 -oN ./nmap.txt
 # -sS to to a SYN scan to be more stealthy
 # -sV to get version detection, not stealthy
 # -O to enable OS detection
 # --osscan-limit to limit OS detection to promising hosts
 # -T5 to speed things along
 # -oN to output to a file

A few notes on the nmap command because it is not how I would run the scan in an actual pentest. Using -sV and -O makes your scan much less stealthy. And running at -T5 is not a great idea in a production environment because it does depend on a very fast network and may result in decreased accuracy. Faster scans can also be harder on the target machine, so not something you want to use in a production setting. I use -sS and -oN out of habit to do a more stealthy scan and save the results (remember documentation is very important in pentesting), and add the other options because this is a lab.

Nmap results in brief:

  • 22/tcp open ssh – OpenSSH 7.2p2 Ubuntu 4ubuntu2.4
  • 80/tcp open http – Apache httpd 2.4.18 (Ubuntu)
  • 139/tcp open – netbios-ssn Samba smbd 3.x-4.x (workgroup: WORKGROUP)
  • 445/tcp open – netbios-ssn Samba smbd 3.x-4.x (workgroup: WORKGROUP)
  • 8009/tcp open ajp13 – Apache Jserv (Protocol v1.3)
  • 8080/tcp open http – Apache Tomcat 9.0.7
  • Running some variety of Linux, likely Ubuntu

Dirb results of interest and findings from digging around:

  • /development
    • ./dev.txt – notes about
      • struts 2.5.12, example REST version -K
      • SMB has been configured -K
      • Apache set up -J
    • ./j.txt
      • /etc/shadow – J’s password easily crackable
  • /icons
  • /index.html
  • /server-status
    • Forbidden error
    • Apache/2.4.18 (Ubuntu) Server


Photo by Miguel Á. Padriñán on

I wasn’t sure where to go next. In the interest of time, read through just enough of the InfoSec Institute walkthrough to get an idea of where to go next. The walkthrough used enum4linux, which is a great tool I’ve used before. So I’m kicking myself a little for allowing myself to get so out of practice.

That found 2 users – kay and jan. I dug a bit with the SMB options, but wasn’t getting anywhere. Back to the walkthrough, which used Hydra to target SSH for jan’s account.

 hydra <IP> ssh -l jan -P /usr/share/wordlists/rockyou.txt

I’m pretty sure using the full rockyou file was overkill, but it got the job done.

Logged in as jan and started poking around. I found that there were home directories for jan and kay. I could view the contents of kay, which included a pass.bak file. I couldn’t read it – so filing that away. There was also a .ssh folder that looks promising, but I wasn’t quite sure what to do with it. I should have kept digging on this, but decided to follow the walkthrough instead. Looked at the suggested Ubuntu 16.04.14 exploit, but decided against it based on the failure in the walkthrough and a dislike for connecting my targeted VMs to the internet.

The walkthrough went back to the .ssh folder at this point. I did some research on how to use ssh keys, which basically said letting other people have access to your private key is a bad idea (in case you needed to be told that). But it was helpful in figuring out what needed to be done.

A few helpful resources:

I pulled over the files using scp and tried logging in. Unfortunately, it asked for a passphrase. Had a bit of a brain fart at this point and got a little stumped at figuring out the passphrase. Back to the walkthrough where ssh2john key > sshtojohn was the next step. For some reason, this made no sense to me. I blame a lack of coffee. I tried the command, but I got the message that the command wasn’t found. Off to do some digging on the ssh2john option of John the Ripper. Basically, the command was just in a different place. I’ve used John the Ripper quite a bit, but obviously I need to spend some time getting more familiar with the tool. Pulled a couple of blog posts for review – Hacking Articles (Raj Chandel’s Blog) had a beginners guide. I’ve found this site to consistently have great info, so here are the posts:

Once I found where ssh2john was, it was pretty straightforward.

 locate sshjohn
 /usr/share/john/ /path/to/privatekey > /path/to/output
 john /path/to/output

Then sit back and wait while John does its thing. It cracked the passphrase, so back to logging in via ssh. I was able to login as kay with no problem. I did have to make sure that the private key was in the proper place to be connected to the root user since that’s who I was in my Kali box. Once I’m done with this VM, I’ll remove the key. If you are running into issues, running ssh with the -v flag should give enough info to figure out where the issue is occurring.

Once logged in as kay, I started poking around. Then realized I should just go cat the file I found earlier before chasing other squirrels. That was kay’s password, and I was able to execute sudo su and get root privileges on the box.

For kicks, I pulled over the /etc/passwd and /etc/shadow files to run them through John. I poked around a bit more, but since I’d gained root I didn’t spend a lot of time. I want to go back and try exploiting some of the other services that were available on the box and taking over the website. I also want to try the method used to get root by Jon Wood, which involved modifying the sudoers file. My initial impression is that you could make jan a sudo user by editing the file as kay, which would be pretty straightforward. And a little pointless since if you are logged as kay you already have root access. I did some digging on options to edit the file as jan without sudo, booting in live mode seemed to be a popular option, but not great for our situation.

Photo by Juan Pablo Arenas on

I looked at some great options for privilege escalation by exploiting sudo rights, but since jan isn’t in the sudoers file, it’s going to take something else. Took a peak back at the walkthrough, and it mentions linuxprivchecker…at which point I face palm because I’ve known about this for ages (from this Linux privilege escalation blog post). I don’t like putting my target VMs on the internet, so I decided to use scp. I couldn’t scp the file into jan’s home directory, so I tried switching the file to a .txt instead of a .py. Still no luck. Decided to try copying to a tmp directory and was able to copy over the .txt version. Then a quick rename and execute the exploit.

It pulled back a lot of information. Scrolling through I saw vi was on the list. Since I’d seen vi come up when I was researching the sudoers file, I decided to try editing sudoers in vi. I was able to edit the file and add jan as a sudo user. Of course, then I had to remember how to save/exit in vi. It exited out to a shell that looked slightly different (not with the typical user info for SSH), but I was able to sudo su and get root on the box. I was working in a shell in vi, which is something I need to look into more. It was good experience working through this method of getting root, but I think this would be low on my list to exploit in an engagement. Manipulating the sudoers file in vi carries some risk (understatement…), and it’s not something I would want to use in a production environment unless other options had been exhausted and the client understood and accepted the risk. I may be very willing to take risks and fork things in lab environments, but production is and should be a totally different situation.

Wrap Up

This was a fun box. I learned some new things, but the biggest lesson was that I need to make a point to keep working on different boxes to keep my skills sharp. Pen testing hasn’t been as high on the priority list, but I need to make time for it. It would be nice to go through and do all the work without relying on walkthroughs when I get stuck, but the reality is that’s not a great option for me right now. I think the next one I’ll look for one with a summary at the beginning – like this one – to give me some ideas without getting too specific.

Some key takeaways:

  • Need to make a point to regularly do CTFs of some sort
  • Need to spend some time learning some of the tools I use frequently in more depth
  • Make sure password policies are also applied to keys, etc.
  • Make sure keys, etc. have the proper permissions


Lifelong paradox - cyber sec enthusiast - loves to learn

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.