We attack your systems before someone else does. With your permission.
Who it is for
For companies and public bodies with systems exposed to the internet: a website, a portal, an API or remote access. And for anyone who has to show, every so often, that someone has tried to get in and what they found.
The problem
Your website has been on the internet for years and nobody has tried to get in on purpose. Or a test was done once, several redesigns ago. A customer asks for your latest penetration test report and you have no recent one. And you worry that the test itself might bring something down.
How we solve it
We agree in writing what is attacked, when and how far. Then we try to get in the way an outsider would. Whatever we achieve is documented with its evidence and with how to close it. And we repeat it regularly, because your systems change.
What it includes
Agreed scope
Which systems, which techniques and what is left out, in writing.
Signed authorisation
From someone entitled to give it. Without it we do not start.
Agreed windows
When testing happens and who is told if something behaves oddly.
Tests from outside and as a user
Without credentials, and also with those of an ordinary user, to see what they can do beyond their role.
Report with evidence
Each finding with how to reproduce it, what it allows and how to fix it.
Retesting
We test the fixes again and repeat the test at the agreed frequency.
How we work
First, the scope and the authorisation. Without both in writing, nothing is launched. We test in the agreed windows and, if we find something serious, we tell you at once, without waiting for the report. At the end you get the report with what is confirmed, what is still to be validated and the minimum fix. Once you have fixed it, we test it again.
What we measure
Findings by severity, findings fixed and verified in the retest, findings still open since the previous test, and the date of the last test.
How it is built
The test follows an order: reconnaissance of what is exposed (domains, services and versions), search for flaws and controlled exploitation of those that appear, only as far as needed to show the impact. We do not delete or modify data, and we do not run denial-of-service tests unless they are agreed.
We look at the TLS and security header configuration, authentication and sessions, permissions between users, form and API inputs, and file uploads. We use the OWASP Top 10 categories as a reference. If the system sits behind a web application firewall, such as Cloudflare's, we also test what it lets through.
Each finding is checked twice before it reaches the report, as in the code audit: one agent proposes it and a different one tries to refute it. Test credentials are kept in a secrets manager and revoked at the end.
What we test outside we apply inside: we work with the controls of the Spanish National Security Framework (ENS), currently under audit.
Frequently asked questions
Can the test bring my website down?
The tests are done to demonstrate the flaw, not to cause damage. We do not run denial-of-service tests unless they are agreed, and the windows are agreed with you. If you prefer, we test in pre-production first.
Why is written authorisation needed?
Because attacking a system without its owner's permission is a crime. The authorisation states who allows it, what may be tested and when.
How often should it be repeated?
It depends on how much your systems change and on what your customers ask of you. The frequency is agreed at the start and written into the scope.
What happens if you find something serious?
We tell you at once, without waiting for the report, with what is needed to close it.
Also in Security
Security audit
Of your code and your applications, with every finding checked twice.
Access and secrets
Who gets in where, and no password outside its manager.
The next step
Tell us how you work today and we will tell you where to start.