Pre-Engagement

Proper pre-engagement sets the foundation for a successful internal penetration test. This phase covers scoping, authorization, network architecture review, and establishing rules of engagement.

Danger

Never begin testing without signed authorization documents. Unauthorized network access is a federal crime under the CFAA and similar laws internationally. On an internal test the boundary has to name ranges, domains and accounts, not "the internal network": that phrase includes guest Wi-Fi, BYOD and partner-managed segments your client may not own, and a sweep of those is a separate authorisation from the one you hold.

Scoping Considerations

Network Scope Definition

Scope Element	Questions to Ask
IP Ranges	Which subnets are in scope? Any exclusions?
Domains	Which AD domains/forests are included?
Systems	Production vs. test? Critical systems excluded?
Cloud	Azure AD, AWS, GCP resources in scope?
Accounts	Test accounts provided or start from zero?

Test Types

The test type decides what the discovery phases have to do for you. Pick it from the client's objective, not from the budget: a black-box test on an estate with full network documentation available spends a week re-deriving what a white-box start would have handed over in an hour, and reports "found the domain" instead of "found the path to the domain".

Type	What you are given	What it simulates	What it can and cannot prove
Black box	Nothing — no credentials, no diagrams, no asset list	An attacker with a foothold and no context	Proves reachability and time-to-compromise. Cannot separate "not exposed" from "we did not find it".
Grey box	One standard user account, basic network information	A compromised employee account — the usual starting point	Best value per day: tests what an authenticated insider reaches, including AD object ACLs.
White box	Admin credentials, full documentation, sometimes a build review	Assuming breach; validating controls rather than perimeter	Maximum coverage and the only shape that can audit configuration at scale. Says nothing about what an unauthenticated attacker reaches.

Authorization Documents

Required Documentation

1. Statement of Work (SOW)

• Detailed scope and objectives
• Timeline and milestones
• Deliverables and report format
• Pricing and payment terms

2. Rules of Engagement (ROE)

• Authorized testing hours
• Allowed attack techniques
• Escalation procedures
• Communication protocols

3. Authorization Letter

• Signed by authorized executive
• Explicit permission to test
• Tester indemnification
• Emergency contacts

Sample Authorization Template

Network Architecture Review

Information

Request network documentation upfront to plan your attack paths and identify high-value targets.

Information to Gather

Network Topology

• Network diagrams
• VLAN segmentation
• Firewall rules (internal)
• VPN configurations
• DMZ architecture

Active Directory

• Domain/forest structure
• Trust relationships
• Domain controller locations
• GPO overview
• Service accounts

Critical Assets

• Database servers
• File servers
• Email servers
• Backup systems
• Crown jewels

Security Controls

• EDR/AV solutions
• SIEM deployment
• NAC implementation
• MFA coverage
• PAM solutions

Test Environment Setup

Attacker Machine Checklist

setup-attacker.sh

# Kali Linux / Parrot OS Setup
sudo apt update && sudo apt upgrade -y

# Essential tools
sudo apt install -y nmap masscan nxc impacket-scripts \
  bloodhound neo4j responder mitm6 ntlmrelayx hashcat john \
  smbclient enum4linux-ng ldapsearch

# Impacket (latest)
git clone https://github.com/fortra/impacket
cd impacket && pip install .

# BloodHound (latest)
# Download from: https://github.com/BloodHoundAD/BloodHound/releases

# PowerShell Empire
git clone https://github.com/BC-SECURITY/Empire
cd Empire && ./setup/install.sh

# Verify tools
which nmap nxc impacket-secretsdump bloodhound-python

Network Access Requirements

Access Method	Pros	Cons
On-site	Direct access, no latency, physical testing possible	Travel required, limited flexibility
VPN	Remote access, convenient	May limit some attacks, network dependency
Jump Box	Controlled access point, audit trail	Limited toolset, performance constraints
Drop Box	Persistent access, simulates insider	Physical deployment needed, detection risk

Communication Plan

Escalation Matrix

