Forgotten Portal
A pentesting exercise in a controlled lab, done during the Nodo EAFIT cybersecurity accelerator: seven documented findings, one technical report, and one executive report.
By Valentina Ramírez
Published: June 16, 2026 · Updated: October 2, 2026
Quote a project like this
- Problem
- Understanding how far someone without credentials can get against a misconfigured server, and explaining that risk to whoever decides the budget.
- Solution
- A pentesting exercise in a controlled lab, with every finding documented and two reports, one technical and one executive.
- Result
- Seven documented findings in two reports, one technical and one executive.
- Nmap
- Gobuster
- Netcat
- Python
- MITRE ATT&CK
- PTES
- Linux
- DockerLabs
The problem
How far someone without credentials can get against a misconfigured server, and how to explain that risk both to a technical team and to whoever decides the budget.
Too much information in public code
A forgotten comment in the HTML exposed a system user and an unpublished path. Everything the server sends to the browser is attack surface.
A file upload with no real control
The form accepted executable types and stored them inside the web root. Validating only the extension is not enough.
Secrets where they should not be
Credentials encoded in a log, an SSH key repeated across all accounts and its passphrase written in an internal document. Encoding is not protection.
Administration permissions that are too broad
One account could run a common utility as administrator without a password. A sudo permission on a binary that runs commands is the same as full access.
Results
- Seven documented findings, three critical, two high and two medium, each with CVSS, evidence and remediation.
- An 18-page technical report and a 14-page executive one, with a risk matrix, MITRE ATT&CK mapping and a remediation roadmap.
- 28 evidence screenshots tied to the writeup, published under the MIT license alongside the repository.
View technical details OpenHide technical details
What I built
- 01
Scope: a single DockerLabs Docker container (Ubuntu with Apache on port 80 and OpenSSH on 22), run on March 23, 2026. Nothing outside the container is in scope.
- 02
PTES methodology in six phases: preparation, exploration, analysis, attack, deep access and documentation. Documentation runs in parallel with the rest, with one screenshot per step.
- 03
Reconnaissance and enumeration with Nmap, Gobuster and an inspection of the page source, without credentials.
- 04
Seven findings, ordered by severity: three critical, two high and two medium, each with a CVSS v3.1 vector and score, affected component, likelihood and impact.
- 05
CWE classification in the writeup, a mapping of the actions to MITRE ATT&CK techniques and a risk matrix using the likelihood-by-impact scheme of ISO/IEC 27005.
- 06
Two deliverables: an 18-page technical report for the security team and a 14-page executive report with business risk, financial exposure and a prioritized remediation roadmap.
- 07
Reproducible evidence: 28 annotated screenshots in the repository, tied to each step of the writeup. The material is released under the MIT license.
Step-by-step writeup
A technical walkthrough in Spanish with one screenshot per step, published on the blog and in the repository.
Technical report
Seven findings with CVSS, affected component, evidence, remediation, MITRE ATT&CK mapping and a risk matrix.
Executive report
The same work translated into business risk, the estimated cost of fixing versus a breach, and an order of priorities.
MITRE ATT&CK mapping
Tactics and techniques tied to each action of the exercise, in a separate file.
Evidence
28 annotated screenshots covering the exercise from start to finish.
How the findings chain together
- 01 Internal information in the public source code (medium).
- 02 A file upload with no real restriction, allowing code execution on the server (critical).
- 03 An upload directory visible to anyone (medium).
- 04 Credentials in a log readable by the web service (high).
- 05 The same SSH key on every account (critical) and its passphrase in an internal document (high).
- 06 A passwordless sudo permission on a binary that runs commands (critical).
Architecture decisions
01 PTES as the structure ViewClose
- Context
- An exercise without a method becomes a list of tricks and cannot be repeated or compared.
- Trade-off
- Following six phases means documenting even when the exercise is a single lab machine.
- Decision
- PTES in six phases, with documentation in parallel and one screenshot per step.
02 Two reports for two audiences ViewClose
- Context
- A technical team needs the detail of each finding, and a decision maker needs to know what to do first and what it costs.
- Trade-off
- Keeping two documents doubles the review, and any change to a finding has to appear in both.
- Decision
- A technical report with CVSS, evidence and remediation, and an executive one with business risk, costs and priorities.
03 Every finding with a severity and a remediation ViewClose
- Context
- A list of weaknesses with no priority or fix does not help correct anything.
- Trade-off
- Scoring with CVSS and likelihood by impact adds judgment that someone else could see differently.
- Decision
- Each finding carries CVSS v3.1, likelihood and impact, a CWE classification and a concrete remediation.
04 A controlled environment with no real data ViewClose
- Context
- Practicing offensive techniques is only valid inside an authorized scope.
- Trade-off
- A lab machine has no real users or traffic, so the business impact in the executive report is estimated.
- Decision
- A single DockerLabs container as the scope, with the impact figures taken from a published source (IBM Cost of a Data Breach 2024).
Learnings
No finding in the exercise depended on an unknown vulnerability: they were configuration mistakes and work habits that repeat in real environments.
A single mistake is rarely enough; the damage comes from chaining several small findings, so fixing the cheapest link already breaks the chain.
The same finding reads differently depending on who reads it: the technical detail and the business risk are two documents, not one.