VAPT

VAPT of Networks

External network testing answers what the internet can reach. Internal testing answers the more important question: what happens after one laptop is compromised. Most organisations have a hardened perimeter and a flat interior, so the difference between the two results is usually the finding that matters.

Methodology

01
Scoping and rules of engagement
Address ranges, excluded hosts, testing windows, escalation contacts and the conditions under which testing stops. Agreed in writing before anything is sent.
02
Passive reconnaissance
For external scope: DNS, certificate transparency, ASN and IP ranges, exposed services and leaked credentials in public breach corpora. No packets to the target.
03
Discovery and enumeration
Host discovery, port and service enumeration, version fingerprinting and operating system identification across the agreed scope.
04
Vulnerability identification
Authenticated and unauthenticated scanning, correlated against version data and known CVEs. Scanner output is triage input, never a finding.
05
Exploitation
Confirmed issues exploited to establish a foothold, with the blast radius agreed in advance. Denial-of-service conditions are identified but not triggered unless explicitly authorised.
06
Post-exploitation and lateral movement
Credential harvesting, privilege escalation, pivoting and the path towards domain or critical asset compromise, recorded as a narrative rather than a list.
07
Detection assessment
What the client's own monitoring saw, and when. A finding that nothing was detected is often more valuable than the vulnerability that allowed it.
08
Reporting and retest
Technical report, executive summary and attack path narrative, then a retest evidencing closure.

Approach to testing

External and internal are separate engagements with separate objectives, and are reported separately even when run together.
Internal testing assumes breach: the tester starts with a network drop or a standard user account, because 'can an attacker get in' is a less useful question in 2026 than 'what happens when they do'.
Segmentation is tested explicitly — whether a compromised host in one zone can reach another — because flat internal networks are the single most common structural finding.
Destructive and denial-of-service conditions are identified and reported but not exercised, unless a separate written authorisation exists.
Testing is run from a documented source address and logged, so the client can reconcile activity against their own detection and confirm what was and was not CSS.

Types of assessment

External penetration test

Internet-facing ranges only. Answers what an attacker with no access can reach and exploit from outside.

Internal penetration test

From a network drop or standard user account. Answers what a compromised endpoint leads to, which is usually the more serious answer.

Assumed breach

Starts from a foothold provided by the client, so tester time goes to lateral movement and escalation rather than to getting in.

Segmentation validation

Narrow scope confirming that defined zones — cardholder, OT, management — are genuinely isolated. Often a PCI DSS or regulatory requirement.

Frameworks and standards

NIST SP 800-115: The technical testing lifecycle the engagement is structured on.
PTES: Execution standard from intelligence gathering through post-exploitation.
OSSTMM: Measurement of operational security where the client wants a repeatable score between engagements.
MITRE ATT&CK: Techniques used are mapped, so the client's detection team can compare against their own coverage.
CIS Benchmarks: Configuration baseline for hosts and network devices found in scope.
CWE / CVSS v3.1: Classification and severity scoring.

Tools used

Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.

Nmap

Host discovery, port and service enumeration, scripted checks.

Nessus / OpenVAS

Authenticated and unauthenticated vulnerability identification for triage.

Metasploit

Controlled exploitation of confirmed issues where a reliable module exists.

Impacket

SMB, Kerberos and RPC interaction during lateral movement.

Responder / NTLMRelayX

Poisoning and relay testing for legacy name resolution and SMB signing gaps.

CrackMapExec / NetExec

Credential spraying and validation across a host set at scale.

BloodHound

Mapping attack paths once a domain foothold exists.

Wireshark / tcpdump

Traffic analysis, cleartext protocol identification and segmentation verification.

Checklist approach

The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.

Perimeter

Exposed services against business need
Remote access: VPN, RDP, SSH exposure and authentication strength
Management interfaces reachable from the internet
TLS configuration on every published service
Default and weak credentials on exposed devices

