Mr Robot VulnHub

Introduction

In this write-up, I'll document how I completed the Mr. Robot: 1 vulnerable machine from VulnHub.

The challenge is inspired by the Mr. Robot TV series and contains three hidden keys. The objective is simple: gain access to the machine, find all three keys, and ultimately obtain root privileges.

This machine is considered beginner to intermediate and focuses primarily on:

• Network reconnaissance
• Web enumeration
• WordPress enumeration
• Credential discovery
• Reverse shells
• Linux shell interaction
• Password hash analysis
• SUID privilege escalation

About VulnHub

VulnHub is a community-driven platform that provides intentionally vulnerable virtual machines for cybersecurity training.

These machines allow security students and professionals to practice offensive and defensive security techniques in controlled environments. Instead of testing techniques against real systems, vulnerable machines can be downloaded and deployed locally in an isolated lab.

About Mr. Robot: 1

Mr. Robot: 1 is an intentionally vulnerable virtual machine inspired by the television series Mr. Robot.

The machine contains three hidden keys:

• Key 1
• Key 2
• Key 3

Each key becomes progressively more difficult to obtain.

The machine does not require advanced reverse engineering or highly complex exploitation techniques, making it a useful challenge for people moving from cybersecurity theory into practical penetration testing.

About This Write-Up

This walkthrough documents the path I used to complete the machine.

It focuses primarily on the successful attack path rather than every failed attempt or possible alternative solution. As with most vulnerable machines, there may be several different ways to reach the final objective.

If you are currently attempting this machine yourself, I recommend trying to solve each stage before reading the corresponding section.

Getting stuck is part of the learning process. Use walkthroughs as a reference when necessary rather than simply copying every command.

Disclaimer

This walkthrough is intended strictly for educational purposes and documents techniques used against an intentionally vulnerable machine inside an isolated lab environment.

Do not use these techniques against systems, networks, or applications without explicit authorization. Unauthorized access to computer systems may be illegal.

Always practice cybersecurity techniques in environments you own or have permission to test.

Lab Setup

For this challenge, I used two virtual machines:

Attacker Machine

• Kali Linux
• 4 GB RAM
• 3 virtual CPUs
• 25 GB virtual disk

Target Machine

• Mr. Robot: 1
• 1 virtual CPU
• 512 MB RAM

Both machines were connected to an isolated host-only network with DHCP enabled.

The purpose of using an isolated network was to keep the vulnerable machine separated from external systems and reduce unnecessary network traffic.

From this point forward, I will refer to the Mr. Robot: 1 VM as the target.

Ground Rules

To make the challenge more realistic, I avoided directly interacting with the target through its virtual machine console.

All reconnaissance, enumeration, exploitation, and post-exploitation activities were performed remotely from the Kali Linux attacker machine.

Reconnaissance

Discovering the Target

The first objective was to identify the target machine on the local network.

My Kali Linux machine had the following IP address:

192.168.115.5

I scanned the local subnet to discover active hosts and identify the target.

The scan revealed several devices, including:

• The host machine
• The VirtualBox DHCP server
• The Kali Linux attacker machine
• An unknown machine at 192.168.115.4

Based on the network configuration, I identified:

192.168.115.4

as the target.

Further scanning showed the following ports:

• Port 80 — HTTP
• Port 443 — HTTPS
• Port 22 — SSH, but closed

Since the target exposed HTTP and HTTPS services, the next logical step was to investigate the web application.

[Screenshot: Nmap discovery and port scan]

Web Enumeration

Opening the target IP address in a browser revealed a website inspired by the Mr. Robot television series.

The website contained an interactive terminal-style interface with several available commands. Executing the commands displayed different animations and images before returning to the terminal interface.

I manually explored the application and inspected the page source and JavaScript files.

However, this did not immediately reveal anything useful.

At this point, I moved from manual exploration to web directory enumeration.

[Screenshot: Mr. Robot website]

Directory Enumeration

