July 13, 2026
Breaking Born2Root: From Enumeration to Root Access
Every penetration test begins with a single objective: understand the target before attempting any exploitation. Without proper…
By Fatima
7 min read
Every penetration test begins with a single objective: understand the target before attempting any exploitation. Without proper reconnaissance and enumeration, even obvious vulnerabilities can remain hidden.
When I began the Born2Root virtual machine, I had no credentials and no prior knowledge of the system. The only way forward was through careful reconnaissance, systematic enumeration, and identifying small clues that could eventually lead to full system compromise.
In this walkthrough, I'll share how I progressed from initial reconnaissance to gaining root access by combining multiple findings throughout the assessment. Rather than simply listing commands, I'll explain the thought process behind each step and how every discovery contributed to the next stage of the attack.
Let's get started.
Before beginning the assessment, I opened the target machine in a web browser to see what was publicly accessible. The homepage appeared simple and didn't reveal any obvious vulnerabilities or login pages.
While exploring the website, I noticed three names displayed in the About Us section: Martin, Jimmy, and Hadi. At the time, they seemed like ordinary employee names, but in penetration testing, even small pieces of publicly available information can become useful later.
Since there wasn't an obvious attack path from the homepage, the next step was to identify the services running on the target and begin the reconnaissance phase
Reconnaissance
The first step was to identify the services exposed by the target machine. For this, I performed an Nmap scan.
nmap -sS -sV -O <Target-IP>nmap -sS -sV -O <Target-IP>
The scan revealed two important services:
- Port 22 — SSH
- Port 80 — Apache Web Server
I also searched for known vulnerabilities related to the detected service versions using SearchSploit, but no suitable public exploits were available.
Since there was no straightforward vulnerability to exploit, I shifted my focus to the web application. The next step was to enumerate hidden files and directories that might reveal additional information or provide a path to initial access.
Enumeration
With the running services identified, the next step was to take a closer look at the web application.
Even when a website appears simple, hidden files and directories can reveal valuable information that isn't accessible through normal browsing. To discover these resources, I performed directory enumeration using Gobuster.
gobuster dir -u http://<Target-IP> -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txtgobuster dir -u http://<Target-IP> -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt
The scan revealed several interesting resources, including:
- robots.txt
- /icons
- /files
At first glance, these directories didn't appear unusual, but they were worth investigating. Hidden files often contain sensitive information, development files, or configuration mistakes that can provide an entry point into the system.
Among the discovered resources, the /icons directory immediately stood out, so I decided to examine it more closely.
Discovering the First Clue
After exploring the discovered directories, I found something unexpected inside the /icons directory, a private SSH key.
Finding a private SSH key on a publicly accessible web server is a serious security misconfiguration. Instead of exploiting the web application, this discovery suggested that SSH might provide a faster path to gaining access.
I also remembered the three usernames Martin, Jimmy, and Hadi, that were listed on the homepage earlier. Those names now became much more important, as they were likely valid user accounts for the SSH service.
The next step was to see whether the exposed private key could be used to authenticate as one of these users.
Gaining Initial Access
I downloaded the private SSH key, adjusted its permissions, and attempted to log in using each of the discovered usernames.
Initially, every login attempt failed. After some investigation, I realized the target machine supported the older ssh-rsa authentication method, which modern SSH clients disable by default.
After enabling compatibility with the legacy algorithm, the connection was successful.
The first successful login was as Martin. Although this provided access to the system, the account had limited privileges, so the next objective was to enumerate the machine and search for a privilege escalation path.
Local Enumeration
After gaining access as Martin, the first step was to understand the environment and look for opportunities to move beyond this low-privileged account.
I explored the user's home directory, checked hidden files, and searched for sensitive information such as credentials or configuration files. Although these checks didn't reveal anything useful, they helped me better understand the system.
Since no obvious privilege escalation path was found, I shifted my focus to scheduled tasks, which are often overlooked but can sometimes lead to higher privileges.
Discovering a Misconfigured Cron Job
While inspecting the system, I found a cron job that attempted to execute a Python script named sekurity.py every five minutes as the user Jimmy.
At first, this looked like a normal scheduled task. However, after checking the expected location, I noticed something unusual — the sekurity.py file didn't exist.
This immediately raised an interesting question:
What if I created the missing file myself?
If the cron job executed whatever file existed at that location, I could potentially run my own code with Jimmy's privileges.
From Martin to Jimmy
To test whether the missing script could be abused, I created my own sekurity.py file and added a simple Python reverse shell payload.
Before saving the script, I started a Netcat listener on my Kali machine to wait for an incoming connection.
nc -lvnp 443nc -lvnp 443After saving the script in the expected location, I waited for the scheduled task to execute. Since the cron job was configured to run every five minutes, it automatically executed my malicious script.
A few moments later, the target machine connected back to my Netcat listener, providing an interactive shell.
The connection confirmed that the cron job had executed my script successfully, giving me shell access as Jimmy. This was a significant step forward because I had successfully moved from the Martin account to another user by exploiting a misconfigured scheduled task.
Although this provided greater access to the system, administrative privileges were still out of reach. The next objective was to continue enumerating the machine and identify a path to full root access.
Looking for the Final Piece
After gaining access as Jimmy, I performed another round of enumeration to look for a path toward root privileges. I searched for sensitive files, checked user permissions, and reviewed common privilege escalation opportunities, but nothing immediately stood out.
One user account, however, had not yet been explored Hadi.
Since I didn't have Hadi's password, I decided to try a different approach. Instead of using a large generic wordlist, I created a small custom wordlist based on common password patterns related to the username. This approach is often faster and more effective in CTF environments.
Discovering Hadi's Password
Using the custom wordlist, I performed a password attack against the SSH service with Hydra.
hydra -t 1 -vV -l hadi -P wordlists.txt <Target-IP> sshhydra -t 1 -vV -l hadi -P wordlists.txt <Target-IP> ssh
After a short time, Hydra successfully identified the correct password for the Hadi account.
With valid credentials now available, I logged in through SSH and continued the assessment with a new user account.
Gaining Root Access
After logging in as Hadi, I continued checking for privilege escalation opportunities. One of the first things I tested was whether Hadi's password could also be used to switch to the root account.
Using the su command, I entered the same password that Hydra had discovered.
The authentication was successful, and I was granted full administrative privileges on the system.
With root access established, I navigated to the /root directory to look for the final challenge flag.
cd /root
ls -a
cat flag.txtcd /root
ls -a
cat flag.txt
The output confirmed that I had successfully compromised the Born2Root virtual machine. The congratulatory message displayed by the system marked the completion of the challenge and confirmed that full administrative control had been achieved.
Reaching this point completed the entire attack chain from reconnaissance and enumeration to privilege escalation and root access.
Lessons Learned
This machine demonstrated how multiple small weaknesses can be combined to compromise an entire system. Some of the key lessons I learned include:
- Always perform thorough reconnaissance before attempting exploitation.
- Hidden files and directories may expose sensitive information.
- Publicly available usernames can become valuable during authentication attacks.
- Misconfigured scheduled tasks can lead to privilege escalation.
- Weak passwords remain a significant security risk.
- Careful enumeration is often more effective than relying solely on public exploits.
Conclusion
The Born2Root virtual machine was an excellent hands-on exercise that reinforced the importance of methodology in penetration testing. Although no single vulnerability immediately led to root access, each phase of the assessment uncovered a small piece of the puzzle.
Starting with reconnaissance, I discovered hidden resources that exposed an SSH private key, gained initial access as a low-privileged user, exploited a misconfigured cron job to move laterally, recovered another user's credentials through targeted password testing, and finally obtained full administrative access.
This machine serves as a great reminder that successful penetration testing is rarely about finding one critical vulnerability. Instead, it is about observing carefully, thinking logically, and connecting multiple findings into a complete attack path.
Thanks for reading! If you enjoyed this walkthrough, feel free to follow me on Medium. I'll continue sharing penetration testing labs, cybersecurity research, and practical ethical hacking walkthroughs in future articles.