Infrastructure Penetration Testing: Internal and External

An infrastructure penetration test is an offensive audit against the network, systems, identities and services of your organisation. The external side simulates an attacker who only knows the public domain and starts by enumerating what is exposed to the internet. The internal side starts from a different scenario: an attacker is already inside (an endpoint compromised by phishing, a visitor on the corporate wifi, a disgruntled employee) and measures how far they can go before getting detected. The two measure different things and, in mid-sized organisations, both are needed at least once a year.

This guide covers what gets audited in external and internal infrastructure pentests, why Active Directory is the backbone of internal work, the findings that show up in 80% of projects, the methodology a serious team applies and how it fits NIS2, DORA, ENS, ISO 27001 and PCI DSS.

What an infrastructure pentest is

An infrastructure pentest is an authorised and scoped offensive exercise against the systems, networks and identities of the organisation: physical and virtual servers, network devices (firewalls, switches, routers), Active Directory or Entra ID, VPNs, segmentation, exposed services and the legitimate flows between all of them.

Unlike a web pentest, which focuses on an HTTP application and its logic, an infrastructure pentest looks at the operating system and the identity layer. What gets audited:

• Exposed services and their configurations (SSH, RDP, SMB, LDAP, Kerberos, databases, admin panels).
• Identities: user accounts, service accounts, permissions, groups, GPOs, ACLs, delegations.
• Network segmentation between VLANs, between environments (production, pre-production, office), between DMZ and backend.
• Patching and hardening of operating systems, hypervisors and network devices.
• Defensive telemetry: whether EDR, SIEM and honeypots detect the offensive team's movements.

Infrastructure pentesting is the closest scenario to a real incident, because most ransomware and APT activity attacks identity and network, not isolated web applications.

Why run an infrastructure pentest

Three operational reasons any security team already accepts:

1. Most incidents move through infrastructure, not web. Initial access may come from an email or an exposed service, but from there the attacker moves laterally in Active Directory, escalates privileges and reaches a domain controller. The web audit doesn't touch any of that.
2. Active Directory accumulates silent debt. GPOs created 10 years ago, service accounts with excessive privileges, forgotten Kerberos delegations, inherited misconfigured ACLs. Without periodic external audit, that debt isn't visible until an attacker exploits it.
3. NIS2, DORA, ENS, PCI DSS and ISO 27001 explicitly cover infrastructure. NIS2 article 21 demands effectiveness testing of technical measures. PCI DSS req. 11.4 mandates annual internal and external pentest. The ENS (Spanish Royal Decree 311/2022) requires it under the Operational Framework for medium and high category systems.

Done well, an infrastructure pentest delivers:

• Real inventory of exposed services and the internal network from the attacker's perspective (often with more detail than the client's CMDB).
• Reproducible attack chains: from initial access to domain controller, step by step.
• Evaluation of real segmentation, not the one in the Visio diagram.
• Recommendations prioritised by blast radius and effort, not by isolated CVSS severity.
• Auditable evidence for NIS2, DORA, ENS, ISO 27001 auditors or PCI DSS QSAs.

External pentest: the perimeter audit

The external pentest simulates an attacker who only has the domain name or the public range. What it covers:

• OSINT reconnaissance. Forgotten subdomains (Certificate Transparency, archive.org, GitHub leaks), exposed IPs, orphan DNS entries, accessible services the team no longer remembers leaving online. More in what is OSINT.
• Service enumeration. Full Nmap, version identification, fingerprinting. Mapping of banners, headers and responses.
• Audit of exposed configurations. VPN without MFA or with a known CVE (Fortinet, Citrix, SonicWall, Ivanti have made headlines repeatedly), on-prem Exchange without patches, public admin panels, anonymous FTP, SMB on the internet, open RDP, Kibana/Elasticsearch without auth.
• TLS and certificate audit. Obsolete versions, certificates close to expiry, weak ciphers, certificate transparency exposure without protection.
• Detection of external leaks. Credentials on pastebins, public repositories with secrets, open S3 buckets, public Trello/Notion, corporate GitHub repositories with tokens.
• Technical phishing (when scope includes it). SPF, DKIM, DMARC validation, spoofing capability of the corporate domain.

The team doesn't enter anything not authorised, but goes far enough to demonstrate access (screenshots, raw requests, evidence of vulnerable version). The client decides whether to authorise exploitation of each finding or to settle for the evidence.

Internal pentest: the audit from inside

The internal pentest starts from the assumption that the attacker is already on the network. The initial scenario varies:

• Assumed breach: a corporate endpoint handed to the offensive team, simulating successful phishing.
• Malicious employee: with their legitimate credentials and permission profile.
• Visitor on corporate wifi: a network with restricted internet access but with some internal reach.
• Partner VPN connection: simulating a provider with limited access.

From that point, the team tries to do what a real attacker would do:

• Internal network reconnaissance. Scanning, identification of critical servers, domain controllers, jump hosts, NAS, backup servers, hypervisors. The prior external OSINT phase is typically consolidated with Maltego for traceability of the investigated asset.
• Active Directory enumeration. BloodHound, ldapdomaindump, PowerView. Reveals the network of relationships, identifies privileged users, service accounts with SPN, machines with unsafe delegation, editable GPOs.
• Credential capture. LLMNR/NBT-NS poisoning with Responder, mitm6 against IPv6, NTLM relay, kerberoasting, ASREProasting. They produce hashes attempted to crack offline.
• Lateral movement. Pass-the-hash, pass-the-ticket, SeImpersonate abuse, PrintNightmare abuse on unpatched systems, RCE via SMB on legacy systems.
• Escalation to Domain Admin or equivalent. DCSync, Golden Ticket, Kerberos delegation abuse, ACL hijacking on privileged groups, PetitPotam against misconfigured ADCS.
• Persistence. Silent backdoors: skeleton key, ACL modification, AdminSDHolder, Kerberos delegation.
• Detection testing. Every action is documented so the client can verify afterwards what EDR, SIEM and SOC detected.

External vs internal: when each fits

The two audits measure different things. Sensible decision:

• External: annually and after any significant perimeter change (new load balancer, VPN deployment, exposure of a new service). The test that catches what an attacker sees before having a foothold.
• Internal: annually for companies with a large Active Directory or under compliance (NIS2, DORA, medium or high ENS, PCI DSS). After incidents or structural changes (domain consolidation, migration to Entra ID, merger).
• Combined: when budget allows, the most useful approach is to run both in the same project with a team sharing cross findings. What gets exposed at the perimeter sometimes explains how the breach happened in a real intrusion.

For small companies or limited surface, an annual external + biennial internal is a reasonable cadence. Those under essential NIS2, DORA or PCI DSS need both every year.

Active Directory: the heart of internal pentesting

More than 80% of critical findings in internal pentests appear in Active Directory. The full family of Kerberos attacks against AD (Kerberoasting, AS-REP Roasting, Pass-the-Ticket, Silver and Golden Ticket, delegation abuse, DCSync) has its own technical guide. The categories that show up in virtually every project:

• Kerberoasting. Service accounts with registered SPN and weak password. Any domain user can request the ticket, extract the hash and crack it offline. Defence: long passwords (25+ characters) and rotated, gMSA where possible.
• ASREProasting. Accounts with Kerberos pre-authentication disabled (DONT_REQ_PREAUTH). Allows extracting the hash without being authenticated to the domain. Defence: review and remove the flag except in justified cases.
• Unsafe Kerberos delegations. Unconstrained delegation (the most dangerous, allows impersonating any user that connects) and misconfigured constrained delegation. Defence: minimise unconstrained, audit resource-based constrained delegation and use Protected Users group for critical accounts.
• Abusable DCSync. Non-privileged accounts or groups with Replicating Directory Changes permissions that allow replicating the full credential database. Defence: review ACLs on the domain object, only Domain Controllers and justified accounts.
• AdminSDHolder and SDProp. Modifications in AdminSDHolder propagate every hour to privileged accounts. A textbook silent backdoor. Defence: SACL monitoring and periodic review.
• GPOs editable by non-privileged users. Inherited ACLs that allow editing a GPO applied to critical machines. Defence: review permissions over GPOs and centralise administration.
• PetitPotam and NTLM relay to ADCS. Force authentication from a domain controller and relay it against the Active Directory Certificate Services role to mint admin certificates. Defence: disable NTLM against ADCS, enable EPA, patch MS-EFSRPC.
• LAPS missing or poorly applied. Same local admin password on every machine, stealable from one and reusable on all. Defence: LAPS deployed with effective rotation.
• Privileged accounts with active session on workstations. Domain admin signed in on a workstation (or the IT laptop). Any compromise of the workstation hands over the account. Defence: strict account tiering, dedicated administrative machines (PAW).

BloodHound remains the go-to tool for visualising most of these relationships in hours.

Typical findings in external infrastructure

Five recurring patterns:

• Unpatched VPN or network appliance. Critical CVE published and not yet applied. Mass campaigns usually exploit it within hours of publication.
• Forgotten exposed services. Old subdomain pointing to an IP with an admin panel the team no longer remembers.
• Credentials in public repositories. GitHub, GitLab, Docker Hub. Service tokens, AWS keys, API secrets.
• Spoofing of the corporate domain. Loose SPF, DMARC at p=none, missing DKIM. Allows sending emails as @company.com to employees.
• Public S3 buckets or equivalent with sensitive data. Shows up in audits more via OSINT than active pentest, but among the most frequent findings.

Methodology of a serious infrastructure pentest

What we apply at Secra and what any professional team follows (aligned with PTES and NIST 800-115):

1. Technical onboarding. Scope agreement, IPs, VPN if applicable, testing window, technical emergency contact, written authorisation of tests.
2. Passive and active reconnaissance. OSINT, service enumeration, surface mapping. Without touching anything.
3. Vulnerability identification. Configuration analysis, version comparison against CVE databases, analysis of anomalous responses.
4. Controlled exploitation. Each exploitation with explicit authorisation in scope. Documentation of every step, evidence capture, without causing denial of service.
5. Post-exploitation. Lateral movement, escalation, evidence capture. In authorised environment.
6. Cleanup. Every persistence, tool and file created by the team is removed at the end. Detailed inventory for validation.
7. Reporting. Executive report separated from the technical one. Each finding with description, proof of concept, justified CVSS severity and recommendation.
8. Debrief and retest. Technical meeting with the client team, retest of each finding once the fixes are ready.

