How we test, what we keep finding and what a test costs; written between assessments by the people who run them.
Choosing a penetration testing provider is not only a matter of the name. The cover of the report does not tell you whether a senior specialist or a first-year tester did the work. This post sets out seven questions that make clear, before you sign, who you are hiring and how experienced they are.
Read more
Attackers remotely raised the temperature of supermarket refrigeration, including in the Netherlands. What could come to a halt in your business if an admin account or a supplier's access falls into the wrong hands? Three questions to work through with your IT team, and how a penetration test shows how far an attacker gets.
A tester sees source code, configuration and user data during a penetration test. What protects you is the agreement plus the way the tester actually works. This post covers what the contract should say, how a careful tester limits what is touched, where findings are stored, who the testers are, and six questions to ask any provider.
A penetration test does not guarantee security. It proves what was found in this scope, in this window, by these testers, and that limit is exactly what makes the result usable. This post explains what a test proves, why it cannot be a guarantee, what makes the result worth more, and how to use it with an auditor or a customer.
A penetration test proves which vulnerabilities exist in a defined system; a red team assessment tests whether the organisation notices and stops a realistic attack with one objective. This post sets out the difference in scope, method, duration and outcome, when each is the right purchase, the scenario-based middle ground, and where DORA and NIS2 decide the matter for you.
Two different things are called the duration of a penetration test: the testing days and the calendar time. Most assessments take three to ten testing days; the report follows within five business days after testing and the retest within 90 days. This post gives indicative testing days per service, the steps from the first call to the report, and what stretches or shortens the calendar.
Good preparation keeps testing days in testing rather than in waiting, and it is the cheapest saving on a penetration test. This post lists what to decide before the scoping call, what to deliver three business days before the start, which environment to offer, who inside your organisation should know, and what happens during and after the test. A checklist at the end shows who does what by when.
A connected swimming pool is still a web application with a motor attached. On a previous assessment the login worked and almost nothing after it did. This is a field note on broken access control in an IoT platform: how a verification link became an admin key, how any account could drive another user's devices, and how a cloud request became a physical command at a heat pump.
At least once a year and after every major change is the short answer. The real interval follows how fast your environment changes and how much depends on it. This post sets out what ISO 27001, PCI DSS, DigiD, NIS2 and DORA require, which changes call for a test now rather than next year, and a practical cadence per situation.
A web application penetration test bought in the Netherlands has two jobs: prove which vulnerabilities the application has, and produce evidence in the form Dutch law, Dutch norms and Dutch auditors ask for. This post covers what the test examines, which frameworks drive it here, what it costs and how long it takes, what the report must contain, and what to check about the provider.
When an injection is blind and the target is rate limited, inference alone crawls to a halt. This is a field note on the technique that gets past both: forcing the database to leak its own data over DNS, one 63-character label at a time.
Do your security measures also work in practice? Read how a penetration test helps with NIS2 and which steps you can take to address risks where it matters.
A mobile app is a client you hand to the user and a set of API calls you cannot see. Testing it well takes two views: static analysis of the app itself and dynamic testing of it while it runs. This post covers what each reveals.
Schedule a free intake call to scope your assessment. Pentrox identifies vulnerabilities in your applications, infrastructure, and cloud environments before attackers do.
Schedule an intake call