Infrastructure Penetration Testing

Modern IT infrastructures are complex and have usually evolved over time. This is precisely what leads to misconfigurations that nobody notices in day-to-day operations: a rule created three years ago for a test, a legacy system that an application still relies on, or an administrative account that was never removed from the client network. We assess your network and system landscape – from the Firewall through the servers right up to the Cloud – and show you just how resilient it really is.

Request a demo Procedure & Methodology

INFRASTRUCTURE AUDIT

Infrastructure
Pentest

Penetration Testing

Target

Networks, servers, cloud, VPN

Perspective

External and internal

Focus

Configuration errors

Prerequisite

IP ranges & maintenance windows

When an infrastructure test is due

The environment has been re-engineered, migrated or extended to include Cloud services.
New sites or network segments have been added, and the segmentation has never been checked.
Remote access has been expanded and it is unclear exactly what can be accessed via it.
A service provider has taken over systems and you wish to have the handover status independently assessed.
Legacy systems are still running because an application requires them, and nobody knows the exact level of risk.
An audit in accordance with ISO 27001 or BSI Basic Protection requires evidence of technical hardening measures.
Following an incident, it must be demonstrated that the exploited pathway has been closed and no other remains open.
Your cyber insurance provider is asking for a recent test.

What we test for

The perspective determines which questions a test answers. We combine perspectives as required.

From the outside

We check what can be accessed without any form of access: exposed services, remote access points, email and web infrastructure. The question is whether there is a way in from the outside.

From the inside

We operate from within your network, just like an attacker following a successful Phishing email or a guest in the wrong network segment. The question is, how far can this attacker get?

Assumed Breach

We assume a compromised system and assess the spread from there. The most realistic starting point for Ransomware scenarios.

What we’re looking at

External attack surface: Anything that responds from the outside: remote access points, VPN gateways, mail servers, web servers, administrative interfaces and services that have been inadvertently exposed. If your initial aim is simply to carry out a comprehensive inventory of this surface, the Attack Surface Analysis is the more suitable starting point. The Pentest also checks which of these vulnerabilities can be exploited.
Network segmentation: Whether the separation between zones holds: client to server, guest network to production network, office to production, and whether the management network is truly segregated.
Servers and services: Patch and version status, default configurations, unnecessarily active services, shares with overly broad permissions, and protocols that are still running for compatibility reasons.
Authentication and access: Role-based models, local administrator accounts, reused passwords, and the question of whether a single compromised account grants access to multiple systems.
Network devices: Firewalls, switches, routers and their management interfaces. Management interfaces accessible using default credentials are not an isolated case, but a classic vulnerability.
Cloud and hybrid: Configuration of IaaS resources, access rights to storage, identity federation and the connection between the on-premises environment and the cloud. This connection is often the weakest link, as nobody regarded it as a potential attack surface when it was set up.
Peripherals and ancillary devices: Printers, cameras, building services and devices that are not subject to software maintenance but are connected to the production network and store credentials.
Backup: Experience shows this is the most critical issue: whether your backups are accessible from the production network and can be deleted using the credentials used there. This is precisely what determines whether a Ransomware incident remains just that – an incident – or becomes a threat to the organisation’s very existence.

What we frequently see

Findings	Why it matters
Management interfaces accessible via the client network	Just one compromised workstation is enough to take control of network devices.
Default or reused credentials	A breach does not open up a single system, but an entire class of systems.
Missing or bypassable segmentation	The attack does not remain local, but immediately reaches critical areas.
Outdated services with known vulnerabilities	Publicly available exploits; no specialist knowledge required.
Backups in the same trust domain	Recovery fails precisely when it is needed.
Orphaned systems with no one responsible	No one patches them, no one monitors them, no one even realises they’re missing.
Test systems with production data	The security level of a test system, the potential for damage of a production system.
Insecure legacy protocols	Enable the interception of login credentials on the network.

How a test is run

Scoping and Approvals

We define scope, perspective, time window and exclusions, and clarify the necessary approvals.

Inventory

Systematic capture of reachable systems, open ports, services and versions. The result is a map of what actually exists, not of what the documentation says.

Vulnerability Analysis

Assessment of the discovered systems for known vulnerabilities and misconfigurations, verified manually rather than taken from a scan result alone.

Exploitation

Controlled testing of whether a finding is practically usable. Only this step distinguishes a possible vulnerability from an actual one.

Lateral Movement

Moving on from a compromised system: which credentials are stored there, which systems can be reached with them, how far the chain extends.

Report and Debrief

Documentation, prioritisation and handover. Critical findings are reported immediately, not first at this stage.

What we don’t do

The most common concern with infrastructure testing is that something will fail. Therefore:

No overload attacks: Availability attacks are prohibited unless expressly agreed otherwise.
No destructive actions: We do not delete, encrypt or alter any production data.
Sensitive systems are identified: Anything you designate as sensitive will be excluded or only monitored passively.
Time windows are adhered to: Active assessments run within the agreed time windows, outside business hours if necessary.
Immediate reporting: If we find anything that could be exploited imminently, or evidence of an incident already in progress, we report it immediately.

What you provide

IP ranges, domains and systems to be included, as well as an exclusion list.
A maintenance or test window, if active assessments are only to take place at specific times.
For the internal test, network access: an on-site network socket, VPN access or a device provided by us.
A technical contact person who is available during the test.
For hosted or Cloud-based systems, clarification as to whether the provider requires notification or authorisation for penetration tests. This applies to more providers than is generally realised and should be clarified before the test begins.

What you’ll take away from this

A technical report containing a catalogue of hardening measures, as well as an answer to the question that determines budget allocation internally: How far could an attacker get from a single compromised system?

We provide a clear overview of the attack chain, as this determines the order of priority. A single misconfiguration is rarely critical. What is critical is the point at which three of them, taken together, create a path to your backups. That is precisely where the first measures come into play.

“Infrastructure penetration tests reveal just how resilient your organisation really is.”