Infrastructure pentesting and compliance

• NIS2 (article 21). Demonstrated effectiveness of technical measures. The infrastructure pentest covers most controls in Annex I (incident management, network security, cryptography, access control). More in NIS2 in Spain: a compliance guide for 2026.
• DORA (articles 24-26). Annual operational resilience testing. For significant entities, TLPT under TIBER-EU every three years, combining intelligence, external and internal under realistic scenarios. More in DORA compliance guide for financial entities 2026.
• ENS (Spanish Royal Decree 311/2022, Operational Framework MP-OP). Regular technical audit for medium and high category systems. Minimum biennial in high, annual in some cases.
• PCI DSS v4.0 (req. 11.4). Annual internal and external pentest + after any significant CDE change. "Industry-accepted" methodology required (PTES, OWASP, NIST 800-115).
• ISO 27001:2022 (control 8.29). Documented security testing in the ISMS. The audit with methodology, findings, fixes and retest directly covers the control.

How to choose the right scope

Three questions that help dimension:

• How many active external IPs do we have? External scales with exposed surface. A company with 5 IPs and one domain gets covered in 3-5 days; one with 50 IPs and extensive subdomains can ask for 10-15.
• How many users and machines does the internal domain have? A domain with 200 machines and 50 servers gets audited in 5-7 days; one with several thousand machines and a forest architecture asks for 15-25 days.
• Is there specific compliance? PCI DSS demands focus, evidence and methodology signature that some providers don't apply by default. More on pricing in penetration testing pricing in Spain.

Frequently asked questions

What's the difference between internal and external pentesting?

The external simulates an attacker who only knows the public domain; it audits what is exposed to the internet (services, configurations, leaks, certificates, patches, spoofing). The internal starts from an attacker already inside the network and measures how far they reach: Active Directory, segmentation, escalation, lateral movement. They are complementary audits: a mature company runs both.

How long does an infrastructure pentest take?

Varies with size. An external against a small surface (10-20 IPs, one domain): 3-5 days. A large external with several subdomains and appliances: 7-12 days. An internal against a mid-sized Active Directory: 5-10 days. Against a domain with thousands of machines and complex forest: 15-25 days. A combined external plus internal project against a mid-sized AD usually closes in 3 weeks.

Is there a risk that pentesting causes denial of service?

Well planned, almost never. Tests that can affect availability (heavy fuzzing, attacks against load balancers, exploits with probability of bringing down the service) are agreed in scope and run in windows outside critical hours. The professional team documents every action and aborts if it detects instability. Real incidence is statistically very low in well-onboarded projects.

Is a scanner enough or do you need a manual pentest?

The scanner (Nessus, OpenVAS, Qualys) is complementary, not a substitute. It detects known CVEs and misconfigurations but doesn't find chains or Active Directory or delegation logic problems. The manual pentest is what uncovers the chain of Kerberoasting + missing LAPS + unsafe delegation that ends in Domain Admin. Auditing only with a scanner leaves 70% of the real risk out.

Do I need internal pentesting if I already have EDR and SIEM well deployed?

Yes, they are different things. EDR and SIEM detect the attacker while they act; the pentest reveals how easy it is for the attacker to move and, secondarily, what those platforms detect or miss. Many projects discover that EDR doesn't cover all servers or that SIEM rules don't include kerberoasting. The audit is what validates real coverage.

What if I've never run an internal pentest and I'm afraid of what we'll find?

It's the usual story the first time: critical findings in Active Directory that have been around for years. The professional way to manage it is to agree up front that the first pentest is treated as a baseline diagnosis, plan 2-3 consecutive cycles to close the debt and use the report to secure internal budget. The first report is always the heaviest; the next ones show measurable progress.

Related resources

• What is a penetration test: the pillar of the cluster, with types, methodologies and recommended frequency.
• Web application penetration testing: the sibling audit on HTTP frontends, complementary to the infrastructure perimeter.
• API penetration testing: REST and GraphQL: the backend audit exposed via web and mobile.
• Cloud penetration testing (AWS, Azure, GCP): the equivalent discipline when infrastructure is in cloud and the perimeter is defined by IAM and policies, not IPs.
• Kerberos attacks in Active Directory: the full technical guide to the family of techniques that produces most internal findings.
• What is a WAF: the control that filters HTTP at application level when the rest of the perimeter is already covered.

Infrastructure pentesting at Secra

At Secra we cover external and internal pentesting with PTES and NIST 800-115 methodology, profiles specialised in Active Directory and Kerberos enumeration, reproducible evidence, mapping to NIS2, DORA, ENS, ISO 27001 and PCI DSS as applicable, and included retest. If your organisation has a large Active Directory, is under compliance or has never run an internal pentest, get in touch through contact or check our infrastructure audit service.