Introduction
From June 8 to August 14, 2026 I did my university internship on the External Security team at Hiberus, in Madrid. Ten weeks, full time, 350 hours. When it ended I stayed on the team as a Cybersecurity Technician, which is probably the best summary of how it went.
Before June, everything I knew about pentesting came from Hack The Box Academy, CTF-style machines and my own labs. Those taught me techniques. The internship showed me what a security assessment looks like when the target belongs to someone who is paying for it, who has signed a scope, and who will read every line of the report.
This post is about that difference. I wrote it for students who are where I was a few months ago.
A note on confidentiality: client work is covered by confidentiality agreements, so there are no client names, sectors, findings or screenshots here. Everything below is about methodology and about what I learned, never about a specific engagement.
1) What the work looked like
The team does offensive security for clients. During my ten weeks that meant three kinds of audit:
- black-box penetration tests of web applications,
- security assessments of cloud infrastructure,
- reviews of Microsoft 365 and Azure tenants, focused on identity policies, permissions and resource exposure.
I also took part in two other audits outside those categories.
The methodology was standard. PTES defined the phases (reconnaissance, scanning, exploitation, post-exploitation, reporting), the OWASP Top 10 and the WSTG structured web testing, and CVSS v3.1 scored severity. The tools were the ones you would expect: Burp Suite for web testing, Nmap and Nuclei for discovery, certificate transparency logs and DNS enumeration for reconnaissance, and PowerShell with the Az module plus the Microsoft Graph API for tenant reviews.
None of that was new on paper. The pace was: at the busiest point I had three or four engagements open at once, each one in a different phase. I could be closing reconnaissance on one, exploiting on another and writing the report for a third, while a client asked to change the scope halfway through an audit.
Most testing was done in pairs with a more experienced consultant. In the first weeks my tutor reviewed every finding before it went into a report. By the end, reviews focused on high-severity issues and on whether the recommendations held together, and I documented medium-severity findings on my own. That gradual handover taught me more than any single task.
2) What labs do not prepare you for
Most of the waiting is for access
In a lab, the machine is up, the scope is one IP address and nobody needs to approve anything. In client work, a surprising amount of time goes into access: authorizations, test credentials, IP allowlists. On some days, waiting for access was most of the work.
That changes how you plan. You learn to ask for everything you need on day one, and to keep a second engagement ready for when the first one is blocked.
Know what you touched
Real systems have real users. Before running anything heavy you think about what it might break, whether the scope covers it and whether the client knows it is coming. Labs reward trying everything. Client work requires you to know exactly what you touched, when and why, because someone may ask.
Scanner output is a starting point
A lot of hours went into triaging the output of automated tools. Most of it was false positives that repeat from one target to the next. Once you understand why a check fires, the triage becomes mechanical and teaches you very little.
It did leave one habit. I don’t trust a tool’s result until I have verified it by hand, and nothing goes into a report because a scanner said so.
3) The report is the product
I went in thinking of the report as the boring part of the job. I ended up learning more from writing findings than from finding them.
To write a finding properly you have to:
- justify the CVSS score, metric by metric,
- describe the attack so that someone else can reproduce it,
- propose a fix that is realistic for that particular client.
Each step forces you to understand the vulnerability better than you did when you found it. A working payload proves the bug exists. The report has to explain why the application is vulnerable, under which conditions it can be exploited and what the fix actually changes. My notes on documentation and reporting from HTB Academy covered the theory. Writing reports for real clients was the practice.
Then comes the meeting. I joined several results presentations with my tutor, and that is where a finding becomes a business decision. The people in the room do not care about the payload. They want to know what could happen and how much it costs to prevent it. Translating a technical issue into those terms, and defending the report in front of the client, was harder for me than a good part of the technical testing.
There is also a less glamorous side: formatting reports to the corporate template, numbering figures, cropping evidence, proofreading. It adds nothing technical. It is still part of the quality the client perceives, and the report is the only thing the client gets to keep.
4) Two mistakes and the habits they left
A false positive I almost reported
Early on I treated something as a finding until my tutor discarded it in review. It looked right, the evidence seemed to support it, and it was wrong.
Since then I follow a simple rule: reproduce every vulnerability twice, and save the evidence before writing a single line of the finding. If I cannot reproduce it, it is not a finding yet.
No system for parallel work
With three or four audits open at once, my first weeks were less efficient than they should have been. I lost time switching context, searching for evidence I had already collected and re-checking things I had already tested.
The fix was a personal system: a priority list per engagement and a strict evidence log with timestamps, so that every finding can be traced back to the request and response that prove it. It is not sophisticated, but I would not work without it now.
5) What the degree gave me, and what it did not
My Computer Engineering degree helped more than I expected, mostly in the background.
- The networks and operating systems courses carried the reconnaissance and infrastructure work.
- Databases and web development made injection and broken access control make sense. Knowing why the bug exists helps more than knowing how to exploit it.
- Years of writing technical documentation for coursework meant reports were never an obstacle.
The gap was business: contracts, scope agreements, the legal framework around testing, and how a company decides what to fix first. A security consultant needs more of that than I had, and it is what I want to work on next.
One part of the cycle I did not see during the internship was retesting, checking the fixes a client applies after the report. The engagements simply outlasted the ten weeks. I do retests now as part of the job.
Final thoughts
I asked for this internship to answer one question: is offensive security what I want to do? The answer is yes. The difference from labs is that someone else owns the system, and you have to be able to show exactly what you did to it.
If you are a student preparing for your first pentesting job, this is what I would tell you after these ten weeks:
- Practise writing findings, not only finding them. Take a machine you have already solved and write the report as if a client had paid for it.
- Build an evidence habit now. Requests, responses, timestamps and screenshots, saved as you go.
- Learn to explain impact without jargon. Try it on someone who does not work in security.
- Expect to wait for access. Credentials, permissions and allowlists slow real engagements down far more than technique does.
Thanks to Jose Manuel Noja Polman and Carlos Dolz del Castillo for their patience and for letting me learn by doing, and to the whole External Security team at Hiberus. I’m glad I stayed.