From outside through the perimeter into the internal network, onto the servers and into your cloud. Not as a list of individual findings, but as the path an attacker would take.
Manual analysis, not a scanner export
Rules of engagement agreed upfront
CVSS rating and PoC for every finding
Five zones, one attack path
Attack path
01
Internet
What is visible from outside
Port scans
Exposed services
Forgotten VPN access
02
Perimeter and firewall
The boundary meant to hold
ACL bypass
Routing errors
Missing segmentation
03
Internal network
What happens after the first click
Lateral movement
LLMNR and NBT-NS
Default credentials
04
Servers and services
The systems themselves
CVEs with exploitation
Databases without a password
Management interfaces
05
Cloud and hybrid
The transition that hardly anyone checks
IAM policies
S3 buckets and Azure Blobs
Jump from on-prem into the tenant
The value is in the chaining: several findings, harmless on their own, together make up the path from outside to privilege escalation.
Vulnerability scan vs. pentest
Automated scan
Our pentest
Finds known CVEs for which a signature exists
Tools provide the basis, a human does the assessment
Sees an open port
Shows what is possible behind it, up to lateral movement
Delivers a list
Delivers PoCs and an order in which to work through them
What the report contains
Management summary for the decision-making level, technical section for the admins
Every finding with CVSS score, how it was exploited and a description of the fix
Reproducible proofs of concept that your team can recreate for itself
Prioritisation: what gets patched right away and what belongs in the hardening strategy
We deliver the test and the technical evidence. Certification, legal advice and reports to authorities are not part of it.
How often
After every major change to your architecture and whenever new core services are rolled out. Beyond that, a test once a year is the usual rhythm; ISO 27001, TISAX and NIS2 do not themselves prescribe a fixed interval. Your IP ranges are being probed by automated tools every single day anyway.
What we need from you
A list of the IP ranges and domains that are in scope, a technical contact person and, for the internal part, network access or a notebook connected to your network. Everything else we clarify together at the kickoff.
Where attacks typically start
Shadow IT and unpatched hosts
Forgotten servers, old DMZ systems, services on default ports. That is exactly where the way in begins.
Misconfigurations
Incorrect ACLs, unsecured services and routing problems open up paths that need no exploit at all.
Lateral movement inside the network
One click or a compromised client quickly leads to critical privileges.
Egress filtering
Many rule sets keep attackers out and let data leave unhindered. We check whether a connection to a command-and-control server can be set up from your network and whether data can leak out via DNS tunnelling or ICMP without anyone noticing.
Hardening vs. patches
In our tests, misconfigurations are regularly more dangerous than missing patches. A fully patched server remains attackable if it uses default passwords, offers Telnet or unsecured SNMP, or can be reached via LLMNR and NBT-NS. That is why we test against the principle of least privilege, not just against the patch level.
Cloud and hybrid
The classic network boundary is disappearing. Alongside the on-premise servers, we look at IAM policies, misconfigured storage buckets and insecure API interfaces. In hybrid setups the transition matters most: can someone get from a compromised server into your tenant?
With Red Teaming and Social Engineering
The Infrastructure Pentest hardens systems. Red Teaming also tests whether your blue team notices movement in the network at all. Add Social Engineering and the test starts where real attacks start: with a click on a client that we then work from.
Frequently asked questions
Does the test disrupt ongoing operations?
A pentest is not a load test. We work with targeted exploits and scans that take availability into account, agree maintenance windows beforehand and get in touch before we move on to critical systems.
Do you test Azure, AWS and Google Cloud?
Yes. The focus is on IAM policies, storage buckets, API interfaces and, in hybrid setups, the transition between on-prem and tenant.
Do you check whether data can leak out unnoticed?
That is part of it. We try to set up a C2 channel and exfiltrate data via DNS tunnelling or ICMP, and record what your filters see of it.
How does the report help with remediation?
It separates the management summary from the technical section, rates every finding by CVSS, shows the exploitation as a PoC and sorts by urgency. We remain available afterwards for questions about implementation.
Do you test from outside or from inside?
Both, and the interesting part is the transition. From outside we see what a stranger sees. From inside we simulate the situation after a click on a client and check which paths are open from there.
What about systems we do not know about ourselves?
Shadow IT, old DMZ systems and unpatched hosts are the classic way in. We look for them in the first two zones, and the report lists them individually.
Want to know how far someone gets into your network?
In a free initial call we agree scope, zones and rules of engagement. Afterwards you receive a written quote.