Severity	Example	Response Time	Contact
Critical	Domain Admin compromise, active breach indicators	Immediate (phone)	CISO + SOC
High	Unpatched critical CVEs, credential exposure	4 hours	Primary Contact
Medium	Misconfigurations, weak passwords	Daily report	Email
Low	Informational findings	Final report	N/A

Pre-Engagement Checklist

Signed Statement of Work (SOW) Authorization letter with executive signature Rules of Engagement documented IP ranges and exclusions confirmed Emergency contacts documented Network access method established Testing tools installed and verified Communication plan agreed upon

Evidence Collection

This phase produces documents rather than packets. They are the evidence: they are what proves the work was authorised, bounded and reversible if a host owner objects.

Signed authorisation: Countersigned SOW, ROE and authorisation letter, with the scope table attached as an annex. The annex — not the covering letter — is what identifies the ranges, domains and accounts that were in play.

Exclusion confirmations: The client's written replies to each "is this in scope?" question, with dates. A verbal answer is not evidence; the email that repeats it back is.

Access records: The ticket or email that provisioned your VPN account or jump box, plus the account names issued. These bound what you can be accused of and what you must hand back.

Contact test: A note that the primary emergency number was dialled once before the engagement and answered. The number that only works during office hours is a finding for the report and a risk during the test.

Tool baseline: Versions of the scanners and clients you will run (nmap, nxc, Impacket, bloodhound-python). A finding you cannot reproduce on a clean host is a finding you cannot defend in a retest.

False Positive Identification

A host that answers is not a host in scope: A sweep of 10.0.0.0/8 reaches management, partner and lab segments. Check every address against the signed annex before you probe it further; reachability is a technical fact, authorisation is a legal one.
Stale scope: A decommissioned range still listed, or a new subnet nobody added. Confirm against the current DHCP and ARP view and get the delta in writing instead of deciding for the client.
Conflicting documents: The SOW lists password attacks but the ROE bans lockout risk. The stricter document wins, and the conflict belongs in the report rather than in your judgement call at 23:00.
Verbal expansion: "You can also look at the cloud tenant" from a project manager is not authorisation. The signatory amends the document, or the tenant waits for a separate engagement.

Testing Checklist

The document list above is what you must hold. These are the checks that prove it is live on the day, before the first packet leaves your machine.

Confirm the authorisation is current

☐ The signed annex in front of you lists the ranges you are about to touch - diff it against your target file, not against memory.
☐ The client's SOC holds your source addresses and testing window in writing, and has acknowledged them.
☐ The emergency number was dialled from the machine you will test from and answered; the time is in your notes.
☐ The VPN or jump-host account issued to you works, and you can name who provisions and revokes it.

Confirm the environment answers

☐ One in-scope host responds from the testing position; silence is an access problem to escalate, not a finding.
☐ Every address you have discovered outside the annex is logged and left untouched, including management and lab segments.
☐ Tool versions are recorded and each tool resolves the target by the same name the client uses.
☐ The out-of-band channel to the client contact works from the test host, not only from your desk.

Remediation & Defense

The deliverable of this phase is process, and these are the controls that stop the next test from starting on a bad footing.

Before the first packet

• Scope as an annex listing ranges, domains and accounts, with exclusions named individually
• Named emergency contacts for every window, with after-hours numbers
• Written testing windows and intensity limits for the segments with production traffic
• A named person who can suspend the test, and a stated way to reach them

During the engagement

• Change control for every scope expansion, signed before the first packet into the new range
• Log any out-of-scope contact and report it the same day, not in the final report
• Keep the capture and tool logs that support the report figures

After

• Return or retain artefacts per the data-handling clause, with destruction dates honoured
• Destroy collected personal data on the agreed date and confirm it in writing
• Record what the client must do before a retest — usually a scope refresh

Reconnaissance

Next phase: discover the network you just scoped

Lab Setup

Build an AD lab to test the rules of engagement on

Legal & Compliance

Authorization, scope and legal boundaries for testing