Reconnaissance. Enumeration. Scanning. Finding vulnerabilities. It all looked good on paper.
I also knew that it was going to be fierce.
What I had not anticipated was how daunting it would be knowing how to actually do it the first time.
And, to my surprise, I was not even excited about it. These days nothing really excites me.
Nevertheless, I showed up.
The Objective
During the ethical hacking sprint at Cyblack, we had to perform a structured penetration test of an insecure banking app hosted on Vulnbank.
It was not merely to be able to find bugs. It was to:
- Know the approaches of attackers to systems.
- Determine actual vulnerabilities with industry tools.
- Analyze their impact
- And report findings in a concise, organized report.
In a nutshell: take theory into practice.
The First Few Days: Confusion.
For the first few days, I was lost.
Not the 'I don't get this one concept' kind of lost. It's the 'where do I even start?' kind.
Although I knew the theory, I found it different when putting it into practice.
Reconnaissance and enumeration were no longer a step but a decision:
- What is it that I am looking for?
- Which results matter?
- What is just noise?
We finally received advice on how to go about the process, and things began to fall into place.
But that initial confusion? It was real.
The Approach: Scanning to Understanding.
After it became clearer, we completed a systematic process of penetration testing.
1. Reconnaissance & Scanning
We began by determining what was exposed.
With Nmap, we have scanned the target and have found:
- Open ports
- Running services
- Potential entry points
At this point, it was easy: run a command and receive results.
However, that simplicity does not last.
2. Enumeration
This is where things began to get problematic.
We used tools such as WhatWeb and Nikto to gain an understanding of:
- Which technologies the application was operating with.
- Server configurations
- Exposed endpoints
Enumeration wasn't just about gathering data. It was about understanding the significance of that data.
Believe me, one of the most challenging things for me was this.
3. Vulnerability Discovery
We followed this up with identifying real weaknesses through:
- Nikto, a tool for discovering misconfigurations on web servers.
- Burp Suite, a tool that can be used to inspect requests and responses.
- OpenVAS, an automated vulnerability scanner.
This phase unearthed several problems, many of which had little to no complexity but were extremely impactful.
4. Analysis
This is where ethical hacking becomes "thinking-based" and not "tool-based."
Each finding had to be:
- Validated
- Understood
- Real-world impact mapped
Not all the items that a tool detects are vulnerabilities.
The Findings: Simple But Dangerous
The one thing that immediately stood out was:
The majority of the vulnerabilities were not advanced.
They were… basic.
- The application was running without HTTPS.
- Lack of security headers such as CSP and X-Frame-Options.
- An error was detected when trying to find an unsafe cross-origin resource.
- Sensitive information was being leaked via headers and endpoints
- The API documentation (Swagger UI) was openly accessible.
- A Slowloris DoS vulnerability was discovered
- The system was using an older version of Python that posed significant risk.
But what really got me thinking, though?
A negative account balance manipulation flaw.
This was no simple matter of engineering. This was indeed a business risk.
What Challenged Me
Being new to ethical hacking was already a challenge.
However, there was something more that was noticeable:
Too much information.
Tools will NEVER provide clean answers. They provide all information you need.
And you have to:
- filter it
- interpret it
- decide what matters
It's not about running more tools at some point.
It is essentially a matter of what you see.
What Changed for Me
Before this sprint, ethical hacking felt like:
run tools → find vulnerabilities → done
Now, I see it differently.
Ethical hacking is:
- knowing where to look
- understanding what you find
- and connecting small weaknesses into real risks
Because most systems don't fail because of one big vulnerability. They fail because of multiple small ones that are left unchecked.
Final Thoughts
This sprint wasn't easy all of a sudden.
It did, however, do something more important:
It changed my way of thinking.
From "what tool should I use?" to "what am I looking for?"
And that changes everything.