I performed directory enumeration against the web server to discover hidden files and directories.

The results revealed several interesting endpoints and, importantly, indicated that the target was running WordPress.

This significantly expanded the attack surface.

Among the discovered resources were:

• A WordPress login page
• A robots.txt file
• Additional hidden files and directories

The robots.txt file turned out to be particularly important.

It referenced files that led to the first key and a custom wordlist.

Finding Key 1

One of the discovered files was:

key-1-of-3.txt

Opening the file revealed the first key.

Key 1 obtained.

The second interesting file was:

fsocity.dic

Opening this endpoint downloaded a large wordlist containing hundreds of thousands of entries.

I saved the wordlist because it appeared likely to be useful later in the challenge.

[Screenshot: First key and fsocity.dic discovery]

WordPress Enumeration

The next major objective was gaining access to the WordPress administration panel.

A WordPress login requires two pieces of information:

• A valid username
• The corresponding password

At this stage, I had neither.

However, the login page behaved differently depending on whether the submitted username was valid.

This difference in responses created a username enumeration opportunity.

Using the discovered fsocity.dic wordlist, I tested possible usernames against the WordPress login page.

Eventually, a valid username was identified.

After confirming the username, the next step was determining its password.

Password Discovery

With a valid username available, I used the custom fsocity.dic wordlist to test possible passwords against the WordPress login.

The wordlist contained many duplicate entries, so optimizing or cleaning the list can reduce unnecessary attempts.

Eventually, a valid username and password combination was discovered.

Using these credentials, I successfully logged into the WordPress administration dashboard.

[Screenshot: Successful WordPress login]

The compromised account had administrator privileges, which meant it could modify parts of the WordPress application.

This provided a potential path from web application access to operating-system-level access.

Gaining a Reverse Shell

A reverse shell causes the target machine to initiate a connection back to the attacker.

Because I had administrative access to WordPress, I could modify executable server-side code.

I configured my Kali machine to listen for an incoming connection and modified an appropriate WordPress PHP file in the lab environment to trigger a reverse shell.

After the modified page was requested, the target connected back to my listener.

I now had shell access to the target.

However, the shell was running as a low-privileged service account.

[Screenshot: Initial reverse shell]

Enumerating the Target

With shell access established, I began exploring the filesystem.

Inside the /home directory, I discovered a directory belonging to the user:

robot

Inside that directory were two interesting files:

• The second key
• A file containing an MD5 password hash

The second key could not initially be read because my current account did not have sufficient permissions.

The password hash, however, was readable.

After recovering the corresponding password in the lab environment, I had credentials for the robot user.

Upgrading the Shell

The initial reverse shell had limited functionality.

To properly switch users and interact with the system, I upgraded the shell to a more functional TTY session.

After upgrading the shell, I switched to the robot account using the recovered credentials.

I could now access the user's home directory with the correct permissions.

This allowed me to read:

key-2-of-3.txt

Key 2 obtained.

[Screenshot: Shell upgrade and second key]

Privilege Escalation

At this point, I had access as the robot user, but I still needed to obtain root privileges to find the final key.

I began local enumeration and searched for executables with the SUID permission bit enabled.

SUID executables are important during Linux privilege-escalation enumeration because certain misconfigured programs may execute with the permissions of their owner.

During the search, one particularly interesting executable appeared:

nmap

The installed version of Nmap supported an older interactive mode.

Because the binary had elevated SUID permissions, this configuration could be abused inside the vulnerable lab to execute a shell with elevated privileges.

After using the interactive functionality to launch a shell, I checked my effective privileges.

I had obtained:

root

[Screenshot: Root shell]

Finding Key 3

With root access, the final step was locating the third key.

I searched the filesystem for the final key file and found it inside the root user's directory.

Reading the file revealed:

key-3-of-3.txt

Key 3 obtained.

The machine was successfully completed.

Attack Path Summary

The overall path through the machine was:

Network Discovery

