Hands-On-KB

Next up in the HTB Academy curriculum is the Footprinting module, which is rated “Medium.” Here we focus on enumerating several common host and network protocols that you’ll find in many enterprise engagements (ie. FTP, SMB, NFS, DNS, SMTP, IMAP/POP3, SNMP, MySQL, etc.).

Footprinting methodology is discussed early on in the Enumeration Principles and Enumeration Methodology sections and we’re provided with this beautiful and not at all intimidating diagram.

Footprinting Lab – Easy

Get used to seeing the name Inlanefreight Ltd. because that’s the fictional company used throughout the HTB Academy CPTS curriculum to simulate various aspects of a penetration testing engagement. Here they’ve commissioned us to test three servers in their internal network (your Easy, Medium, and Hard footprinting labs). First off we start with their internal DNS server, and show them how much information, especially anything that can be used against them, can be gleaned from this endpoint.

Also, our “teammates” apparently found the credentials “ceil:qwer1234” (username:password) and mentioned that some employees of the company were discussing SSH keys on a forum (really?). We must use this information and the techniques learned in this section to find a flag.txt file stored on the server by the admins.

So being the highly skilled and technical infosec professional I am (clearly being sarcastic here), the first thing I do is run an aggressive scan against the DNS server by throwing every Nmap Scripting Engine (NSE) DNS script at it with the command nmap -p- -A 10.129.42.195 –script dns*

Besides making me seem barely better than a chimp smashing a keyboard, this scan actually gives me two useful pieces of information: the FQDN for a ProFTPD Server within their internal network (ftp.int.inlanefreight.htb) running on TCP port 21, and the fact that another ProFTPD Server running on TCP port 2121 is named “Ceil’s FTP” (I wonder what we could use to get into there…)

Using the command wget -m –no-passive ftp://ceil:qwer1234@[Target IP]:2121 we’re able to download any available files from the main directory of Ceil’s ProFTPD server, which provides us with an index.html page with the following files revealed. (Look up the function of the -m or –mirror and –no-passive options for wget here).

That .bash_history file looks interesting. Let’s see what Ceil was up to in his/her terminal.

Well if I’m seeing this right it looks like Ceil made a directory named ssh, overwrote their OpenSSH private key with the text “test” to see if they had write permissions on the file, checked their user and group IDs and associated privileges, generated a new 4096 bit RSA key, removed the SSH directory with rm -rf (to delete root owned files and/or directories recursively), appended the contents of their public key to a file named authorized_keys, made a directory named flag, created the flag.txt file, and put it in that directory.

First thing we can do to really ruin Ceil’s day is download their RSA private key with the command:

wget ftp://ceil:qwer1234@[Target IP]/.ssh/id_rsa.

Then we use that private key to log into the server via SSH with the command: sudo ssh ceil@[Target IP] -i id_rsa

The last thing we have to do after logging into the server successfully is cd back into the home directory, enter the flag directory Ceil made, and output the contents of the flag.txt file to the terminal with cat flag.txt

Answer: HTB{7nrzise7hednrxihskjed7nzrgkweunj47zngrhdbkjhgdfbjkc7hgj}

Footprinting Lab – Medium

Now we move on to the next scenario, and I remember this one being kind of annoying since I’m not that familiar with MSSQL Server Management Studio. Again we need to find out as much information about the server as possible and discover ways to exploit it. There’s a user named HTB already created on the machine and we need to find their credentials.

Based on the mention of a server “everyone on the internal network has access to” this seems like it’ll have an SMB component to it. We start off with an nmap scan (sudo nmap -sC -sV -A <Target IP>) that shows us several services running on the server.

The “microsoft-ds?” service running on port 45 is just SMB. There’s also an NFS share on port 2049 named mountd. Let’s start with that. Make a new directory you can mount the NFS share to (I named mine ft-mount) and use the command sudo mount -t nfs <Target IP>:/ ./ft-mount/ -o nolock to mount the share.

If you go into the directory you’ll find a subdirectory named TechSupport. Checking the permissions for the folder will show you that you don’t have the ability to read it, but if you back out into your user directory (for me it was htb-ac-3686) you can use ls ft-mount/TechSupport to list the contents of the directory.

