Network & infrastructure penetration testing.
From the public perimeter to Active Directory. We find how far an attacker would get from a single foothold, and prove it.
We secure the Czech tech companies that made it globally.
Network & infrastructure penetration testing
Most organisations' perimeter is tighter today than it has ever been — cloud, VPN, multi-factor authentication. The real risk sits inside: a single phished workstation, a contractor's laptop or a forgotten server is enough for an attacker to keep moving — through reused passwords, legacy protocols and Active Directory misconfigurations, to domain admin and the data the business runs on. A vulnerability scan does not see that path: it reports CVEs ordered by score, while the attacker usually needs none of them.
Our network & infrastructure penetration testing is therefore built on attack paths, not on a list of vulnerabilities: we map what is reachable, chain individual weaknesses into a realistic path and demonstrate it end to end. Scope covers the external perimeter, the internal network (typically as an assumed breach — from the position of an ordinary user or workstation), wireless networks and, on request, industrial and OT environments (ICS/SCADA).
How a test runs
Every network penetration test runs in three stages — from mapping the attack surface to proving real impact.
Attack surface mapping
From outside: domains and subdomains, cloud resources, exposed services and management interfaces (RDP, SSH, VPN, mail and remote-access portals), leaked credentials, forgotten and unpatched systems. From inside: hosts, services, file shares and above all Active Directory — users, groups, GPOs, trusts, ADCS. The result is not a list of IP addresses but a map of targets.
Attack path design
From the map we build the paths a real attacker takes: reused passwords and shared local-admin passwords, legacy protocols (LLMNR/NBT-NS, NTLM relay, unsigned SMB), Kerberos abuse (Kerberoasting, AS-REP roasting), ADCS and Active Directory permission misconfigurations, default credentials, unpatched services, missing segmentation. Weaknesses that look "low" on their own form, in a chain, the path to domain admin.
Execution and impact
We execute the paths safely, coordinated with your operations team, and document the impact: which systems and data we reached and with what privileges. Severity is rated by CVSSv3 on demonstrated impact, not on a scanner's score — a finding reads "here is how far we got", not "this looks risky".
Wireless networks are tested including WPA2/WPA3-Enterprise configuration, guest-network isolation and evil-twin attacks. In OT environments the approach follows the sensitivity of the process — from passive analysis to active tests in a maintenance window, always by agreement.
What you get
A report in four parts: a scope recap, a management summary with an expert opinion on your security standing, an audit-findings checklist sorted by severity, and detailed findings — each with description, impact, CVSSv3 severity, and a concrete proposed fix. Every finding is peer-reviewed so your team can reproduce and fix it fast.
Every test is run by certified senior specialists — no junior hands learning on your systems.
Use the test results toward NIS2, DORA, ISO 27001, and PCI-DSS.
Pricing
Scope follows the number of hosts and services, the number of sites, and whether the test is external, internal or wireless; for OT environments, the agreed testing mode. We confirm scope and price on a short call.
Our insight.
The path to domain admin rarely runs through a CVE. Usually through a password reused on a service account.
Frequently asked, always answered.
During testing, will any of our services be temporarily unavailable or data damaged?
The goal is not to disrupt service or damage data, and any potentially destructive test is agreed in advance. A system's reaction to an exploit cannot always be predicted, so we coordinate with your operations team and recommend current backups.
What is the difference between a black box, grey box and white box test?
The amount of information the tester is given up front. Black box imitates an outside attacker with no knowledge; grey box — for internal tests typically an assumed breach with an ordinary user account — gives the most realistic picture in the least time; white box with documentation and access allows the deepest coverage. We recommend the level on the intro call.
Do we need an external or an internal test?
An external test verifies what is reachable from the internet. An internal test verifies what happens after the first foothold — phishing, a compromised laptop, a supplier's access. Organisations with a closed perimeter mostly need the latter; we recommend the scope by where your critical systems sit.
Let's talk it through.
Tell us what you run — address ranges, number of sites, Active Directory, Wi-Fi or OT — and we will propose a scope.
Book a free consultation ›