Overview
External testing enumerates the full perimeter, every address in the ranges, every service on every port, every certificate and every hostname that resolves, then tests what is exposed: unpatched services, default and reused credentials, exposed management interfaces, and applications nobody remembers deploying.
Internal testing begins from an assumed breach. From a standard domain user on a standard workstation, the engagement follows the same path an operator would: credential harvesting, Kerberos abuse, delegation misconfiguration, certificate services, share enumeration and lateral movement until either domain administrator is reached or every path has been closed off and documented.
Engagement at a glance
- Scope types
- External perimeter, internal network, or both
- Typical duration
- 5 to 15 working days depending on host and subnet count
- Internal access
- Delivered by VPN, a jump host, or shipped hardware implant
- Standards
- PTES, NIST SP 800-115, MITRE ATT&CK
- Assumed breach
- Internal testing starts from a standard domain user, mirroring a real phishing outcome
- Deliverable
- Attack path diagram from entry point to highest privilege obtained
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- Full port and service enumeration across in-scope ranges
- Vulnerability identification and manual exploitation
- Default, weak and reused credentials
- Exposed management interfaces and remote access services
- Active Directory enumeration and attack paths
- Kerberoasting, AS-REP roasting and delegation abuse
- Active Directory Certificate Services misconfiguration
- SMB, LDAP and NTLM relay conditions
- Credential harvesting and reuse across hosts
- Lateral movement and privilege escalation to domain admin
- Network segmentation validation
- Legacy protocol and configuration exposure
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Perimeter exposure | Every port on every in-scope address, service fingerprinted and version-matched to known exploits | Direct external compromise of an internet-facing host |
| Credential hygiene | Default credentials, password reuse across services, spraying within agreed lockout limits | Authenticated access without exploiting anything |
| Active Directory | Kerberoastable accounts, AS-REP roasting, unconstrained and constrained delegation, ACL abuse paths | Standard user to domain administrator |
| Certificate services | Template permissions, enrolment agent rights, subject alternative name abuse | Certificate-based impersonation of any user including administrators |
| Relay conditions | SMB signing, LDAP channel binding, NTLM relay paths between hosts | Authentication coerced from one host and replayed at another |
| Segmentation | Reachability tested between every pair of in-scope zones, including out-of-band paths | Flat network where the diagram shows isolation |
What we commonly find
A service account with a 2019 password and a service principal name
Requestable by any domain user, crackable offline, and frequently over-privileged.
SMB signing not enforced
One of the oldest findings in the industry and still one of the fastest routes to lateral movement.
Certificate template misconfiguration
Enrolment rights that let a standard user request a certificate naming someone else, authentication as any account, resistant to password resets.
Segmentation that exists on the diagram
The guest network reaching the server VLAN through a route nobody documented.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- Annually for any organisation with on-premises infrastructure or an Active Directory domain.
- Before or after a PCI DSS assessment, which requires both internal and external testing.
- After a merger, an office move or a significant network change.
- Following an incident, to confirm the path used is closed.
Questions
Do you need to be on site?
Rarely. Internal testing is normally delivered over VPN, through a jump host, or via a small device shipped to the office and plugged into the network. On-site presence is available where a physical or wireless component is in scope.
Will you disrupt production systems?
Denial-of-service and resource-exhaustion techniques are excluded by default. Exploits with a known stability risk are flagged during scoping and run only with approval, at an agreed time. Password spraying is rate-limited below your lockout threshold, confirmed against your actual policy before it starts.
What is an assumed-breach test?
Testing starts from a standard domain user account rather than spending days on initial access. Phishing succeeds eventually against any organisation; the useful question is what happens next. This produces more actionable findings than proving that an email can be delivered.
How do you validate segmentation?
Reachability is tested between every pair of in-scope zones. Each expected-blocked path is attempted and the result recorded, so the report states which controls held rather than asserting the design is correct.
How much does a network penetration test cost?
Scope is driven by the number of live hosts, the size of the IP ranges, and whether internal, external or both are in scope. A fixed quote follows a short scoping call. External testing is usually priced by range; internal by host count and site count.
How often should we run a network penetration test?
Annually as a baseline, and after any significant change to the estate. Organisations under PCI DSS test at least annually and after significant change by requirement; those under ISO 27001 or SOC 2 usually settle on the same cadence because it is what auditors accept.
Do you test Active Directory specifically?
Yes, and on internal engagements it is usually where the path runs. Coverage includes Kerberos attack paths, delegation misconfiguration, credential exposure in shares and scripts, ACL abuse, and the route from a standard domain user to domain administrator, which is the question the report has to answer.
What is the difference between a vulnerability assessment and a network penetration test?
A vulnerability assessment enumerates what might be wrong. A penetration test proves what an attacker can do with it, chains findings together, and stops at demonstrated impact rather than at a severity score. Most products sold as penetration tests in this market are the first with a different cover page.
Can you test wireless networks?
Yes, as part of on-site internal scope. Coverage includes authentication method weaknesses, guest and corporate network separation, rogue access point resilience, and whether a device on the wireless network reaches anything a device on the wired network reaches.