↓

Port Scanning

↓

Web Enumeration

↓

Directory and File Discovery

↓

First Key

↓

WordPress Enumeration

↓

Credential Discovery

↓

WordPress Administrator Access

↓

Reverse Shell

↓

Local Enumeration

↓

Robot User Access

↓

Second Key

↓

SUID Enumeration

↓

Privilege Escalation

↓

Root Access

↓

Third Key

What I Learned

The Mr. Robot: 1 machine was a useful exercise because it connected several individual cybersecurity concepts into one complete attack chain.

The most important lessons for me were:

Enumeration is critical

The attack path depended heavily on discovering information that was not immediately visible.

The robots.txt file, hidden files, WordPress installation, credentials, and SUID binary were all discovered through enumeration.

Small information leaks can become serious

A difference in login error messages may appear insignificant, but it can reveal whether a username exists.

That information can make further credential attacks much easier.

Administrator access can have a much larger impact

Compromising a WordPress administrator account was not limited to modifying website content. The ability to modify executable server-side code created a path toward operating-system access.

Initial access is only the beginning

The first shell had very limited privileges.

Further enumeration was required to move from the web service account to the robot user and finally to root.

Misconfigured permissions can lead to complete compromise

The SUID configuration on an older Nmap binary created the final privilege-escalation path.

This demonstrated why unnecessary SUID permissions and outdated software can be dangerous.

Conclusion

Completing Mr. Robot: 1 gave me practical experience with a full penetration-testing workflow:

Reconnaissance → Enumeration → Initial Access → Post-Exploitation → Privilege Escalation

Rather than focusing on a single vulnerability, the machine required multiple findings to be connected Mr. Robot: 1 — VulnHub Walkthrough

Introduction

In this write-up, I'll document how I completed the Mr. Robot: 1 vulnerable machine from VulnHub.

The challenge is inspired by the Mr. Robot TV series and contains three hidden keys. The objective is simple: gain access to the machine, find all three keys, and ultimately obtain root privileges.

This machine is considered beginner to intermediate and focuses primarily on:

• Network reconnaissance
• Web enumeration
• WordPress enumeration
• Credential discovery
• Reverse shells
• Linux shell interaction
• Password hash analysis
• SUID privilege escalation

About VulnHub

VulnHub is a community-driven platform that provides intentionally vulnerable virtual machines for cybersecurity training.

These machines allow security students and professionals to practice offensive and defensive security techniques in controlled environments. Instead of testing techniques against real systems, vulnerable machines can be downloaded and deployed locally in an isolated lab.

About Mr. Robot: 1

Mr. Robot: 1 is an intentionally vulnerable virtual machine inspired by the television series Mr. Robot.

The machine contains three hidden keys:

• Key 1
• Key 2
• Key 3

Each key becomes progressively more difficult to obtain.

The machine does not require advanced reverse engineering or highly complex exploitation techniques, making it a useful challenge for people moving from cybersecurity theory into practical penetration testing.

About This Write-Up

This walkthrough documents the path I used to complete the machine.

It focuses primarily on the successful attack path rather than every failed attempt or possible alternative solution. As with most vulnerable machines, there may be several different ways to reach the final objective.

If you are currently attempting this machine yourself, I recommend trying to solve each stage before reading the corresponding section.

Getting stuck is part of the learning process. Use walkthroughs as a reference when necessary rather than simply copying every command.

Disclaimer

This walkthrough is intended strictly for educational purposes and documents techniques used against an intentionally vulnerable machine inside an isolated lab environment.

Do not use these techniques against systems, networks, or applications without explicit authorization. Unauthorized access to computer systems may be illegal.

Always practice cybersecurity techniques in environments you own or have permission to test.

Lab Setup

For this challenge, I used two virtual machines:

Attacker Machine

• Kali Linux
• 4 GB RAM
• 3 virtual CPUs
• 25 GB virtual disk

Target Machine

