Trick
https://app.hackthebox.com/machines/477
Last updated
Was this helpful?
https://app.hackthebox.com/machines/477
Last updated
Was this helpful?
Starting out on DNS we add 10.10.11.166 to our attacking systems secondary DNS servers. Performing a zone transfer with dig reveals the sub-domains root.trick.htb and preprod-payroll.trick.htb.
Note: Add these into /etc/hosts.
Note: add to /etc/hosts.
Performing directory enumeration with dirseach reveals the /user.php page.
Viewing the page we find the username Enemigosss. We find the page buttons are not actionable.
Viewing the page source reveals come code that indicates parameters that we can use.
Testing the page parameter we are taken to a new page however, unable to action in any meaningful way further.
the id=n parameter could possibly be susceptible to SQL injection so we fire up sqlmap and command in the URL with the parameters.
Running through with the --batch and --tables parameters we are shown the users table on the payroll_db database.
We can then dump the contents of the users table.
which reveals the following credentias credentials: Enemigosss:SuperGucciRainbowCake
We find that none of the pages provide any interesting information so we use wfuzz to fuzz for further pages.
Looking again at the subdomain preprod-payroll we can fuzz the subdomain for other potentials domains where the word "payroll" is fuzzed which identifies "marketing".
Adding preprod-marketing.trick.htb to our hosts file we then browse to the domain and find an additional host.
Going through the available pages we find the parameter /index.php?page=services.html can likely be fuzzed for further pages or maybe even LFI.
Checking for LFI:
We get various hits for the bypassing to read /etc/passwd.
Seeing that the user michael exists on the target system we fuzz for well known files and get a hit for the id_rsa ssh key.
Copying the contents into id_rsa and using chmod to set the appropriate permissions. We are then able to SSH into the target system.
Grabbing the user.txt flag.
Checking sudo permissions with sudo -l. We see we have the ability to restart the fail2ban service as root without specifying the root password.
Some research into privilege escalation with fail2ban. Having the ability to edit the iptables-multiport.conf file presents opportunity for privilege escalation.
The user michael has directory permissions over /etc/fail2ban/action.d which means we can replace files within the directory with our own files.
First off, copy the current contents of iptables-multiport.conf and make appropriate changes. Below we are setting the command to create a new root user with the password Password123.
The command will be executed under "actionstart" which executes the given command for when the service starts.
The following commands then need executing in quick succession as the directory resets often.
Copy the preconfigured iptables-multiport.conf we created earlier into the configuration file and save.
Wait a short while, check /etc/password and we should see our new user.
We can then use su to switch to our new root user. For some unknown reason during the process of changing user I was moved directly to the root user. No complaints...
Browsing to reveals the following login prompt.
Going back to the login page on we are able to proceed with the given credentials.
Finding the page we are presented with an opportunity for file upload. However, I was not able to get this working. Viewing the requests through a proxy shows our working user does not have permission for file upload.