Host and service

Missing patches against known exploited CVEs
End-of-life operating systems and appliances
Unnecessary services and open ports
Local privilege escalation paths
Host firewall and endpoint protection presence

Network protocol

LLMNR, NBT-NS and mDNS poisoning exposure
SMB signing enforcement
IPv6 present and unmanaged
Cleartext protocols carrying credentials
VLAN hopping and trunk configuration

Credentials and access

Password spraying resistance and lockout policy
Credentials reused across hosts or tiers
Service accounts with excessive rights
Kerberoastable and AS-REP roastable accounts
Cached credentials on shared hosts

Segmentation and architecture

Zone-to-zone reachability against the documented design
Management network isolation
Guest and BYOD network containment
OT and corporate network separation
Egress filtering and command-and-control paths

Detection

Which testing activity generated an alert, and how quickly
Logging coverage on critical hosts
Detection of credential attacks and lateral movement
Response to an active foothold

How findings are scored

Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.

Critical: Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
High: Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
Medium: Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
Low: Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
Informational: A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.

Scan types selected

Safe Checks
Standard / OWASP Top 10
Destructive
SANS Top 25
Business Logic Vulnerability Testing

Standard toolset by stage

OSINT: Datasploit, Google Dorks, Shodan
Enumeration & Scanning: Nmap, Wfuzz, Unicornscan
Domain Enumeration: Nikto, DnsRecon, Knock
Crawling & Fuzzing: Burp Suite, Acunetix, Netsparker
Vulnerability Analysis: OpenSSL, sqlmap, CVE-Details
Exploitation: Metasploit, Netcat, Exploit-DB

Free toolkit

Penetration Testing Checklists

Sixteen assessment checklists covering the targets we test: web applications, Android, iOS, APIs, networks, Active Directory, thick clients, WiFi, SCADA and ATMs — plus red team test cases, firewall audit, malware analysis and vendor security assessment.

16 checklists · ZIP · 775 KB

Download the toolkit

Deliverables

Technical assessment report (PDF)
Executive summary (PDF, one page)
Attack path narrative with diagram
Finding register (spreadsheet) with affected host inventory
MITRE ATT&CK mapping for the blue team
Remediation walkthrough with the infrastructure team
Retest report evidencing closure

Frequency

One-time: A first assessment, a specific customer requirement, or validation after a major infrastructure change.
Quarterly: External perimeter for organisations with a changing internet footprint, or where a regulator requires it.
Biannually: Internal network for most organisations — frequent enough to catch drift, spaced enough to allow remediation between cycles.
Annually: Stable internal networks with strong change control, supplemented by continuous vulnerability management.

Resource deployment

External testing runs remotely. Internal testing requires either an on-site presence or a CSS-supplied device shipped to the client and connected to the network. On-site is preferred for first engagements: a tester in the building can verify physical network access, test wireless and guest segmentation, and confirm segmentation claims against actual cabling rather than documentation. A typical internal engagement places one or two testers on site for three to five days, with analysis and reporting completed remotely.

How CSS tests

A unified swarm of agents, for blind spot detection

AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.

Enumeration across a large address space is exhaustive machine work; a tester under time pressure samples, and the host that gets skipped is the one running the forgotten appliance.
Credential spraying has to respect lockout thresholds across thousands of accounts simultaneously — a scheduling problem agents handle and humans get wrong.
Attack path analysis across a domain is a graph problem. Agents enumerate paths; the tester decides which are realistic and which depend on conditions that will not occur.
Detection coverage is assessed by correlating every action taken against what the client's tooling recorded, which requires complete action logging rather than tester recollection.

Every agent finding is validated by a human tester before it reaches the report, and all exploitation remains under human control. The swarm decides what to look at; it does not decide what is true, and it does not decide what to exploit.

Why this differs

What CSS does that most vendors do not

Every one of these is checkable. Ask any vendor for the same and compare the answers.