• Mr. Robot: 1
• 1 virtual CPU
• 512 MB RAM

Both machines were connected to an isolated host-only network with DHCP enabled.

The purpose of using an isolated network was to keep the vulnerable machine separated from external systems and reduce unnecessary network traffic.

From this point forward, I will refer to the Mr. Robot: 1 VM as the target.

Ground Rules

To make the challenge more realistic, I avoided directly interacting with the target through its virtual machine console.

All reconnaissance, enumeration, exploitation, and post-exploitation activities were performed remotely from the Kali Linux attacker machine.

Reconnaissance

Discovering the Target

The first objective was to identify the target machine on the local network.

My Kali Linux machine had the following IP address:

192.168.115.5

I scanned the local subnet to discover active hosts and identify the target.

The scan revealed several devices, including:

• The host machine
• The VirtualBox DHCP server
• The Kali Linux attacker machine
• An unknown machine at 192.168.115.4

Based on the network configuration, I identified:

192.168.115.4

as the target.

Further scanning showed the following ports:

• Port 80 — HTTP
• Port 443 — HTTPS
• Port 22 — SSH, but closed

Since the target exposed HTTP and HTTPS services, the next logical step was to investigate the web application.

[Screenshot: Nmap discovery and port scan]

Web Enumeration

Opening the target IP address in a browser revealed a website inspired by the Mr. Robot television series.

The website contained an interactive terminal-style interface with several available commands. Executing the commands displayed different animations and images before returning to the terminal interface.

I manually explored the application and inspected the page source and JavaScript files.

However, this did not immediately reveal anything useful.

At this point, I moved from manual exploration to web directory enumeration.

[Screenshot: Mr. Robot website]

Directory Enumeration

I performed directory enumeration against the web server to discover hidden files and directories.

The results revealed several interesting endpoints and, importantly, indicated that the target was running WordPress.

This significantly expanded the attack surface.

Among the discovered resources were:

• A WordPress login page
• A robots.txt file
• Additional hidden files and directories

The robots.txt file turned out to be particularly important.

It referenced files that led to the first key and a custom wordlist.

Finding Key 1

One of the discovered files was:

key-1-of-3.txt

Opening the file revealed the first key.

Key 1 obtained.

The second interesting file was:

fsocity.dic

Opening this endpoint downloaded a large wordlist containing hundreds of thousands of entries.

I saved the wordlist because it appeared likely to be useful later in the challenge.

[Screenshot: First key and fsocity.dic discovery]

WordPress Enumeration

The next major objective was gaining access to the WordPress administration panel.

A WordPress login requires two pieces of information:

• A valid username
• The corresponding password

At this stage, I had neither.

However, the login page behaved differently depending on whether the submitted username was valid.

This difference in responses created a username enumeration opportunity.

Using the discovered fsocity.dic wordlist, I tested possible usernames against the WordPress login page.

Eventually, a valid username was identified.

After confirming the username, the next step was determining its password.

Password Discovery

With a valid username available, I used the custom fsocity.dic wordlist to test possible passwords against the WordPress login.

The wordlist contained many duplicate entries, so optimizing or cleaning the list can reduce unnecessary attempts.

Eventually, a valid username and password combination was discovered.

Using these credentials, I successfully logged into the WordPress administration dashboard.

[Screenshot: Successful WordPress login]

The compromised account had administrator privileges, which meant it could modify parts of the WordPress application.

This provided a potential path from web application access to operating-system-level access.

Gaining a Reverse Shell

A reverse shell causes the target machine to initiate a connection back to the attacker.

Because I had administrative access to WordPress, I could modify executable server-side code.

I configured my Kali machine to listen for an incoming connection and modified an appropriate WordPress PHP file in the lab environment to trigger a reverse shell.

After the modified page was requested, the target connected back to my listener.

I now had shell access to the target.

However, the shell was running as a low-privileged service account.

[Screenshot: Initial reverse shell]

Enumerating the Target

