September 24, 2026
The Reflected XSS Methodology: 11 Labs Behind $5,000+ in Bounties and 80+ Pentests
The Reflected XSS Methodology: 11 Labs Behind $5,000+ in Bounties and 80+ Pentests
Salman Khan
New Update: Our new blog is updated.
Free download
Omair Manzoor is the Founder, CEO, and Chief Hacker of ioSENTRIX, a CREST-accredited cybersecurity firm. With 14+ years in offensive security, he has led penetration tests for Fortune 500 companies including engagements for Amazon, Bank of America, VISA, and the London Underground. His exploits are part of the Metasploit Framework and Immunity Canvas. Omair is a published researcher, conference keynote speaker (DOD, CISA, BSides), and technical reviewer for academic security textbooks.
Internal vs external penetration testing is the first scoping decision in any network security program, and the wrong answer wastes budget. An external network pentest tells you what an attacker on the internet can reach and break. An internal network pentest tells you what that same attacker can do once they are inside. Both answer different questions, and a mature program runs both.
This guide explains the difference between internal and external penetration testing, walks through the methodology for each, and gives you the frequency rules that PCI DSS v4.0.1 actually sets.
External network penetration testing is a controlled attack on an organization's internet-facing systems, performed from outside the network with no prior access, to prove which exposures a real attacker could exploit. It covers everything with a public IP or DNS name: firewalls, VPN gateways, mail servers, web and API hosts, remote access portals, and cloud-hosted services that answer to the internet.
The attacker's starting position is the internet, and the starting knowledge is usually just a company name or a list of IP ranges. That is what separates an external network pentest from a vulnerability scan: the scanner reports a version banner; the tester chains that banner into a working foothold, or proves the exposure is not exploitable in your configuration.
Internal network penetration testing is a controlled attack performed from inside the network, starting from the position of a compromised workstation, a rogue employee, or a phished user, to measure how far an attacker can move and what they can take before anyone notices. The scope is the internal estate: workstations, file servers, Active Directory, internal applications, and the segmentation that is supposed to keep them apart.
The premise is that perimeter controls have already failed, which is the realistic assumption. The tester is given, or quickly obtains, a low-privilege foothold and then works toward domain-level control, sensitive data stores, or whatever "crown jewels" the engagement defines. The question is not whether an attacker can get in, but what the blast radius is once they do.
A good internal pentest also tests the defenders. If EDR and SIEM never fired while the tester dumped credentials and crossed three subnets, that silence is a finding.
The difference between internal and external penetration testing comes down to the attacker's starting position and the question being answered. External testing starts from the internet with no access and asks "can they get in?" Internal testing starts from inside the network with a foothold and asks "how bad is it when they do?"
Everything else follows from that split. External scopes are narrower and defined by public exposure. Internal scopes are wider and defined by what is reachable from a given network position. External findings cluster around exposed services, weak authentication, and misconfiguration. Internal findings cluster around Active Directory weaknesses, credential reuse, flat networks, and missing detection. External tests are usually shorter; internal tests take longer because the attack surface is larger and the attack paths are deeper.
Neither test substitutes for the other. A hardened perimeter with a flat internal network is one phishing email away from domain compromise. Tight segmentation behind an unpatched VPN appliance is one CVE away from the same outcome.
An external network penetration testing methodology moves through three phases: reconnaissance and OSINT to build a map of what the organization exposes, exposure mapping to enumerate and fingerprint every reachable service, and exploitation to prove which exposures give an attacker a foothold. The phases line up with the Penetration Testing Execution Standard (PTES), which defines intelligence gathering, vulnerability analysis, exploitation, and post-exploitation as distinct stages, and with the planning, discovery, attack and reporting structure in NIST SP 800-115.
The tester starts with nothing but the target's name and builds the attack surface from public data: DNS records, certificate transparency logs, ASN and IP allocations, cloud storage naming patterns, job postings that reveal technology stacks, and credential dumps from past breaches. This is the OSINT phase, and it regularly turns up assets the client did not know were theirs: a forgotten staging subdomain, a microsite on an unpatched CMS, a developer's test API. MITRE ATT&CK catalogs this stage under the Reconnaissance tactic (TA0043).
With the asset list in hand, the tester enumerates every reachable service, fingerprints versions, and identifies authentication surfaces: VPN portals, webmail, SSO login pages, management interfaces that should never face the internet. Findings are prioritized by exploitability, not CVSS score alone: a default credential on a management console outranks a critical CVE whose exploit path a WAF blocks.
The tester attempts to gain a foothold: exploiting an unpatched service, abusing a misconfiguration, or using leaked credentials against an exposed login. Password spraying against a VPN or SSO portal is a common path because real intrusions use it. The goal is evidence. If a foothold is achieved, the tester documents the full chain and stops at the agreed boundary set in the rules of engagement. If no foothold is achieved, the report says so, with the exposures that were probed and why they held.
An internal network penetration testing methodology starts from an assumed breach, maps Active Directory attack paths from that foothold, and then executes lateral movement toward defined objectives while measuring whether defenders detect any of it.
The engagement begins with a foothold the client provides: a standard-user domain account, a workstation on the corporate VLAN, or VPN access equivalent to a remote employee. This is deliberate: spending days on initial access wastes budget better spent on what happens after, and it reflects how most incidents unfold, through a phished user or a compromised laptop rather than a zero-day against the firewall.
From the foothold, the tester enumerates the domain: users, groups, computers, group policy, trusts, and service accounts. Most internal compromises run through Active Directory, because it is where identity, privilege, and trust relationships are centralized. Common paths include Kerberoasting (ATT&CK T1558.003) to crack service account passwords offline, pass-the-hash (T1550.002) to reuse cached credentials across hosts, and abuse of over-permissioned groups or delegation settings. The tester is looking for the shortest path from a standard user to Domain Admin, and there almost always is one.
With elevated access, the tester moves toward the engagement's objectives: a database of customer records, a finance share, an OT jump host, a backup server. Lateral movement (ATT&CK TA0008) across VLANs also tests network segmentation directly. If the tester reaches the cardholder data environment from a guest wireless segment, the segmentation control failed, whatever the firewall rules say on paper. Throughout, the tester logs timestamps so the client can check them against SIEM and EDR alerts afterward. The gap between what happened and what was detected is one of the most valuable outputs of the engagement.
You need both, but the order and frequency depend on what changed. Run an external network pentest when you have launched or changed anything internet-facing, when a compliance framework requires perimeter testing, or when you have never had one. Run an internal network pentest when you want to know your blast radius, when you have had an incident or suspicious activity, when you have changed segmentation or identity infrastructure, or when your detection stack has never been exercised by a real adversary simulation.
If budget forces a choice for a first engagement, ask which failure would hurt more. A public SaaS company is usually exposed most on the outside. A company with a large office estate, a Windows domain, and a modest public footprint is usually exposed most on the inside, and the internal test tends to produce the more alarming report, because flat networks and stale Active Directory hygiene are common and rarely visible until someone exploits them.
For organizations that need to demonstrate both to an auditor, the practical model is a combined engagement: an external phase, then an internal assumed-breach phase, delivered as one report with one remediation plan. That is also how ioSENTRIX scopes most network penetration testing work, because the findings from one phase inform the other.
PCI DSS v4.0.1 requires both internal penetration testing (Requirement 11.4.2) and external penetration testing (Requirement 11.4.3) at least once every 12 months and after any significant infrastructure or application upgrade or change. Each test must follow the entity's documented methodology (11.4.1) and be performed by a qualified internal resource or qualified external third party with organizational independence from the systems being tested; the tester does not need to be a QSA or ASV.
Two related rules matter for scoping. Requirement 11.4.1 requires the methodology to include testing from both inside and outside the network and to validate any segmentation and scope-reduction controls. Requirement 11.4.5 requires penetration tests on segmentation controls at least once every 12 months and after any change to those controls, and 11.4.6 raises that to at least once every six months for service providers. The PCI Security Standards Council published v4.0.1 in June 2024 as a limited revision with no added or deleted requirements, so the 11.4 frequencies carry over from v4.0 unchanged. The requirement text above is taken from the Council's published SAQ D for Merchants.
The takeaway is that PCI DSS does not let you pick one. If cardholder data is in scope, annual internal and external network penetration testing is the floor, not a best practice. Our PCI DSS v4.0 penetration testing guide covers the full requirement set. ioSENTRIX performs the penetration testing side of PCI compliance; we are not an Approved Scanning Vendor and do not perform ASV scans.
Internal penetration testing is a simulated attack launched from inside an organization's network, starting from the position of a compromised device or user account. It measures how far an attacker can escalate privileges and move laterally, and whether internal defenses detect the activity. The most common objective is control of Active Directory or access to a defined set of sensitive systems.
External penetration testing is a simulated attack launched from the internet against an organization's public-facing systems, with no prior access. It identifies which exposed services, credentials, or misconfigurations an outside attacker could use to gain a foothold. The tester starts from public information and works inward.
External network pentests are typically shorter because the scope is bounded by what is publicly exposed. Internal network pentests take longer because the reachable attack surface is larger and Active Directory attack paths take time to map and exploit safely. Actual duration depends on the number of hosts, the complexity of the domain, and the objectives agreed in scoping; see our penetration testing cost guide for the factors that drive effort.
No. An internal pentest is scoped, time-boxed, and focused on finding as many exploitable weaknesses as possible from a given position, with the blue team usually aware. A red team engagement is objective-driven, often covert, and tests people and process as well as technology.
Yes. Penetration Testing as a Service (PTaaS) delivers internal and external testing on a rolling basis, with findings tracked in a portal and retests requested on demand rather than waiting for the next annual cycle. This fits organizations that change infrastructure often, since PCI DSS requires retesting after significant changes anyway. ioSENTRIX offers this through its PTaaS service.
ioSENTRIX is a CREST-accredited penetration testing firm, ISO/IEC 27001 certified and SOC 2 Type 2 attested. Our network penetration testing engagements cover both external and internal scopes, with assumed-breach internal testing, Active Directory attack-path mapping, and detection review built into the standard methodology. We do not stop at reporting that a control exists; we produce evidence of whether it held under attack.
If you are scoping your next network pentest, or an auditor has asked for both internal and external results, talk to us and we will help you define a scope that answers the questions that matter.
