Infrastructure penetration testing

The external test simulates an attacker on the internet who knows nothing about you and starts from your domain. The internal test simulates an attacker who is already inside, typically through an employee who opened an attachment. The external test answers how hard it is to get in. The internal test answers what happens next, and that answer is the less pleasant one.

Both tests make sense, but not at the same time. If you’ve never tested, start with the external perimeter: it’s cheaper and the findings get fixed faster. The internal test makes sense right after, because it’s the one that shows if a single compromised workstation stops at one computer or ends at Domain Admin. If you’d rather go through the configurations first and clean them up together, and only then try an attack, that is what a review and remediation of configurations before the test is for.

The internal test doesn’t require us to come on site. A virtual machine on the network is enough, or a laptop you plug into a socket in the office and give us remote access to. Where the workstation sits is part of scoping: a position on the office network paints one picture, a position in the server segment another.

This way of setting up the brief is known in the industry as assume breach: we skip the break-in from outside and start directly inside, as if the attacker were already in. You pick the starting point by the scenario you want checked, either a compromised workstation or an ordinary domain account with no special privileges that you hand to us. What assume breach means exactly is spelled out in a separate glossary entry.

Phishing isn’t the only way into the internal network. Wi-Fi as another path into the internal network gives an attacker near the building the same starting position as a compromised workstation, just without anyone clicking an attachment.

We start with an inventory, not a scan. From public sources we compile a list of domains, subdomains, IP ranges, and certificates and compare it with what you consider yours. The difference between those two lists is the most valuable output of the first phase. Every item left on it we then verify separately: a forgotten test instance, an old VPN, a printer with a public IP.

Then come service mapping and manual verification. The scanner reports a vulnerable version; the tester checks if it’s actually exploitable in this configuration, and only then does it go into the report. This step removes the findings that would otherwise tie up your administrators for nothing.

Two spots on the perimeter we check every time: a management interface exposed to the internet without a source address restriction, and accounts without multi-factor authentication on remote access. Both get fixed in a matter of hours and close the shortest path in. The applications running on that perimeter are tested separately, because their flaws are in the code, not in the network configuration.

Active Directory (AD) is the directory service that holds the accounts, computers, and privileges of the whole company. Once an attacker controls it, they control everything else. That’s why the internal test goes after it and looks for the paths that lead from an ordinary user account to Domain Admin.

Specifically: Kerberoasting (MITRE ATT&CK T1558.003), pulling a hash from a service account and cracking it offline. Exploitable certificate templates in AD CS, where the requester chooses whom the certificate is issued to (the scenario labeled ESC1). Passwords forgotten in scripts and on file shares every employee can read. Excessive privileges delegated years ago to a colleague who no longer works there.

We describe these paths in detail in our article on five paths to Domain Admin, including how each one gets closed. What the test adds is that we verify which of them work in your environment and in what order they’re worth fixing.

Three variables: the number of live IP addresses in the range, the number of sites, and the number of domains in Active Directory. Not the number of employees; that has nothing to do with the work involved. A hundred addresses on one flat network is less work than thirty addresses in three separate segments, each with its own rules.

The external perimeter usually takes one to two weeks, an internal network with one domain two to three. We break down how the price of a network test is calculated on the pricing page, including what raises the effort and what doesn’t.

Cloud accounts aren’t part of this scope. We test permissions and roles in AWS as a separate service, because they’re calculated from different variables and the provider’s own rules apply.

The industrial layer isn’t part of it either: we test industrial systems separately, because OT and ICS (industrial control systems) in a running plant are checked carefully and with different techniques than a wired IT network.

CVE-2026-39042 is a finding by our team, reported to the vendor through responsible disclosure and since then kept as a public record under its own number: an integer overflow in the core IPC library of MikroTik RouterOS, specifically in the unflatten() function in libumsg.so. It lets an unauthenticated remote attacker crash the service, that is, cause a denial of service, and the record in the National Vulnerability Database (NVD) dated July 13, 2026 rates it CVSS 7.5 (High). It affects versions 7.21.x before 7.21.4 and 7.22.x before 7.22.2. We mention it because on a network device a scanner on its own sees only the firmware version. A flaw of this kind is found only where someone reads what the protocol does with its input.

The classification of findings by CVSS and the shared test process and report format are described on the penetration testing page. Here only the target and the techniques differ.