Organizations running regular penetration tests often face the same early question: should you be testing from the outside in, or from the inside out? The answer matters more than most teams realize. Internal and external penetration testing serve fundamentally different purposes, surface entirely different attack paths, and require distinct toolsets, methodologies, and scoping decisions.
This post breaks down both approaches in technical depth, covering what each test actually involves, what an attacker model looks like in each scenario, and how to decide which one your organization needs right now.
External penetration testing simulates an attacker who has no prior access to your environment. The tester starts from a position of zero trust, zero credentials, and zero internal network visibility. Everything that gets discovered must be found through open-source intelligence, service enumeration, vulnerability scanning, and exploitation of internet-facing systems.
The attack surface for an external test includes public IP ranges, DNS records, web applications, mail servers, VPN gateways, API endpoints, and any externally reachable service.
Before a single packet is sent, a skilled external tester will spend significant time on passive reconnaissance. Tools like theHarvester, Amass, and Shodan are standard starting points.
amass enum -passive -d redfoxsec.com -o redfox_subdomains.txt
[cta]
theHarvester -d redfoxsec.com -b google,bing,linkedin,shodan -f redfox_harvest.html
[cta]
This phase reveals subdomains, email naming conventions, exposed services, and technology stacks, all without touching a single target system directly. A Shodan query can surface forgotten admin panels, unpatched appliances, and development servers left open to the public internet.
shodan search "org:TargetCorp" --fields ip_str,port,hostnames,os
[cta]
Once the external attack surface is mapped, the tester moves into active scanning. Nmap with aggressive service detection and Nessus or Nuclei for vulnerability identification are commonly used here.
nmap -sV -sC -p- --min-rate 3000 -oA external_scan 203.0.113.0/24
[cta]
nuclei -l redfox_subdomains.txt -t cves/ -t exposures/ -severity critical,high -o nuclei_results.txt
[cta]
The goal is to identify CVEs affecting exposed services, misconfigurations in web servers, SSL/TLS weaknesses, open administrative interfaces, and default credentials on network appliances.
Web applications represent the largest and most exploitable portion of an external attack surface for most organizations. Testers will conduct parameter fuzzing, authentication testing, and injection attacks against login portals, APIs, and content management systems.
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt \
-u https://target.com/FUZZ \
-mc 200,301,302,403 \
-o ffuf_results.json
[cta]
sqlmap -u "https://target.com/search?q=test" \
--level=5 --risk=3 \
--dbs --batch \
--output-dir=sqlmap_output
[cta]
External testers will also probe for SSRF vulnerabilities, JWT weaknesses, OAuth misconfigurations, and exposed API keys in JavaScript bundles, all of which represent realistic paths an external attacker would use.
If your organization needs a structured external assessment that goes beyond automated scanning, Redfox Cybersecurity delivers manual-led external penetration testing that mirrors the tradecraft of real-world threat actors targeting your perimeter.
Internal penetration testing starts from a position of assumed breach or insider threat. The tester either operates from within the corporate network physically, connects over VPN with a standard user account, or is given a low-privileged foothold to simulate post-exploitation activity following an initial compromise.
This type of testing is designed to answer a critical question: if an attacker gets past the perimeter, how far can they go?
The assumed breach model has become the preferred framing for most internal penetration tests. Rather than spending days trying to bypass perimeter controls, the tester starts with a standard domain user account and a workstation on the internal network, then attempts to escalate privileges, move laterally, and reach high-value targets like domain controllers, financial systems, or sensitive data stores.
This model reflects reality. Most breaches today begin with phishing, credential stuffing, or supply chain compromise, all of which hand an attacker an internal foothold without ever defeating the perimeter head-on.
Active Directory is the backbone of most enterprise Windows environments, and it is almost always the primary target in an internal penetration test. Tools like BloodHound, SharpHound, and ldapdomaindump are used to map out privilege paths, group memberships, and misconfigurations.
bloodhound-python -u lowprivuser -p 'Password123' \
-d corp.local -c All \
--zip -o bloodhound_data
[cta]
ldapdomaindump -u 'corp.local\lowprivuser' -p 'Password123' \
ldap://dc01.corp.local -o ldap_dump/
[cta]
BloodHound's graph analysis will surface attack paths that are invisible to most defenders, including Kerberoastable service accounts, unconstrained delegation, ACL abuse chains, and paths to Domain Admin through nested group memberships.
Once the environment is mapped, internal testers will attempt credential-based attacks. Kerberoasting, AS-REP Roasting, and NTLM relay attacks are staple techniques in this phase.
impacket-GetUserSPNs corp.local/lowprivuser:Password123 \
-dc-ip 10.0.0.1 \
-request \
-outputfile kerberoast_hashes.txt
[cta]
hashcat -m 13100 kerberoast_hashes.txt \
/usr/share/wordlists/rockyou.txt \
-r /usr/share/hashcat/rules/best64.rule \
--status
[cta]
NTLM relay attacks using Responder and ntlmrelayx are particularly effective in environments that have not disabled LLMNR and NBT-NS or enforced SMB signing.
responder -I eth0 -wv
[cta]
impacket-ntlmrelayx -tf relay_targets.txt \
-smb2support \
-l loot/
[cta]
For Windows local privilege escalation, WinPEAS and PowerUp are used to identify unquoted service paths, weak registry permissions, and token impersonation opportunities.
. .\PowerUp.ps1
Invoke-AllChecks | Out-File -FilePath C:\Temp\powerup_results.txt
[cta]
The Redfox Cybersecurity team conducts internal penetration tests that include full Active Directory attack path analysis, lateral movement simulation, and domain compromise walkthroughs with remediation guidance.
After gaining elevated credentials or a foothold on a privileged system, internal testers simulate lateral movement across the network. Pass-the-hash, pass-the-ticket, and WMI-based execution are common methods.
impacket-wmiexec corp.local/administrator@10.0.0.5 \
-hashes aad3b435b51404eeaad3b435b51404ee:8f81ee5558e2d1244a3e289d4b9bf18c
[cta]
impacket-psexec corp.local/administrator@10.0.0.5 \
-hashes aad3b435b51404eeaad3b435b51404ee:8f81ee5558e2d1244a3e289d4b9bf18c
[cta]
Testers also check for credential reuse across systems, overly permissive SMB shares exposing sensitive data, and SSH key pairs stored on compromised workstations that open paths to additional hosts.
Understanding the distinction at a high level is useful. Understanding it at the level of scope, attacker model, tooling, and business impact is what helps security teams make the right investment decision.
External testing models a threat actor with no prior knowledge or access. Internal testing models a threat actor who has already established a foothold, whether through phishing, a compromised vendor account, or a malicious insider.
These are not interchangeable scenarios. An organization can have a hardened perimeter and still be extremely vulnerable internally, because internal security is frequently treated as an afterthought once the firewall is trusted.
External tests are scoped to internet-facing assets: public IP ranges, domains, subdomains, APIs, and cloud-exposed services. Internal tests are scoped to internal network segments, Active Directory infrastructure, internal applications, databases, workstations, and server infrastructure.
In practice, internal scopes tend to be significantly larger and require more time to cover thoroughly.
While there is some overlap, the toolsets diverge meaningfully. External tests lean on Amass, Nuclei, ffuf, sqlmap, Burp Suite Professional, and Nikto. Internal tests rely heavily on BloodHound, Impacket, Rubeus, CrackMapExec, Responder, and Mimikatz equivalents like lsassy or pypykatz.
cme smb 10.0.0.0/24 -u administrator \
-H 8f81ee5558e2d1244a3e289d4b9bf18c \
--shares
[cta]
lsassy -d corp.local -u administrator \
-H 8f81ee5558e2d1244a3e289d4b9bf18c \
10.0.0.5
[cta]
External vulnerabilities represent the most immediate risk, because they are accessible to any attacker on the internet. Internal vulnerabilities represent the highest damage potential, because they often lead directly to domain compromise, ransomware deployment, or data exfiltration.
Prioritizing one over the other without considering both is a strategic gap. The most resilient organizations test both surfaces regularly, because real-world attackers chain external entry points directly into internal exploitation paths.
The answer depends on your current security posture, your compliance requirements, and your threat model.
External testing should be a baseline requirement for any organization with public-facing infrastructure. It is especially urgent if your organization has recently expanded its cloud footprint, deployed new web applications, acquired a company with unknown external exposure, or received a threat intelligence alert about your sector.
Regulatory frameworks including PCI DSS, ISO 27001, and SOC 2 Type II all require external penetration testing as part of their assessment scope. If you are pursuing any of these certifications or renewals, a structured external test from a qualified team like Redfox Cybersecurity is a prerequisite, not just a best practice. You can review the full scope of security testing services at redfoxsec.com/services to understand what a compliance-grade engagement covers.
Internal testing is critical when your organization has never assessed what an attacker could do with a single compromised workstation. It is also essential after a phishing incident, after onboarding a large number of new systems, or when you suspect that your Active Directory environment has accumulated years of privilege debt.
Organizations that rely on flat internal networks, that have not implemented network segmentation, or that are running legacy operating systems should treat internal penetration testing as urgent rather than routine.
The most effective security programs treat internal and external testing as complementary, not competing. An external test that achieves a foothold hands the results directly to an internal test simulation. A full red team engagement will chain both phases together, from initial OSINT through perimeter exploitation through lateral movement to full domain compromise.
If budget constraints force a choice, a reasonable approach for most mid-sized organizations is to run an external test first to close the most immediately exploitable gaps, then follow up with an internal test under the assumed breach model to understand the blast radius of a successful perimeter compromise.
A quality external penetration test report will include a full asset inventory discovered during reconnaissance, a list of exploited and exploitable vulnerabilities mapped to CVEs and CVSS scores, proof-of-concept documentation for each finding, and prioritized remediation guidance.
Testers should be able to show exactly how an unauthenticated attacker could move from a Shodan search to a shell on an internal system, step by step.
An internal test report should include an Active Directory attack path map, a list of compromised credentials and systems, lateral movement paths documented with tool output and screenshots, and a clear narrative showing how far an attacker could have gotten from a single low-privileged starting point.
The best internal test reports include remediation guidance that is specific, actionable, and sequenced by business impact, not just CVSS score.
Internal and external penetration testing are not variations of the same exercise. They target different attacker models, require different toolsets, and surface different categories of risk. External tests expose what any internet-connected attacker can see and exploit. Internal tests expose what happens after the perimeter fails, which, given current breach statistics, is the scenario every organization should be prepared for.
Running only external tests leaves your organization blind to the lateral movement and privilege escalation paths that define modern ransomware and data extortion campaigns. Running only internal tests ignores the front door. A mature security program needs both, conducted by testers who understand the difference between checking compliance boxes and simulating the tradecraft of real adversaries.
Redfox Cybersecurity delivers both internal and external penetration testing engagements with full manual exploitation, detailed reporting, and remediation support. If you are ready to understand your true attack surface from both sides, explore the full range of penetration testing services at redfoxsec.com/services and reach out to schedule a scoping call.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
