Before diving into complex exploit chains, a solid Vulnerability Assessment and Penetration Testing (VAPT) methodology requires mastering service enumeration and identifying low-hanging fruit.

Hack The Box's Starting Point (Tier 0) provided a controlled environment to validate how default configurations and legacy protocols routinely expose internal infrastructure. Here is the technical breakdown of the access vectors I exploited, and the necessary remediation for each.

Mindset : Learning on the Fly

When I started these machines, I realized that there is never going to be a "perfect time" to begin. There will always be something I haven’t studied yet or a concept that feels completely new to me.

But that shouldn't be a dealbreaker to try and solve a problem. Instead of waiting until I knew everything, I decided to just jump in, try things out, and learn on the go.

Meow: Telnet

Difficulty: Very Easy

Machine Summary

Enumeration revealed that the service was not only exposed but permitted administrative access without credentials. Initial access was achieved by exploiting a misconfigured Telnet Service, connecting to the service immediately prompted for a username, which accepted the default root account with no password required, which gave access to the files and flag.txt on the Service.

1. Discovery

A network scan revealed 1 open port, with the primary attack surface being an exposed Telnet service on port 23/tcp.

# Enumeration
sudo nmap -sV 10.129.41.186

2. Exploitation (Foothold)

Because the service failed to enforce Authentication, I was able to Login as Root User on the Telnet Service without a Password.

# Exact command
telnet 10.129.41.186 23

The Telnet login already yielded a root shell, so no additional privilege‑escalation commands were required.

Now, Flag was present at the root directory itself.

3. Remediation

To secure this, system administrators must implement the following:

Fix 1: Disable Telnet completely.

Fix 2: Implement SSH (Port 22) for remote administration, enforce key-based authentication, and disable PermitRootLogin in the SSH configuration.

Fawn: FTP

Difficulty: Very Easy

Machine Summary

Enumeration revealed that Port 21 used for FTP (File Transfer Protocol) is open. Initial access was achieved by exploiting a misconfigured FTP, that allowed anonymous login, which directly exposed the flag.txt.

1. Discovery

A network scan revealed 1 open port, with the primary attack surface being an exposed FTP service on port 21/tcp.

# Enumeration
sudo nmap -sV 10.129.41.176

2. Exploitation (Foothold)

Because the service failed to enforce Login Authentication, I was able to Login to FTP service on the machine.

# Command
ftp 10.129.41.176

I authenticated using the username anonymous and a blank password, which granted access to the internal directory structure.

After logging into FTP, I was able to access the files on the machine, followed by downloading the flag.txt with get command to my local machine.

3. Remediation

To secure FTP Service, system administrators must implement the following:

Fix 1: Modify the FTP server configuration (e.g., vsftpd.conf) to set anonymous_enable=NO.

Fix 2: Transition to SFTP to ensure data is encrypted in transit.

Dancing: SMB

OS: Windows | Difficulty: Easy

Machine Summary

The critical flaw here was a failure to implement Role-Based Access Control (RBAC) in SMB (Server Message Block), allowing guest access to internal shares. Initial access was achieved by exploiting a misconfigured SMB using smbclient, by enumerating through internal Shares and getting access to a custom share Workshares that permitted unauthenticated connections, allowing me to navigate the directory and exfiltrate files.

1. Discovery

A network scan revealed 4 open ports, with the primary attack surface being an exposed SMB service on port 445.

# Enumeration
sudo nmap -sV 10.129.41.222

2. Exploitation (Foothold)

Using smbclient, I initiated a null session to list available shares. This revealed a custom share named WorkShares that permitted unauthenticated connections, because the service failed to enforce authentication, I was able to Access the Directories and Files on the Share.

# Command
smbclient -L //10.129.41.222

After getting the access to Files and Directories, I Enumerated through available files and got the flag.txt in one of the Directories. Lastly, Downloaded the file by get command to the Local Machine.

3. Remediation

To secure SMB service, system administrators must implement the following:

Fix 1: Disable anonymous and guest access in the SMB configuration.

Fix 2: Enforce strict permissions ensuring only authenticated users can mount internal shares.

Redeemer: Redis

Difficulty: Easy

Machine Summary

Enumeration revealed the port 6379 for the Redis Service to be open. Initial access was achieved by using redis-cli tool, and then got info about database and keys, followed by finding flag as a key:value pair. Lastly retrieved the flag using get.

1. Discovery

A network scan revealed 1 open port, with the primary attack surface being an exposed Redis Database service on port 6379.

# Enumeration
sudo nmap -p- -sV 10.129.78.26

2. Exploitation (Foothold)

Because the service failed to enforce Password Authentication, I was able to connect using command line tool redis-cli without needing to know a password.

# Command
redis-cli -h 10.129.78.26

Once connected, database enumeration via the INFO command gave information regarding the redis version and others, but an important information was in Keyspace section, it told that there is only 1 database with 4 keys db0:keys=4. (As shown in the above screenshot, some of the content that was not significant for our concern was snipped out)

After knowing there is only 1 database with id db0, I used select command to query on that database and then enumerated the keys with command keys *.

Key Enumeration revealed flag key, then I retrieved the value stored in the flag key using the get command.

3. Remediation

To secure this infrastructure, system administrators must implement the following:

Fix 1: Bind Redis to localhost (127.0.0.1) in redis.conf instead of all interfaces (0.0.0.0).

Fix 2: Configure the requirepass directive to enforce a strong authentication password.

Final Takeaways & Reflections

What Surprised Me the Most

Before starting these machines, I assumed I would have to think deeply to figure out usernames or break past tough barriers. What surprised me most was how predictable everything actually was. Gaining access didn't require complicated exploits—it came down to basic defaults: logging in as root with no password, using anonymous, or hitting an open database with zero authentication.

From a defensive perspective, the lesson is clear:

• Never rely on default configurations: Always enforce strong passwords and proper authorization, even on internal services.

• Secure according to the service: Critical data stores like Redis should never face the public internet—they should be restricted and bound to localhost.

Looking at Solutions & Adjusting My Approach

Working through this also brought me face-to-face with tools I had never used before, like redis-cli. Instead of backing off, I jumped in with curiosity to see how it worked.

At some points, I won’t deny that I needed to look at the solution. But when I did, it wasn't just to get the flag—it showed me what I was thinking versus what the right approach actually was, and how to adjust my thought process next time.

Documenting this first experience of trying something new has been a great learning curve in itself. It proved to me that you don't need to know everything before you start—you just need to be willing to learn as you go.