Cybrary ForgeCYBRARY / FORGE
Forge Offensive · Methodology

How we run a pentest

Forge Offensive follows the same spine as a professional engagement: agree the rules, map the surface, prove the risk with the least force necessary, then hand over a report someone can act on. Every phase below names the deliverable it must produce and the simulated labs that teach it. Nothing real executes at any point.
Phases
5
Deliverables
5
Offensive labs
10
Real packets
0

The engagement spine

  1. 1 · Pre-engagement and scope

    Nothing starts until the scope is locked. Targets, windows, excluded systems and the rules of engagement are agreed before a single packet (simulated or otherwise) is sent.

    • Define in-scope ranges, hosts and cloud accounts — and what is explicitly out
    • Set the testing window and any no-go actions (no DoS, no exfil of real data)
    • Record it all on the engagement so the range can flag scope violations for you
  2. 3 · Exploitation and initial access

    Prove the risk with the least force necessary. One supervised exploit against a stale service, one phish against an authorized audience, one crack of a captured handshake — then stop and document.

    • Exploit only what the ROE names, under supervision
    • Capture proof (session, screenshot-equivalent, loot record) at the moment of access
    • Note every defensive gap you notice — the blue mirror is watching too
  3. 4 · Post-exploitation and lateral movement

    From the foothold, answer the question the customer actually asked: how far could this go? Read the attack graph before you move, walk the shortest path, and record every hop.

    • Read /pentest/attack-graph before touching credentials
    • Kerberoast, DCSync and AssumeRole chains executed deliberately, one hop at a time
    • Track beacons, tasks and loot in the C2 console, scoped to the range or scenario
  4. 5 · Reporting and handover

    The deliverable is the product. Every finding carries a CVSS 3.1 vector, evidence, and a remediation a real engineer can action. The engagement exports as a report, not a memory.

    • File each finding as you go — score, evidence, remediation — never at the end
    • Tag web findings with their OWASP Top 10 category
    • Export the report from the engagement and walk the customer through it

Deliverables

An engagement that ends without these five artifacts did not happen.

  • Rules of engagement

    The signed contract: scope blocks, testing windows, excluded systems and escalation contacts. The engagement enforces it — scan outside scope and the violation is recorded on the report.

  • Findings register

    One row per finding: title, affected host or URL, CVSS 3.1 vector and score, reproduction evidence, and a remediation written for the person who has to fix it.

  • Kill-chain timeline

    Every simulated tool run lands on the engagement timeline in order, so the customer can see not just what was found but how the attack actually unfolded.

  • Detection-gap appendix

    What the blue side saw and missed. Blue-mirror verdicts and purple-team replays turn each attack step into a concrete detection recommendation.

  • Exportable report

    The print-ready engagement report: scope, findings with scores, timeline, and remediation priorities. The thing a real engagement lives or dies on.

Put it into practice

Start an engagement, then run the labs against it — tool activity flows into the kill-chain timeline and findings land on the report.

Every host, credential and target referenced here is simulated. The methodology is the real thing.