Offensive & Application Security
Network and infrastructure penetration testing (VAPT)
Manual, authorised testing of internet-facing systems, internal networks, Active Directory and servers, with evidence and a fix for every finding.
Key areas covered
- Engagement
- Fixed scope, agreed and authorised in writing before testing starts
- Approach
- Black-box, grey-box or white-box, chosen with you during scoping
- Access
- External testing remotely; internal testing over a secure connection or on site, as agreed
- Reference standards
- PTES, NIST SP 800-115, CVSS for severity ratings
- You receive
- Executive summary, technical report, debrief call and optional retest
Overview
About network and infrastructure penetration testing (VAPT)
A penetration test is an authorised, simulated attack on your systems. A tester works out which weaknesses can really be exploited and how far an attacker could get. VAPT (vulnerability assessment and penetration testing) pairs broad automated discovery with that manual exploitation step.
This page covers network and infrastructure testing: internet-facing services, internal networks, Active Directory, servers and remote access. Our penetration testing also covers AI and LLM applications, web applications and APIs, mobile apps and IoT and embedded devices, and can be combined with infrastructure testing in one engagement.
A typical starting point
A customer, auditor or regulator has asked for a VAPT report, or you want to know how far an attacker could get into your network.
The security problem
What attackers look for in your network
Exposed and outdated services
Internet-facing systems running unpatched software or unnecessary services are the most common way in.
Weak credentials and password reuse
Default, guessable or reused passwords let attackers log in instead of breaking in.
Active Directory attack paths
Misconfigured permissions and delegation can let an ordinary user account become a domain administrator.
Flat internal networks
Without segmentation, one compromised laptop can reach servers, backups and critical systems.
What’s covered
What an infrastructure penetration test covers
Area 01
External infrastructure
- Internet-facing IP ranges, hosts and exposed services such as VPN, mail, RDP, SSH, FTP and web servers
- TLS configuration and certificate handling
- DNS records and subdomain exposure
- Perimeter filtering and firewall rule effectiveness
- Known vulnerabilities in exposed software and appliances
Area 02
Internal network and Active Directory
- Segmentation between user, server and sensitive network zones
- Active Directory configuration, including Kerberos and NTLM weaknesses, delegation and privileged group membership
- Credential exposure, password policy and password reuse
- Unpatched and end-of-life systems
- Privilege escalation and lateral movement paths towards agreed targets
Area 03
Remote access and wireless
- VPN gateway configuration and authentication strength
- Remote desktop and third-party remote-support access
- Wireless network security and guest isolation (on site, by arrangement)
Area 04
Hosts and builds
- Configuration review of representative server and workstation builds
- Local administrator rights, unnecessary services and weak permissions
- Endpoint security controls and whether they can be bypassed
Our approach
How a network penetration test is carried out
Step 1: Scoping and authorisation
We agree targets, testing windows, approach, contacts and rules of engagement. You sign a written authorisation before any testing begins.
Step 2: Reconnaissance and discovery
We map the agreed scope: live hosts, open ports, running services and versions, using automated tools and manual enumeration.
Step 3: Vulnerability analysis
We identify candidate weaknesses from scanning, configuration review and manual investigation, and rule out false positives.
Step 4: Controlled exploitation
We attempt to exploit confirmed weaknesses within the rules of engagement to prove real impact. Denial-of-service techniques are excluded unless you explicitly request them.
Step 5: Post-exploitation
Where it is in scope, we test how far access can be extended (privilege escalation, lateral movement, access to sensitive data) and stop at the objectives agreed with you.
Step 6: Reporting and debrief
Every finding is documented with evidence, a severity rating and remediation steps. We then walk your team through the results.
Step 7: Retesting (optional)
After you have applied fixes, we retest the affected findings and issue an updated report showing what has been resolved.
Standards and references we work to
- PTES
- Penetration Testing Execution Standard: the structure of the engagement, from pre-engagement to reporting.
- NIST SP 800-115
- NIST’s technical guide to information security testing and assessment.
- CVSS
- FIRST’s Common Vulnerability Scoring System, used to rate the severity of each finding consistently.
- CIS Benchmarks
- Reference configurations used when reporting operating system and device hardening findings.
- MITRE ATT&CK
- Used to describe the attacker techniques demonstrated during internal testing.
What you receive
What you receive from a penetration test
Executive summary
A plain-language overview of overall risk, the most significant issues and recommended priorities, for leadership and non-technical stakeholders.
Technical findings
For each issue: a description, affected systems, CVSS severity, step-by-step evidence, business impact and specific remediation guidance.
Scope and methodology statement
Exactly what was tested, when, from where and with what level of access, so the report holds up to customer and auditor review.
Remediation priorities
A short, ordered list of fixes so your team knows where to start and what can wait.
Debrief call
A session with your technical team to go through findings, answer questions and agree next steps.
Retest report
If retesting is in scope, an updated report confirming which findings have been fixed.
Sample finding
Domain administrator access from a standard user account
Internal Active Directory (CORP), service account svc_sqlbackup
MITRE ATT&CK T1558.003 Kerberoasting; CIS Controls v8 Control 5
- What we found
- A service account with a weak password and domain administrator rights could be cracked offline by any domain user.
- Evidence
- Using a standard test account, we requested a Kerberos service ticket for svc_sqlbackup, recovered its password offline and authenticated as a domain administrator. Commands and screenshots attached.
- Business impact
- An attacker who compromises any staff laptop could take over every server and account in the domain, and deploy ransomware network-wide.
- Fix
- Replace the account with a group managed service account (gMSA), remove domain administrator rights, enforce long random passwords on remaining service accounts and alert on Kerberoasting activity.
- Status
- OpenFixed, verified at retest
Good to know
A vulnerability scan is not a penetration test
An automated scan lists potential vulnerabilities based on software versions and signatures. It is fast and inexpensive, but it produces false positives and cannot show whether weaknesses can be chained together into a real compromise.
A penetration test adds a skilled tester who verifies, exploits and explains each issue. If a scan is all you need, we will tell you. Read more in our guide to vulnerability scanning vs penetration testing.
Good to know
A penetration test does not make you compliant
A VAPT report is evidence that testing was carried out and that issues were found and addressed. It supports ISO/IEC 27001, SOC 2, PCI DSS and regulatory requirements, but it does not certify compliance on its own.
Before we start
What we need before testing starts
- A named technical contact, and an escalation contact who is reachable during testing windows.
- The in-scope IP addresses, hostnames or network ranges, and confirmation that you own them or are authorised to have them tested, including anything hosted by a third party.
- A signed authorisation and agreed rules of engagement.
- For internal testing: a way to connect (VPN account, jump host or a network port on site) and, for grey-box tests, a standard user account.
- A decision on whether your hosting provider, managed security provider or internal SOC should be told about the test in advance.
- Recent backups of critical systems, as a normal precaution.
Not sure you have everything?
We confirm exactly what network penetration testing needs from your side during the scoping call, before any work is agreed.
Book a scoping callFAQ
Questions about network penetration testing
Still have a question?
Ask about scope, timing or cost for network penetration testing, even if you are not ready to commission work yet.
Contact our teamWhat is the difference between VAPT and penetration testing?
VAPT stands for vulnerability assessment and penetration testing. The vulnerability assessment finds and lists potential weaknesses, largely with automated tools. The penetration test then manually verifies and exploits them to show real impact. In India, “VAPT” is the term most often used in contracts and audit requests; in practice it describes a penetration test that includes a vulnerability assessment.
How long does a penetration test take?
It depends on scope. An external test of a small number of internet-facing IP addresses can take a few days. An internal network and Active Directory test for a larger organisation can take one to three weeks including reporting. We give you a fixed estimate once the scope is confirmed.
Will testing disrupt our systems?
Penetration testing carries a small risk, which we manage carefully. We agree testing windows with you, exclude denial-of-service techniques unless you request them, and stop and contact you if a system becomes unstable. Exploits that could affect availability are discussed with you before they are attempted.
Should we choose a black-box, grey-box or white-box test?
In a black-box test the tester starts with no information, like an outside attacker. Grey-box testing provides some information or a standard user account. White-box testing provides full documentation and access. Grey-box usually gives the best value: it reflects a realistic attacker (for example, one who has phished an employee) without spending paid time on discovery your team could simply tell us.
How often should we have a penetration test?
At least once a year, and after any significant change to your network or systems. Some standards set this explicitly. PCI DSS, for example, requires internal and external penetration testing at least every 12 months and after significant changes.
Is penetration testing the same as red teaming?
No. A penetration test aims to find as many exploitable weaknesses as possible within a defined scope. A red team exercise is a longer, objective-based simulation that tests whether your people and detection tools notice and respond to an attack. Most organisations should run regular penetration tests before considering a red team exercise.
Can you test systems hosted by a third party or in the cloud?
Usually, yes, but the provider’s rules apply. AWS, Microsoft Azure and Google Cloud allow customers to test their own resources within their published policies, for most services without prior approval. Shared hosting and SaaS providers often do not allow testing. We confirm what is permitted before testing begins.
Will you sign a non-disclosure agreement?
Yes. We can sign a mutual NDA before you share details of your environment. Findings and evidence are handled confidentially, and how long we keep them is agreed in the engagement terms.
Related services
Often combined with network penetration testing
Talk to us about network penetration testing
Tell us what has prompted the conversation. We will reply to arrange a short, no-obligation scoping call for network penetration testing.