Infrastructure Pentest (NETWORK VAPT)

The difference between an external and an internal infrastructure pentest is the position the test starts from, and therefore the question it answers.

External

An external infrastructure pentest looks at what an attacker on the internet can reach and do. It is largely about attack surface you did not know you had: forgotten hosts, a management interface exposed during a migration, and credentials that still work on something nobody owns any more.

Internal

An internal infrastructure pentest looks at what somebody who already holds a position inside your network can reach from it. It measures blast radius. Almost every estate turns out flatter than its diagram, and the distance from one workstation to domain rights is shorter than anyone expects.

They answer different questions and neither substitutes for the other. If you have never tested, buy the external engagement first, because unknown exposure is the more urgent risk. Buy the internal one shortly after, because it determines how bad an incident becomes and almost nobody has visibility into it.

An internal infrastructure pentest needs a position that you grant, and an external infrastructure pentest needs no credentials at all.

External

No credentials. Starting with nothing but your address ranges is the point of it, because that is the position an internet attacker holds. Supplying accounts would turn it into a different test.

Internal

A standard user account on a managed laptop is the usual starting point. Earning that position covertly is a Red Team engagement, which is a different service at a different price.

Segmentation

For the segmentation question you may want positions in more than one segment, for example one in the corporate network and one in a restricted or management segment. A boundary is only proved to hold once we have tried to cross it from the far side.

An infrastructure pentest typically takes one to two weeks for the external engagement and two to three weeks for the internal, with reporting included.

External duration depends on the address ranges in scope. Internal duration is driven by host count and directory complexity, not by subnet size, because the time goes into Active Directory paths and proving segmentation rather than into sweeping addresses.

Gathering information is the phase clients most often want to shorten, and the one we protect. A test run against an incomplete asset list is a test of the wrong thing.

Yes, an infrastructure pentest from RedTeam Security assesses Active Directory in depth rather than scanning it.

Delegation, ACL abuse, group nesting, service account exposure and AD CS certificate template misconfiguration, including the ESC classes, are assessed and chained into complete paths. A list of individual misconfigurations without the path between them is not actionable, so the paths are what you get in the report.

Credential hygiene is part of the same work: reuse across tiers, cached credentials, and whether one host's local administrator password is every host's. The report shows the path from that first account to whatever it reaches, not a list of settings to flip.

An infrastructure pentest should not disrupt production, and the rules of engagement are written to make sure it does not.

No production change is made without written agreement. Denial of service techniques are excluded by default, and where a finding could only be proved by degrading a service we describe it rather than trigger it.

Before work starts the rules of engagement fix testing hours and an open deconfliction channel, so your team can reach us at any time and pause a test. Where the work needs to run outside business hours, that is agreed at scoping rather than discovered on the night.

Yes, an infrastructure pentest covers cloud and hybrid infrastructure as part of the same engagement where the estate spans both.

Identity federation between the on-premises directory and the cloud tenancy is a frequent source of findings, precisely because it belongs to neither team. A synchronised account or a trust that nobody reviewed can turn an internal foothold into cloud access, or the reverse.

Where the cloud estate is the whole estate, tell us at scoping. The test is then an identity and configuration review rather than a network one, and the scope should say so.

An infrastructure pentest is usually black box for the external engagement and grey box for the internal, and you choose once we have explained the trade.

Black box

We start with nothing but the name of the target, the way a real attacker does. Highest realism, lowest coverage. External testing is genuinely black box, because that is the attacker's position.

Grey box

We start with the access a legitimate user would have. This is the honest default for internal testing, from a standard user account, since a black box internal test spends its budget rediscovering the network instead of testing what it permits.

White box

Full access to documentation, configuration and firewall rules. Highest coverage, lowest realism, and the right choice when the question is completeness, for example whether a segmentation design holds everywhere and not only where we happened to look.

The difference between an infrastructure pentest and a vulnerability scan is that a scan lists what might be wrong and a pentest proves what an attacker can do with it.

A scanner reports on signatures and version strings. It cannot chain a medium on one host with a medium on another into a path to cardholder data, and it cannot tell you whether a boundary holds when somebody tries to cross it. We use automated tooling for coverage, then hands-on analysis of everything it surfaced and everything it cannot reason about.

Nothing in our report rests on tool output alone. If we say something is exploitable, we exploited it, and the report contains the steps you can follow to see it yourself. Keep scanning between tests, because it is cheap and continuous, and use the pentest to learn what the scan cannot show.

An infrastructure pentest at RedTeam Security follows the same six phases on every engagement: gathering information, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting.

The structure follows PTES and NIST SP 800-115, and findings are mapped to MITRE ATT&CK so a technique in the report has the same name as one in your detection rules. Running the same phases each time means two reports a year apart are comparable, which is what a regulator reading them wants.

Threat modelling comes before any tooling runs, so the effort goes where the risk is instead of evenly across a checklist. Post exploitation is where two mediums that together reach something sensitive stop being two mediums.

The deliverables of an infrastructure pentest are a report, a retest once fixes land, and an attestation of what was tested and found.

The report carries an executive summary, technical findings with severity, evidence, reproduction steps and named owners, and a remediation order that reflects real risk rather than raw CVSS. Anything chained comes with an attack path graph, and every technique is mapped to MITRE ATT&CK so the report sits alongside the rest of your risk reporting.

The retest is quoted up front, so it is not a surprise. What you receive at the end is an attestation, not a certificate, because nobody can certify a network as secure and an examiner knows that.

An infrastructure pentest evidences the independent testing obligations under CBUAE, the UAE IAS and the DESC ISR, which are the three regimes this service most often serves.

CBUAE

Licensed banks, payment institutions and stored-value facilities are required to run independent periodic security testing with findings tracked to closure. The engagement produces the scope rationale, findings, owners and retest evidence an examiner asks for.

UAE IAS

Federal entities and critical national infrastructure operators evidence several IAS control families through testing rather than documentation. The IAS was published by NESA, now SIA, so a tender that says NESA means the IAS.

DESC

Dubai government entities and their suppliers must test proportionately to the classification of the information handled under the ISR. Supplier connections are explicitly in scope, which is the part most organisations forget to include.

An infrastructure pentest should be repeated annually as a baseline, and sooner after any change that moves the boundary: a new site, a merger, a migration, or a change to the directory or the perimeter.

The regulators above say periodic rather than naming a frequency, so the cadence is yours to justify, and an annual test with a retest in between is the one most organisations settle on. If budget only covers one engagement a year, alternate external and internal rather than repeating the external test each time.

Between tests, keep scanning. A scan tells you when something new is exposed, and the next pentest tells you what it is worth to an attacker.