Hack The Box: Starting Point - Archetype

 Introduction

After taking some free courses I bought a subscription to the ethical hacking learning platform. I chose Hack the Box to practice hacking skills and I hope that I will not regret it. The number of available options could be overwhelming but luckily Hack the Box crew thought about creating the Starting Point lab. It consists of nine machines with a Very Easy breaking level and those boxes are dependent on each other. It means that the post-exploitation phase is important in this particular lab since we can find some useful information. Findings can be leveraged to break into the next machine in the chain. I have to admit that I'm not a security specialist but I'm a student who wants to be a red teamer. Thus, I describe my way of thinking from the start to the end of a penetration test in my writeups rather than the ideal solution. With this in mind, I invite you to follow my writeup of the Archetype machine.


Enumeration

To be able to test the machine for some vulnerabilities first we need to know what services are running on it and what can be accomplished with them. Let's map the network services of the machine using nmap. I'm going to use the -sC option for running default nmap scripts to gather more information, -sV to check what services are running, -p- to test all ports, and -oN would redirect the result to the specified file.


I've marked the most important opened ports. In the green rectangle, there are ports responsible for the SMB protocol. It looks like the machine uses Windows Share and we can check if it's possible to access those shares anonymously. Maybe we can gather some sensitive data this way. On the 1433 port, the MSSQL server is running. In order to log in to the server, we have to find the credentials somewhere or crack them using Hydra for instance. On the 5985 and 47001 ports, there are some web applications running, but we can't access them so they are out of my concern for the time being.

Firstly, I will try to list the Windows Shares using smbclient. I don't have any user credentials so I hope that the anonymous login is enabled on the machine. Obviously, such a configuration is considered a security hole. 


The share named backups looks promising. Maybe it can be accessed without typing any password.


As you can see we can not only access the share but also get the file from it. Let's see what the stolen file has inside.


The prod.dtfConfig file is a configuration file of the SSIS with the XML format. Luckily there are credentials to the MSSQL server in the stolen config file. The login to the server is ARCHETYPE\sql_svc and M3g4c0rp123 is the password. Let's check if those credentials are correct with the Metasploit framework and its auxiliary/scanner/mssql/mssql_login module.

Foothold



The module options are set as follows:


The USERNAME option isn't correctly set. Instead of writing ARCHETYPE\sql_svc  I'm going to write ARCHETYPE\\sql_svc because the backslash is probably a special character inside the Metasploit.


Now everything is set as it should be and we are good to go.


Unfortunately, the login failed. For some reason, the default login in the module is set to WORKSTATION\ and the rest is pasted right after the backslash. That's why we are not able to check if those credentials are correct using Metasploit. I've done some research on the internet and it looks like there is another way to login into the MSSQL server. I'm going to use the mssqlclient.py script from the excellent Impacket collection.


The login has failed but the output from the tool is pretty interesting. It says that I've tried to log in using the ARCHETYPE\Guest as the username. Again, most likely the backslash destroys the whole authentication process. I will try to log in using the slash - as simple as that.


As the authentication to the MSSQL server was successful we can use the IS_SRVROLEMEMBER macro to see if the compromised account is a member of the admin role.


Perfect! The ARCHETYPE\sql_svc user is the administrator of the server. It means that we are allowed to enable the xp_cmdshell configuration option. The sp_configure procedure is used for enabling or disabling configuration options on the MSSQL servers. But first, let's check if the xp_cmdshell is actually disabled. To verify this we need to see the configuration table and to see the table the Show Advanced Options should be enabled.


sp_configure will return the whole configuration table but we are interested only in the xp_cmdshell option.



In my case, the xp_cmdshell is already enabled but I write this writeup after getting the flag. Thus, I'm going to show you how this option can be activated.


The reconfigure command is used for saving the new state of the configuration option. Some options require the server reboot to change the state and the reconfigure command does this kind of job for us. You can now ask why we had to enable the xp_cmdshell? First of all, only the server's administrator is allowed to change the state of this option. Second, the xp_cmdshell option spawns the cmd console and we can talk to the console through the xp_cmdshell. At this moment we are able to run the PowerShell commands for instance. Therefore, I'm going to search for the reverse shell. I found something like this -> https://gist.github.com/egre55/c058744a4240af6515eb32b2d33fbed3. Obviously, you have to change the default IP and port to your own. As you probably know the reverse shell connects from the victim's machine to the attacking system. To accept the shell session I will use the 443 port because it's a standard HTTPS port and it isn't blocked by firewalls usually. In order to upload the shell from the attacking system, the HTTP server should be launched. The best way to do this is to use the python SimpleHTTPServer module. The whole setup for creating and accepting the shell session looks like this:


Now we can use the console on the compromised machine to download the shell from the attacking system.


The shell was successfully uploaded but has been blocked by antivirus software running on the compromised machine. That's weird because the machine is marked as Very Easy. In such a case the three options come to my mind. First, we can search for another reverse shell on the internet. Second, we can try to obfuscate the shell before uploading it to the server. Third, we can maybe disable antivirus and execute the shell without unnecessary obstacles. I found this reverse shell:


Luckily the above reverse shell works just fine and we are finally inside the compromised machine.


The user flag is on the Desktop of the sql_svc user.


Privilege Escalation

I have to admit that this part took me a great amount of time compared to the enumeration and foothold phases. I didn't know where to start. Therefore, I looked inside the HTB official writeup of this machine and the privilege escalation technique was pretty amazing for me because I've learned something new.

First of all, we need to think what resources are accessible on the machine from the sql_svc account and how we can leverage that to raise the privileges. As you know the compromised host uses Windows Shares. The anonymous login option isn't disabled but maybe the users of the machine still use their credentials to access those shares? And maybe the administrator used the console to jump into the resources? Obviously, we can check this possibility by reading the console's history file. The mentioned file path is C:\Users\sql_svc\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt.


There we have it! Now as we know the administrator's credentials we can use the psexec.py script from the lmpacket collection. This program executes any process on Windows devices remotely. In order to use the psexec we have to know credentials to a local Windows account. The default process that the script executes is cmd.exe and this is exactly what we want.


As you can see now we have SYSTEM privileges and we can now read the root flag.


The root flag is on the Administrator's desktop.

Sum-up


This was my first lab on the Hack the Box platform and I feel that I learned a lot. Hope that other labs are as good as this or even better. If you are still reading this I wanna thank you for your attention. Have a nice day and happy hacking!


Comments

Popular posts from this blog

Learning of malware analysis. Solving 9-1 lab from the "OllyDbg" chapter. ("Practical Malware Analysis" book)

PicoCTF 2018 - Reverse Engineering writeups