With shell access established, I began exploring the filesystem.

Inside the /home directory, I discovered a directory belonging to the user:

robot

Inside that directory were two interesting files:

• The second key
• A file containing an MD5 password hash

The second key could not initially be read because my current account did not have sufficient permissions.

The password hash, however, was readable.

After recovering the corresponding password in the lab environment, I had credentials for the robot user.

Upgrading the Shell

The initial reverse shell had limited functionality.

To properly switch users and interact with the system, I upgraded the shell to a more functional TTY session.

After upgrading the shell, I switched to the robot account using the recovered credentials.

I could now access the user's home directory with the correct permissions.

This allowed me to read:

key-2-of-3.txt

Key 2 obtained.

[Screenshot: Shell upgrade and second key]

Privilege Escalation

At this point, I had access as the robot user, but I still needed to obtain root privileges to find the final key.

I began local enumeration and searched for executables with the SUID permission bit enabled.

SUID executables are important during Linux privilege-escalation enumeration because certain misconfigured programs may execute with the permissions of their owner.

During the search, one particularly interesting executable appeared:

nmap

The installed version of Nmap supported an older interactive mode.

Because the binary had elevated SUID permissions, this configuration could be abused inside the vulnerable lab to execute a shell with elevated privileges.

After using the interactive functionality to launch a shell, I checked my effective privileges.

I had obtained:

root

[Screenshot: Root shell]

Finding Key 3

With root access, the final step was locating the third key.

I searched the filesystem for the final key file and found it inside the root user's directory.

Reading the file revealed:

key-3-of-3.txt

Key 3 obtained.

The machine was successfully completed.

Attack Path Summary

The overall path through the machine was:

Network Discovery

↓

Port Scanning

↓

Web Enumeration

↓

Directory and File Discovery

↓

First Key

↓

WordPress Enumeration

↓

Credential Discovery

↓

WordPress Administrator Access

↓

Reverse Shell

↓

Local Enumeration

↓

Robot User Access

↓

Second Key

↓

SUID Enumeration

↓

Privilege Escalation

↓

Root Access

↓

Third Key

What I Learned

The Mr. Robot: 1 machine was a useful exercise because it connected several individual cybersecurity concepts into one complete attack chain.

The most important lessons for me were:

Enumeration is critical

The attack path depended heavily on discovering information that was not immediately visible.

The robots.txt file, hidden files, WordPress installation, credentials, and SUID binary were all discovered through enumeration.

Small information leaks can become serious

A difference in login error messages may appear insignificant, but it can reveal whether a username exists.

That information can make further credential attacks much easier.

Administrator access can have a much larger impact

Compromising a WordPress administrator account was not limited to modifying website content. The ability to modify executable server-side code created a path toward operating-system access.

Initial access is only the beginning

The first shell had very limited privileges.

Further enumeration was required to move from the web service account to the robot user and finally to root.

Misconfigured permissions can lead to complete compromise

The SUID configuration on an older Nmap binary created the final privilege-escalation path.

This demonstrated why unnecessary SUID permissions and outdated software can be dangerous.

Conclusion

Completing Mr. Robot: 1 gave me practical experience with a full penetration-testing workflow:

Reconnaissance → Enumeration → Initial Access → Post-Exploitation → Privilege Escalation

Rather than focusing on a single vulnerability, the machine required multiple findings to be connected into a complete attack chain.

For anyone learning penetration testing, vulnerable machines like this are valuable because they turn theoretical concepts into practical experience inside a controlled and authorized environment.

Thanks for reading.

**All testing documented in this write-up was performed against an intentionally vulnerable virtual machine in an isolated lab environment.**into a complete attack chain.

For anyone learning penetration testing, vulnerable machines like this are valuable because they turn theoretical concepts into practical experience inside a controlled and authorized environment.

Thanks for reading.

All testing documented in this write-up was performed against an intentionally vulnerable virtual machine in an isolated lab environment.