HTB Academy Labs - Footprinting (Medium)

Today we'll be be going through HTB Academy's second-stage lab on Footprinting. This one was good fun when I did it the first time around and I can potentially see some places where those of us on a newish journey into the wonderful world of pentesting might get tripped up. In this post, I'll share my approach to the lab and hopefully give you some ideas on how you may approach this one and build out your own attack methodologies. Let's give it a go!

Because we're looking at a second-stage lab, I would highly recommend you tackle the first-stage lab before going after this one. Better still, go through the very comprehensive Footprinting modules, if you have the cubes. There is a metric ton of information there that will help, not just with this lab, but with your building out your own approach for interacting with certain protocols and technologies.

Before we get started, we want to know what our end goal is. For this lab, HTB Academy wants us to get the password for a user called HTB. We now know the goal. Let's get started.



As we always do, let's start with a simple scan to get the lay of the land.

So we've got what looks to be a lot going on here. Straight away we can see some open ports for NFS, RDP, and SMB. What I tend to do in these situations is just pick a protocol and exhaust all the possibilities I can think of, before moving on to something else. Go with your gut. Often times it will lead you in the right direction.

Because it's the first port that caught my eye, let's go with NFS. NFS can be trivial to get into if misconfigured. Fingers crossed that's the case here. First thing to consider is the ports that NFS operates on, TCP/111 and TCP/2049. We see both ports in our scan, so lets run another but let's focus just on those ports and perhaps throw an NSE script just to cover all the bases. Perhaps we've got a mountable share we can poke about in.



Having a look at this scan's output we can see we've got a mountable share, /TechSupport. Let's see if we can get in there and learn something.



Now that we've got the share mounted and we've listed the contents we can see a fair few files prefaced with ticket. So it looks like we've managed to find a ITMS repository for the company's support services desk. Sadly though, looking at the file size for most of these, we've got a null value which we know = no data. All but one.

Let's see if we can have a look at what's inside.



Very nice! It looks like we've got a conversation between a chap called Alex and an operator. There looks to be some kind of issue with a web config file that Alex needs some assistance with. And being the good sysadmin that he clearly is, Alex has shared with the operator all the details we need (yes, username and password included) to move around a bit more freely and poke about on at least one other system.



What I typically like to do in a situation like this is create a l00t folder where I can keep information like this so it's easy for me to reference the information. You never know when, where and how you may able to use information like this so best to always keep it in your back pocket, so to speak.

I think we've probably done all we can with NFS at this point. We've got some creds, where might we be able to use those? If we recall in our initial scan, we could see that port 3389 was open. And knowing that port 3389 means RDP we can try to get remote access to the server.

Let's fire up Remmina (or the RDP application of your choice) and see if we can leverage those creds that Alex was nice enough to share.



We're in!



So we can see straight away that this server is likely to have some good stuff on it thanks to this server running SQL. We'll get the obvious checks out of the way first and see if this instance of Microsoft SQL Server Management Studio is atrociously misconfigured.

We know we have a password in our "back pocket". Let's give that a try and see if they're going the lazy route and reusing passwords.





We got a connection, but there doesn't seem to be a process on the other end of the pipe. My first thought here is that the sa account isn't enabled but you just never know. Let's put it a pin in this one. We may have another opportunity at it later. They look to have passed basic misconfig 101. Let's see if we can get in with Windows Authentication. Perhaps Alex's isn't just a sysadmin, but also a DBA and doesn't believe in standard/admin account separation.





Okay, we're clearly not getting in this way. We're going to have to explore the file system a bit.

I typically like to first check to see who's present on the system. 



So we've got Alex, Administrator and Public. Obviously we're not going to have to do any heavy lifting to view Alex's directory. Let's see what he has on this server, if anything.



Fairly stock directory listing for a user's directory. We can see that TechSupport share we were able to mount earlier. But we also see another interesting directory in this otherwise stock listing; devshare. Let's see what's in there.



This looks important.



And there it is! The all important sa password. Getting into MS SQL Server Management Studio should be easy now. Let's note these creds in our l00t file and head back to SQL.





Another "No process" error. Definitely a good bet that this account isn't enabled. So we've got an sa account password for a plausibly disabled account. What now? Well...password reuse is still on the table and we've to an Administrator account we haven't played with yet. Let's see if this password lets us run Management Studio as Admin.



That worked! Let's see if we can go a step further and authenticate to the database.



That also worked! We've got access to not just the company's database server, but to the database itself. The sky is the limit at this point. More importantly, we know we're likely very close to getting our flag. Recall that we're looking for a password for a user called "HTB".

For this bit, we'll have to dust off our Transact-SQL and run a query or two to see if we can discover that username on this particular database or if we'll have to keep exploring.

The nice thing about SQL Server Management Studio's New Query window is it's autocomplete functionality. Let's take good advantage of that here.

We'll start with a basic query to see what we can look at.



That accounts table catalogue looks just about perfect for what we're going after.



It looks like we're on the right track. Let's build out a query a bit and see where we can get to.

From here on out, you'll have to build out the queries yourself. I had to dust of my T-SQL. You'll have to feel that pain as well.



Looks like we're very close now. Just a bit more enumeration and we may have what we're looking for.



And we've arrived. We've enumerated this database and have at our fingertips a collection of names and passwords. One more query should do the trick.



We've got it! Now, submit your flag, collect your cubes and go have some tea. Job well done!

Until next time!