Exploited, not scanned

A Nessus report is not a penetration test. Findings reach the report only when exploited or, where exploitation is out of scope, when confirmed by hand with evidence.

Both reports, always

Technical report and executive summary together, plus an attack path narrative that reads as a story rather than a table.

Fixation, not a backlog

Remediation worked with the infrastructure team and retested to evidence closure.

Detection is assessed, not ignored

The report states what the client's own monitoring caught and what it missed. Most vendors report the vulnerability and say nothing about whether anyone would have noticed.

Reporting

Two documents, two audiences

Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.

Technical assessment report

For the engineers who will fix it

Disclaimer, and Limitations on Disclosure and Use
Risk Level & Description — the five levels above, scored on CVSS 3.1
Scan Type — which of the five assessment types were selected
Assessment Scope — the control areas covered
Assessment Date — the exact testing window
Objective of the Assessment — objectives listed against completion status
Tools Utilization — manual and automated tooling by stage
Summary of the Assessment
Overall Recommendations, split into Must Have and Should Have
Vulnerability Overall Classifications as per Organization
Security Issues Highlighted
The Key Findings — each with evidence and detailed recommendation
Summary of Findings & Conclusion

For this assessment specifically

Scope, address ranges, source addresses used and the exact test window
Every finding with CVSS v3.1 vector, CWE reference and affected hosts
Attack path narrative from initial access to the highest privilege reached
Evidence: command output, screenshots, captured credentials redacted
MITRE ATT&CK technique mapping for the detection team
Segmentation results against the documented design
Detection timeline: what was alerted on and when
Retest results appended against each original finding

Executive summary

For the people who will fund the fix

Objectives, each against a completion status
Overall Finding of the Assessment — total threats identified, broken down by component and severity
Summary of the Assessment
Artefacts of the Assessment — the key findings as a numbered register with severity
Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
Overall Recommendation, including a Business Enabling Recommendation sequence
Must Have and Should Have actions

For this assessment specifically

What an attacker could reach, stated in terms of business systems rather than hostnames
Severity distribution and movement since the previous assessment
The three things that most need funding
Regulatory exposure where relevant (PCI DSS segmentation, RBI, CERT-In directions)
Remediation timeline and retest date
One page

Case studies

What this finds in practice

Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.

A manufacturing group with eleven plants and a corporate data centre.

Finding: Corporate and plant networks were documented as segmented. In practice a single misconfigured route on a legacy firewall allowed a compromised office laptop to reach the plant historian and, through it, the engineering workstation network.
Recommendation: Correct the route, then verify segmentation by testing rather than by reading configuration. Add segmentation validation as a standing item after any firewall change.
Outcome: Route corrected within 48 hours. Segmentation testing is now run quarterly, and has since caught two further drift issues after change windows.

A financial services firm, roughly 900 staff, internal assumed-breach engagement.

Finding: From a standard user account, LLMNR poisoning captured a service account hash within twenty minutes. The account was a local administrator on 340 hosts and its password had not changed in four years. Domain admin followed in under three hours.
Recommendation: Disable LLMNR and NBT-NS, enforce SMB signing, rotate the service account and remove its blanket local administrator rights in favour of per-host delegation.
Outcome: All implemented over six weeks. The retest reached local administrator on two hosts and stopped there. Nothing had alerted during the original test, which drove a separate detection engagement.

A hospital network with clinical and administrative systems on shared infrastructure.

Finding: Medical imaging devices running end-of-life embedded operating systems sat on the same VLAN as administrative workstations, with no host protection and no patch path from the vendor.
Recommendation: Isolate clinical devices into their own segment with explicit allow rules, since patching is not available. Compensating controls where the vendor cannot fix the device.
Outcome: Isolation implemented across two maintenance windows. The finding also gave the hospital documented evidence to take to the device vendor at contract renewal.

Scope this assessment

Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.

Start a conversation All VAPT capabilities