Vulnerability Scanning
Outer skin, internal network, web applications and cloud checked continuously against CVE — rated against your situatio…
ViewOffensive Services
Penetration Testing
A vulnerability scan tells you which doors are unlocked. A penetration test tells you how far somebody gets who walks through them — and what they could take along the way. We carry out that attack, under your instruction and within your limits, before somebody does it without either.
01
What it is
The difference from a vulnerability scan
The two are often listed side by side in proposals, as if they were grades of the same thing. They are not. A scanner works through a list of known weaknesses and reports which of them apply. That is valuable, fast and cheap — and it stops exactly where the interesting attacks begin.
Because most serious incidents do not come from a single gap but from a chain: an outdated test system nobody watches any more; a service account with more rights than it needs; a network segment more open than intended. Each link on its own would look harmless. Only together do they form a path from the outside into the customer database.
No automated procedure finds those chains. They emerge from understanding your organisation, your processes and what is worth taking. We use the same tools and the same techniques as an attacker — the only difference being that we write a report at the end instead of disappearing.
The process
Seven phases, like a real attack
We work to established methodologies — OSSTMM, PTES and, for web applications, the OWASP testing guide. The sequence is deliberately the one an attacker would follow; only the ending differs.
- 3–5 days
- for a single web application
- 1–2 weeks
- for a mid-sized infrastructure
- 3 days
- for analysis and reporting
- 1 day
- for the retest after remediation
After remediation we retest the findings. A report that ends up in a folder has changed nothing — only a passed retest closes the matter.
- 01
Reconnaissance — we collect what can be found publicly about your organisation: domains, address ranges, names in professional networks, orphaned subdomains. The first foothold often appears here already.
- 02
Enumeration — which systems respond, which services run, in which versions. Comparing that against what you expect is regularly the first finding.
- 03
Access — the attempt to actually get in. Through a gap, through valid credentials from a breach, through a person.
- 04
Privilege escalation — from the first foot in the door to administrator. This phase decides whether an incident is annoying or existential.
- 05
Dwell time — how long would the attacker stay undetected? That is the real test of your monitoring, not the question of whether the break-in succeeds.
- 06
Traces — we check what your logging recorded of all this. Frequently less than expected.
- 07
Report — findings ordered by severity, each with evidence, impact and a concrete countermeasure. Plus a summary readable without an IT background.
Think like an attacker, report like an expert witness.
02
The variants
Which scope your test needs
01
Two questions determine effort and value: how much do we know beforehand, and where do we attack from? The right answer depends on what you want to find out — not on what sounds most thorough.
02
Black box
We start with what anyone on the internet can find. That is the most honest simulation of an external attack and shows how far a stranger gets without prior knowledge. The price: a substantial share of the time goes into reconnaissance an attacker would also spend — except that they have no end of budget.
03
White box
You give us architecture documents, access and, where useful, the source code. The same time then finds considerably more. This variant is the most thorough and the choice when evidence is required — but it does not answer how hard it would be to get in from outside.
04
Grey box
The usual compromise and in most cases our recommendation: limited prior information, for instance a user account without special rights. That tests what an attacker can achieve who already has a foot in the door — the most common real starting point.
05
From outside or from inside
The external test examines what is reachable from outside: firewalls, web servers, VPN access, cloud services. The internal one starts where an attacker stands after the first successful step — or where a disgruntled employee stands anyway. Testing only the outside tells you nothing about the second half of the damage.
The findings
What we almost always find
After many tests the patterns repeat. That is not bad news — it means a great deal can be achieved with manageable effort before the hard cases come into play.
01
Unpatched systems, usually not the productive ones but the forgotten ones: the test server from two years ago still hanging on the network.
02
Credentials that may do too much. Service accounts with administrator rights, because it was quicker to set up that way.
03
Misconfigurations on systems that are current and secure in themselves — just set up wrongly.
04
People who do not recognise a well-made message as an attack. No blame, but the reason why security awareness training sits next door.
03
The basis
Who tests, and under what terms
A penetration test is an authorised attack on somebody else's systems. Without a clean legal basis it is a criminal offence — and the best intentions change nothing about that. Before the first packet there is therefore always a written engagement setting out scope, timeframe, permitted techniques and the emergency contacts.
Where systems are involved that you do not own yourself — hosted with a provider, in somebody else's cloud, operated by a service partner — we obtain their consent before touching them. That costs lead time and is not negotiable.
Our testers hold the relevant certifications — OSCP, GPEN, CEH — but those are the entry ticket, not the qualification. What matters is the experience of which chain is likely in your industry, and the discretion to handle what one gets to see along the way.
04
The rhythm
A test is a snapshot
The result holds for the state on the day of testing. Every new application, every migration, every interface opened changes the position. An annual test is the sensible baseline; more important is an additional one after every major change — when something new has actually been created.
If you want to keep an eye on the position in between, combine the test with continuous monitoring. What the test uncovers once, Strider keeps visible in operation, and the state of remediation lands in Sightadel.
05
In closing
Only those who know their weaknesses can close them
The value of a penetration test does not lie in the report. It lies in what happens afterwards: in the findings that were worked through and retested, and in the certainty that the remaining ones are consciously accepted rather than unnoticed.
Talk to us about scope and design. The initial conversation costs nothing and usually produces a first usable assessment on its own.
FAQ
Frequently asked questions
Can a penetration test damage or take down our systems?
The risk cannot be reduced to zero, but it can be contained well. Techniques carrying an availability risk — load testing, or exploiting certain memory errors — are explicitly approved or excluded in advance. For critical systems we prefer to test against a copy or within an agreed window. And throughout the test there is a number on which we stop immediately.
How long does a test take?
For a single web application usually three to five days, for a mid-sized infrastructure one to two weeks. Add roughly three days for the report. The retest after remediation normally takes a day.
What happens to the data you see along the way?
We access only as far as needed for evidence — an extract from a table rather than its full contents. What we see is confidential, stored encrypted and deleted after an agreed period. The details are in the contract, not in a statement of intent.
Should our IT and SOC be told in advance?
That depends on the goal. If they know, you are testing the technology. If they do not, you are also testing detection and response — which is more valuable, but requires at least one person on your side to be informed and able to confirm the test if in doubt.
Is a penetration test enough for ISO 27001 or NIS2?
It is one building block, not evidence in itself. Both require regular technical testing, and a test with documented remediation satisfies that point. It does not cover the remaining requirements — that is what ISMS implementation is for.
Offensive Services
More in this area
Contact
Reputation takes years. Destruction takes seconds.
Talk to us before somebody else does. The first conversation is free and we reply the same business day.