// the kill chain

How a test actually unfolds

Every professional engagement, CTF box, and bug hunt follows the same arc. Learn the phases and you will always know what to do next. Open any phase for its goals, techniques, deliverables, and the mistakes to avoid.

  1. 0x00

    Scope & Authorization

    Get written permission that names exactly which systems, dates, and techniques are allowed.

    • Signed RoE
    • Scope file
    • Emergency contact
    • Encrypted evidence store

    Goal: Turn an idea of a test into a signed agreement that protects you, the client, and every third party their systems touch.

    Questions to answer

    • Who owns each asset in scope, and does the person signing actually have authority over it?
    • Which IP ranges, domains, applications, and accounts are in scope, and which are explicitly out?
    • Are third-party services (cloud, SaaS, CDN, payment processors) included, and do their terms allow testing?
    • What testing windows apply, and are there blackout periods such as month-end processing?
    • Is social engineering, physical access, or denial of service allowed? Usually the answer is no.
    • Who is the emergency contact if something breaks or you find evidence of a real breach?

    Deliverables

    • Signed rules of engagement
    • Machine-readable scope list
    • Contact sheet with escalation path
    • Kickoff call notes

    Techniques

    Rules of engagement
    A document covering scope, timing, allowed techniques, data handling, communication, and stop conditions. Both sides sign it before any traffic is sent.
    Scope validation
    Resolve every domain and check every IP against WHOIS and ASN records. Clients regularly list addresses they do not own, such as a former hosting provider's range.
    Threat modeling the engagement
    Agree on what you are simulating: an external attacker with nothing, a phished employee, a malicious insider, or a compromised vendor. It shapes every later phase.
    Data handling plan
    Decide where evidence lives, how it is encrypted, and when it is destroyed. You will likely see personal data and credentials.
    Bug bounty scope
    For public programs, the policy page is your authorization. Read it fully, including the out-of-scope list and the safe harbor terms.

    Common mistakes

    • Starting with a verbal OK or a forwarded email from someone who does not own the systems.
    • Assuming a cloud provider's or SaaS vendor's infrastructure is in scope because the client uses it.
    • Testing an IP that has since been reassigned to someone else.
    • No agreed plan for what happens if you find a live intrusion by a real attacker.

    Pro tips

    • No signature, no packets. This single document is what makes it a test instead of a crime.
    • Keep the scope file in your project folder and load targets from it, so a typo cannot add a stranger's host.
    • Ask for a test account at every privilege level. It turns hours of guessing into minutes of real testing.
    Read our disclaimer on legal use →
  2. 0x01

    Reconnaissance

    Map the attack surface from public sources before touching anything: domains, subdomains, people, tech stack.

    • crt.sh
    • subfinder
    • amass
    • Shodan
    • Censys
    • Wayback Machine
    • GitHub search
    • whois

    Goal: Build the most complete picture of the target possible without sending a single packet to it.

    Questions to answer

    • What domains, subdomains, and IP ranges belong to the organization, including acquisitions and old brands?
    • What technologies, frameworks, cloud providers, and third-party services do they use?
    • What do employee names, roles, and email formats look like?
    • Have credentials, source code, or internal documents leaked publicly?
    • What did the attack surface look like in the past, and what might still be running?

    Deliverables

    • Asset inventory (domains, hosts, IPs)
    • Technology profile
    • Leaked data notes
    • Prioritized target list

    Techniques

    Certificate Transparency
    Every publicly trusted TLS certificate is logged. Searching crt.sh for %.example.com lists subdomains, including internal and staging names.
    Passive DNS and subdomain sources
    Tools like subfinder and amass aggregate dozens of sources: DNS datasets, search engines, archives, and APIs.
    ASN and IP range mapping
    Look up the organization's autonomous system numbers to find netblocks they own outright.
    Search engine dorking
    Queries like site:example.com filetype:pdf or site:example.com inurl:admin find exposed documents and panels.
    Historical content
    The Wayback Machine and similar archives reveal old endpoints, parameters, and JavaScript files that may still be live.
    Code and secret leaks
    Search public code hosts for the company's domain, internal hostnames, and API key patterns.
    People and email format
    Public profiles reveal names and roles. Combine with a confirmed email format to understand the human attack surface, even if phishing is out of scope.
    Internet-wide scan data
    Shodan, Censys, and similar services already scanned the internet. Query them for the target's ranges and certificates.

    Common mistakes

    • Skipping recon to start scanning. You will test a fraction of the real surface.
    • Treating every discovered asset as in scope. Check each one against the scope file.
    • Not saving raw output. You will need it again, and in the report.

    Pro tips

    • Certificate Transparency logs list subdomains companies forgot they had.
    • Old JavaScript files in archives often reference API endpoints that were never removed.
    • Acquired companies are frequently the weakest link and still connected to the parent network.
    How DNS works →
  3. 0x02

    Scanning & Enumeration

    Find live hosts, open ports, service versions, users, shares, and every endpoint the app exposes.

    • Nmap
    • masscan
    • ffuf
    • feroxbuster
    • Burp Suite
    • enum4linux-ng
    • NetExec
    • ldapsearch
    • snmpwalk

    Goal: Turn a list of targets into a detailed map of every service, version, user, and entry point you can reach.

    Questions to answer

    • Which hosts are alive, and which ports are open on each, TCP and UDP?
    • What exact software and version is running on every open port?
    • What does each service give away without authentication: users, shares, banners, configuration?
    • For web apps, what are all the routes, parameters, roles, and API endpoints?
    • Where does the app accept input, and what does it do with it?

    Deliverables

    • Per-host service list with versions
    • Application route and parameter map
    • Enumerated users and groups
    • Screenshots of exposed interfaces

    Techniques

    Host discovery
    ICMP, ARP on local segments, and TCP probes to common ports find live hosts. Firewalls often drop ping, so do not rely on it alone.
    Full port scans
    Scan all 65,535 TCP ports at least once. Services on high ports are exactly the ones nobody hardened.
    Service and version detection
    nmap -sV and default scripts identify software and versions, which drive the next phase.
    UDP scanning
    Slow but essential. SNMP, DNS, TFTP, and IPMI on UDP regularly leak a great deal.
    Content discovery
    Wordlist-based fuzzing for directories, files, backups, and virtual hosts finds what links do not.
    Application mapping
    Walk every feature through an intercepting proxy as each role. The proxy history becomes your map of requests to test.
    JavaScript analysis
    Front-end bundles contain API routes, feature flags, and sometimes keys. Search them for paths and secrets.
    Directory services
    SMB null sessions, anonymous LDAP binds, and RPC can reveal users, groups, and password policy on Windows networks.

    Common mistakes

    • Only scanning the top 1,000 ports.
    • Running a scanner at maximum speed against fragile production systems.
    • Ignoring UDP entirely.
    • Fuzzing with one wordlist and stopping. Different stacks need different lists.

    Pro tips

    • Enumeration is where tests are won. When you are stuck, you have not enumerated enough.
    • Save every scan in all formats (nmap -oA). Grepable output makes later triage fast.
    • Revisit enumeration after every new credential or foothold. The map changes.
    Enumeration commands in the cheatsheet →
  4. 0x03

    Vulnerability Analysis

    Match versions and behavior to known weaknesses, then validate them manually to rule out false positives.

    • searchsploit
    • NVD
    • CISA KEV
    • Nuclei
    • Burp Scanner
    • sqlmap (with care)
    • testssl.sh
    • Manual testing

    Goal: Produce a list of real, validated weaknesses, each with evidence and an understanding of why it exists.

    Questions to answer

    • Do any discovered versions have public CVEs, and do they actually apply to this configuration?
    • Where does user input reach an interpreter: SQL, a shell, a template engine, an XML parser, the DOM?
    • Are authentication, session handling, and access control enforced on every request, server side?
    • What assumptions does the business logic make, and can they be broken?
    • Are there misconfigurations: default credentials, verbose errors, open storage, permissive CORS?

    Deliverables

    • Validated vulnerability list with evidence
    • False positive notes
    • Initial risk ratings
    • Candidate attack chains

    Techniques

    Version to vulnerability mapping
    Look up each version in the NVD, vendor advisories, and the CISA KEV catalog. Read the advisory to check the vulnerable configuration really applies.
    Automated scanning
    Template scanners and DAST tools cover known patterns broadly. Treat their output as leads to verify, never as findings.
    Input testing
    Probe every parameter for injection classes: SQL, command, template, XSS, path traversal, SSRF, XXE. Watch for errors, timing differences, and reflected output.
    Access control testing
    Replay requests from a high-privilege user with a low-privilege session, and change object IDs. Broken access control is the most common serious web bug.
    Authentication review
    Test password reset flows, MFA bypasses, session fixation, token expiry, and lockout behavior.
    Business logic review
    Skip steps in multi-step flows, use negative quantities, race concurrent requests, and replay one-time actions.
    Configuration review
    Check headers, TLS, CORS, cookie flags, exposed debug endpoints, and cloud storage permissions.

    Common mistakes

    • Reporting scanner output without validating it.
    • Matching a CVE on version alone when the vulnerable module or setting is not enabled.
    • Testing only as an anonymous user, missing every authorization flaw.

    Pro tips

    • Scanners find the easy 20%. Logic flaws and access control bugs need a human.
    • Ask why a bug exists. The root cause usually appears in more than one place.
    • Two accounts in two browsers is the single most productive setup for finding access control bugs.
    Web vulnerability classes explained →
  5. 0x04

    Exploitation

    Safely demonstrate that a weakness is real and show its impact, within the agreed rules.

    • Burp Repeater
    • Metasploit
    • Impacket
    • hashcat
    • John the Ripper
    • Custom PoCs

    Goal: Prove impact with the least risky method possible, so the client can prioritize fixes based on evidence instead of theory.

    Questions to answer

    • What is the least invasive way to prove this vulnerability is real?
    • Could this exploit crash the service, corrupt data, or affect real users?
    • Is this technique explicitly allowed in the rules of engagement?
    • What is the realistic business impact if an attacker did this?
    • Do I understand every line of the public exploit I am about to run?

    Deliverables

    • Evidence of impact (screenshots, request and response pairs)
    • Timestamped action log
    • Notes on attempted but unsuccessful paths

    Techniques

    Proof over damage
    Read a harmless file, run id or whoami, or retrieve a single non-sensitive record. Stop once impact is clear.
    Reviewing public exploits
    Read exploit code before running it. Public proofs of concept can be unreliable, destructive, or even backdoored.
    Credential attacks
    Password spraying and cracking captured hashes, within agreed limits so you do not lock out real accounts.
    Web exploitation
    Turn validated injection or access control flaws into a clear demonstration of what data or actions an attacker gains.
    Chaining
    Combine smaller weaknesses, such as an information leak plus an IDOR plus weak session handling, into one realistic attack path.
    Change control
    Log every action with a timestamp. If something breaks, the client needs to know exactly what you did and when.

    Common mistakes

    • Running an exploit you have not read.
    • Dumping an entire database when one row proves the point.
    • Exceeding lockout thresholds during password attacks.
    • Continuing after something breaks instead of stopping and calling the emergency contact.

    Pro tips

    • Prove impact with the least invasive method. A screenshot of access beats a crashed server.
    • Before running anything heavy, ask what happens if it fails halfway.
    • Unsuccessful attempts are findings too. They show which controls work.
  6. 0x05

    Post-Exploitation

    Assess what an attacker could reach from a foothold: privilege escalation, sensitive data, lateral paths.

    • BloodHound
    • PEASS-ng
    • GTFOBins
    • LOLBAS
    • Impacket
    • NetExec
    • Seatbelt
    • pspy

    Goal: Show the real consequence of the initial compromise, measured by how far an attacker could get and what they could touch.

    Questions to answer

    • What user am I, what privileges do I have, and what can this host reach?
    • Can I escalate to root, SYSTEM, or domain admin, and how?
    • What credentials, keys, or tokens are stored on this system?
    • Which other hosts trust this one, and which share credentials with it?
    • Where is the sensitive data the client cares most about, and can I reach it?

    Deliverables

    • Attack path diagrams
    • List of reachable sensitive assets
    • Credential exposure findings
    • Detection gaps observed

    Techniques

    Local enumeration
    Kernel and OS version, sudo rights, SUID binaries, services, scheduled tasks, writable paths, and installed software.
    Privilege escalation
    Abuse misconfigurations such as weak service permissions, sudo rules, writable cron jobs, unquoted service paths, or token privileges.
    Credential harvesting
    Config files, environment variables, shell history, browser stores, and memory frequently contain reusable secrets.
    Active Directory path analysis
    Collect relationships with BloodHound and look for the shortest path from your user to high-value groups.
    Lateral movement
    Reuse found credentials across hosts and protocols such as SMB, WinRM, SSH, and RDP to expand access within scope.
    Cloud pivoting
    Instance metadata, attached roles, and stored cloud keys can turn a single host into account-wide access.
    Persistence (only if agreed)
    Some engagements test detection of persistence. Never install it without explicit permission, and document it for removal.

    Common mistakes

    • Stopping at a low-privilege shell and calling it done.
    • Copying sensitive data off the network when proving access was enough.
    • Leaving tools, accounts, or persistence behind.

    Pro tips

    • Document the attack path as a chain. Chained low-severity issues often equal a critical one.
    • Check whether the blue team noticed anything. Detection gaps are valuable findings.
    • Credential reuse is the most common lateral movement path in real breaches. Test it.
    Graphs and attack paths →
  7. 0x06

    Reporting & Cleanup

    Remove any artifacts you created, then deliver clear findings with evidence, risk ratings, and fixes.

    • CVSS calculator
    • ATT&CK Navigator
    • Report template
    • Screenshot and evidence tooling

    Goal: Leave the environment as you found it and hand over a report that gets the right things fixed in the right order.

    Questions to answer

    • Have I removed every file, account, and configuration change I made?
    • Can an executive understand the overall risk from the first page alone?
    • Can an engineer reproduce and fix each finding from its write-up alone?
    • Are severity ratings consistent and justified by real impact and likelihood?
    • What should the client fix first, and what will retesting look like?

    Deliverables

    • Final report
    • Cleanup confirmation
    • Raw evidence archive (encrypted)
    • Debrief presentation
    • Retest plan

    Techniques

    Cleanup checklist
    Walk your action log and reverse each change: uploaded files, created users, modified settings, scheduled tasks. Note anything you could not remove.
    Executive summary
    One page in plain language: what was tested, the overall posture, the most serious risks, and the top recommendations.
    Finding write-ups
    Each finding gets a title, severity, affected assets, description, step-by-step reproduction, evidence, impact, and specific remediation.
    Risk scoring
    Use CVSS for a consistent technical baseline, then adjust priority with business context.
    Attack narrative
    Tell the story of the most significant attack chain from start to finish. It shows why individual findings matter together.
    Mapping to frameworks
    Mapping techniques to MITRE ATT&CK helps defenders build detections for exactly what you did.
    Debrief and retest
    Walk the client through the results, answer questions, and agree on a retest once fixes are in.

    Common mistakes

    • Rating everything critical. If everything is urgent, nothing is.
    • Generic remediation like apply best practices instead of specific steps.
    • Leaving sensitive evidence unencrypted on a laptop after the engagement.
    • Writing only for engineers or only for executives.

    Pro tips

    • The report is the product. Write it for two readers: executives and engineers.
    • Write findings as you go. Reconstructing them from memory at the end produces worse reports.
    • Include what went well. It tells the client which investments are working.
    Score findings with the CVSS calculator →