In that deluge of support tickets, which all strangely have 0 bytes, there’s one that actually has something in it. Open it up and see what we’ve got.

Well look at that! We’ve got credentials! Alex was sloppy enough to leave his username and password within his IT support ticket, and probably wasn’t aware of how easy it would be for a malicious cyber actor to access it. Let’s use these creds to access the SMB share on the target machine, first enumerating it with enum4linux-ng.py (make sure you use a ‘\‘ to escape out that exclamation point in Alex’s password).

Wow! We were able to learn a lot from that. The domain name (INFREIGHT), the exact version, release, and build of Windows 10 running on the target machine, and the accessible shares in the image above. Of those five, only IPC$, Users, and devshare are accessible. Let’s now use smbclient to connect to the share.

On the share you’ll find a text file named important.txt, but if you try to access it from your terminal you won’t find anything inside and may even encounter a bug where the file is cleared and you have to restart your Target VM (as I had to). So our next option is to use Alex’s creds to access the target machine via RDP (either Remmina or XFreeRDP, whichever you prefer).

Now we’re on the target with a nice GUI to click through. And if you go rummaging around in the file explorer and navigate to the Local (C:)\Users\alex folder you’ll find our friend devshare and the mysterious text file with the suspicious name.

These people have a real problem with leaving login credentials lying around. This is the login of the system administrator (sa) whose password is 87N1ns@slls83. Now if you’ve noticed our desktop on the Windows machine we RDP’ed into, you’ll see a shortcut for MSSQL Server Management Studio, which may have the HTB account info we’re looking for.

Go ahead and either right-click on that icon and click “Run as Administrator” or close out your RDP connection and log back in with your administrator credentials (using Remmina or XFreeRDP with the username Administrator and the password visible above).

From there you’ll have to put together a Transact-SQL query to find information about the HTB account. Digging through the folders on the database server shows us a table within accounts named dbo.devsacc. So we put together the simple query of SELECT * FROM accounts.dbo.devsacc where name = ‘htb’; and voila. Lab complete.

Answer: lnch7ehrdn43i7AoqVPK4zWR

Footprinting Lab Hard

So first off I start with two nmap scans: one for UDP and one for TCP.

These scans let us know that SSH, SNMP, POP3/S, and IMAP/S are all running on this target machine. We also get to see what capabilities the POP3 and IMAP servers have. But where do we go from here?

Using onesixtyone to find SNMP community strings with a wordlist with the command onesixtyone -c /opt/useful/SecLists/Discovery/SNMP/snmp-onesixtyone.txt <Target IP> shows us the community string backup. We can then use braa with the command braa backup@<Target IP> to find login credentials for a user named “tom.”

We then use curl -k ‘imaps://<Target IP>’ -user tom:NMds732Js2761 to access the e-mail inboxes on the server. The only one that matters is literally named “INBOX” and we can read the single e-mail sitting in there with the IMAP command 1 FETCH 1 RFC822.TEXT (which was a pain to figure out, let me tell you).

That e-mail, for some reason, contains Tom’s entire RSA private key which we can then copy into a text file named id_rsa, provide it with the necessary permissions with chmod 600 id_rsa, and log into the server via SSH with Tom’s username and private key.

We then use ls -al to figure out what files Tom has in his directory, including his history of most recently used bash commands (.bash_history).

Tom recently accessed MySQL on this server using the command mysql -u tom -p. If we do the same thing and then use Tom’s password that we found via braa (NMds732Js2761) we’re able to access the MySQL database on the server.

Traversing the SQL database, we can find our answer by first showing all databases (show databases;), selecting the users database (use users), and finally searching the users database for the user named HTB (select * from users where username = ‘HTB’;) we easily find our answer.

Answer: cr3n4o7rzse7rzhnckhssncif7ds

So there you have it. All three labs for the Footprinting module.

Overall these were definitely not easy. The Medium lab especially was a huge pain to get through at certain points. Don’t get discouraged if you need to check the forums for an idea of how to progress or use the hint for the lab. No point in wasting hours or days stumbling around in the dark looking for an answer.