IT / Cyber Pentest From the outside, like a stranger.
We attack your systems in a controlled way: from the outside like an unknown party, from the inside like an employee whose access has already fallen into the wrong hands.
- The question being answeredWhat can someone attacking from outside achieve – and someone who is already inside the network?
- Why it mattersA vulnerability scan reports theory. A pentest shows which findings can actually be chained together and how far they lead.
- What you have afterwardsEvery finding with a reproducible path, CVSS score, management summary and re-test.
A commissioned attack on your own systems. We look for vulnerabilities and exploit them in a controlled way to show how far someone would get. The difference from a real attack: you know about it, it is agreed in writing, and we destroy nothing.
A scan is an automatic list of possible problems – often with many false positives. A pentest checks by hand which of them can actually be exploited. A scan says "this door could be open", a pentest walks through it.
This describes how much we get from you beforehand: nothing, a normal user account or full insight. Which option makes sense depends on your question – we explain it in detail on the basics page.
An internationally standardised scale from 0 to 10 for the severity of a vulnerability. That way "critical" is not our opinion but a traceable rating that your insurer or auditor also knows.
The number of a publicly known vulnerability, such as CVE-2024-1234. Publicly known means: there is a description, usually a ready-made attack tool and almost always an update that closes the gap. Systems with open CVEs are not searched for specifically – they are found automatically, often within hours of publication.
The step from "I'm in" to "I can do anything". An attacker almost never lands on the network with full rights straight away, but on an ordinary workstation account. What is interesting is how many steps it takes from there to administrator – with good separation it is many, in a structure that has grown over time often two.
From the outside, like a stranger.
A vulnerability scan tells you what is theoretically open. A pentest tells you which of it someone can actually exploit and how far they get with it. We deliver the latter.
- Technical report with reproduction steps
- Management summary
- Prioritised list of measures
- Re-test after implementation
How we work.
Scope
Objectives, systems, time windows and exclusions are defined in writing.
Reconnaissance
Passive research, followed by active mapping of the reachable attack surface.
Exploitation
Controlled and traceable. No test that endangers your operations without prior agreement.
Report
Every finding with reproduction steps, CVSS score and measure.
What it looks like in practice.
Not a sales pitch, but what we actually do – with the techniques and tools behind it.
External: the attack surface you don't know about
In almost every assessment we find at least one reachable system that nobody in the organisation knew about any more.
The external test begins by mapping your actual attack surface – and it is usually larger than the known main domain: subdomains from Certificate Transparency logs, forgotten staging systems, mail servers, VPN gateways and everything that Shodan or Censys has already indexed anyway.
We then test every reachable service specifically: outdated software versions with known CVEs, weak transport encryption, exposed admin interfaces, default credentials and accounts without two-factor authentication. For web applications we follow the OWASP Testing Guide.
Email security is a block of its own. We check whether SPF, DKIM and DMARC are set so that a forged message in your name is actually rejected. In practice the records are often there, but in monitoring mode – forged emails are reported but still delivered. For scams such as the fake payment instruction, that is the decisive difference.
Not everything that is technically possible belongs in a test. We do not carry out load attacks that deliberately take a service down. With login forms we proceed carefully so that we don't lock out real user accounts in bulk and cause an outage ourselves. What is excluded is set out in the Rules of Engagement beforehand – so specifically that there is no discussion afterwards.
Internal: the path to domain administrator
The question is not whether someone gets into the network. The question is how far they get from there.
The internal test starts from a realistic position: an attacker is already on the network – via a phishing email, a compromised laptop or an open network socket.
In Active Directory environments we test the usual escalation paths: Kerberoasting against service accounts with weak passwords, AS-REP roasting on accounts without pre-authentication, insecure ACL inheritance, LLMNR and NBT-NS poisoning to capture hashes, and password reuse between local administrator accounts.
Before getting to Active Directory, we test the network itself. Outdated name resolution services such as LLMNR and NetBIOS answer requests that should really go nowhere – an attacker on the same network can step in between and capture credentials. If SMB signing is also missing, this data can be relayed directly. Both are default settings from another era that are still active in many networks that have grown over time.
A recurring finding is passwords that are the same everywhere. If the local administrator password is identical on every workstation, a single compromised machine is enough to land on all the others. Microsoft solves this with LAPS, which manages a separate, automatically changing password for each device. We check whether it is in use – and whether really all devices are covered or only those that happened to be running when it was introduced.
Technical deep dive
Network segmentation is just as relevant: does a workstation in the office actually reach the production control system, the camera system or the administration servers? Separation is often planned but cancelled out again in the firewall rules by a historical exception.
Wi-Fi, cloud and the question of authorisation
Cloud tests have one special feature: not everything that is technically possible is contractually permitted.
For Wi-Fi we test the authentication. WPA2-PSK with a key that hasn't changed in years is the norm in smaller businesses. With WPA2-Enterprise we check whether clients really validate the server certificate – otherwise the login attempt can be intercepted with a cloned access point. We check guest networks for actual separation.
Azure, AWS and Microsoft 365 are in scope if they are part of your infrastructure. The provider's terms of use apply here: some types of testing are allowed without prior notice, others are not. We clarify this beforehand and record it in the Rules of Engagement.
With the guest network we are less interested in the encryption than in the separation. A guest access that points to the same router and reaches the internal network from there is not a guest network, but a second name for the same network. We also check whether devices on the guest network can see each other – in waiting areas, studios and schools that is the norm and rarely intended.
In the cloud the focus shifts from servers to identities and permissions. Typical findings: app registrations with far more rights than the application needs, access tokens without expiry, administrator roles that someone was given for a one-off task and never gave back, and Conditional Access rules with so many exceptions that the rule effectively no longer applies. None of this triggers an alarm – it only becomes apparent when someone looks specifically.
What is included – and what explicitly is not.
So that you know what you are getting into before you commission us. The exact scope is defined in the intro call.
Typical scope
A clearly defined target: a web application, an external perimeter or an internal network segment. Combinations are possible but are calculated separately.
Duration
Three to ten test days depending on size. The report follows within one week of the end of testing; critical findings appear in the portal immediately.
Prerequisite
Commission, Rules of Engagement and – for cloud services – confirmation that the provider in question permits the test.
Not included
No denial of service, no tests against production systems without explicit approval, no attacks on third-party systems.
A pentest is a snapshot. It replaces neither ongoing vulnerability management nor regular patching – it shows what an attacker would achieve today.
What clients want to know beforehand.
No. Aggressive tests that risk an outage are explicitly agreed with you beforehand. The norm is a controlled test during normal operations.
It depends on the question. Black box shows what an outsider achieves without prior knowledge. White box finds more in the same time, because we don't first have to search for what you already know.
Yes – Azure, AWS and Microsoft 365 are part of the standard scope if they are part of your infrastructure. We tell you beforehand what the respective cloud provider permits without prior notice under its terms of use.
Yes, on request. By default we deliver the prepared report in the portal; you can also download scan output and evidence as raw data.
An external test of a manageable attack surface is done in three to five days, an internal test with Active Directory more like one to two weeks. Preparation and reporting come on top. Realistically, four to six weeks lie between commission and final report – but you see the findings in the portal from day one, not only at the end.
We may only test those with the provider's knowledge. If someone else runs your server, your shop or your phone system, we need approval from that provider – otherwise we would be testing someone else's infrastructure without a mandate. We tell you beforehand which approvals are needed and can help word the request.
What often goes with it.
We're standing in your server room.
We get into your building – with the same means as a real attacker, but with your signature in our pocket and a photo as proof.
What is already out in the open.
We gather what can be found freely about your organisation before someone else does. Completely passive – we don't touch your systems.
The moment of decision.
Technology can be patched, people can't. We train the decision in the moment of the attack – measurable, repeatable and without singling anyone out.