Evidence and reporting discipline that runs alongside the whole assessment, not at the end. The deliverable is a professional report; SysReptor is the tool that produces it. This page is the workflow and the trackers — capture as you go, and writing the report becomes assembly instead of archaeology.

The expensive failure mode is reaching domain dominance with no clean proof of how you got there. Capture evidence the moment something works. Re-creating it later costs far more time than capturing it now.

🛡️ Methodology Checklist

  • One evidence folder per host, created the moment you touch the host
  • Terminal output logged continuously (don’t rely on scrollback)
  • Screenshot every successful step with a consistent name
  • Each finding tracked with a status from identified → reviewed
  • Every manual 📝 Reporting Trigger used reused as a finding draft
  • Attack path narrative reconstructable from evidence alone
  • Report-readiness checkpoints cleared before calling it done

📂 Evidence Discipline

Folder structure & evidence discipline are canonical in Reporting_Documentation — the standard engagement folder layout (Admin/Deliverables/Evidence/{Findings,Scans,Notes,…}/Retest), the investigation notes, continuous tmux logging, and the Activity/Payload/System-Modification trackers all live there. This page is the SysReptor production workflow that sits on top of that evidence.

The one rule that makes this page work: per successful step, capture three things — the exact command, its output, and a screenshot (YYYY-MM-DD_HHMM_[HOST]_[FINDING]_desc.png). For web findings, also save the raw request/response. Capture in the moment; scrollback is not evidence.

🗃️ Findings Tracker

Keep this current as you work — it is the spine of the report (the 12. Findings note from Reporting_Documentation). Status lifecycle: identified → evidence-captured → written → reviewed. The first row is an example; replace it. Copy into your working notes (Obsidian / SysReptor):

| ID | Title | Host / scope | Severity | Status | Evidence folder |
|----|-------|--------------|----------|--------|-----------------|
| F-001 | Kerberoasting — weak service-account password | db01 / svc_sql | High | evidence-captured | Evidence/Findings/F-001 - Kerberoasting/ |
| F-002 |  |  | Critical/High/Med/Low/Info | identified | Evidence/Findings/F-002 - …/ |

🔁 From Manual Page to Finding

Most technique pages in this manual end with a 📝 Reporting Trigger block — that block is a finding draft. It already gives you the four fields a report finding needs:

Reporting Trigger fieldSysReptor finding field
Finding TitleTitle
ImpactImpact / risk
Root CauseDescription / root cause
RecommendationRemediation

So the flow is: used a technique → open its manual page → copy the Reporting Trigger → paste into a SysReptor finding → attach your captured evidence → set severity. See also Reporting_Findings_Types, Reporting_Documentation, and Report_Writing for assembling the full report.

Don’t start from scratch — Finding_Library holds a reusable set of these findings already in SysReptor finding-template field structure (title, CVSS baseline, summary, impact, affected components, recommendation, references), each linked back to its manual page. Create them once in SysReptor, reuse them every engagement.

🧱 SysReptor Workflow

  1. One project per engagement. Pick a report design up front so section structure is fixed early. Designs live under the Designs menu — a demo design ships by default; import more (e.g. the OffSec-Reporting repo) via Designs → Import from file, then choose your design when you create the project.
  2. Draft findings as you go, not at the end — paste from the Reporting Trigger, attach evidence, justify severity (CVSS where the design expects it).
  3. Write the attack-path narrative as a running story: initial access → each escalation → domain dominance, each step pointing at its finding and evidence. See Report_Writing for the narrative → bullet-flow → per-step-evidence structure.
  4. Appendices: full host list, command log / compromise walkthrough, and the dynamic appendices (payloads, compromised credentials, configuration changes, domain password analysis) — templates in Report_Writing.
  5. Export to the deliverable format once the readiness checkpoints below pass.

✅ Report-Readiness Checkpoints

Per finding:

  • Evidence is complete and legible (command + output + screenshot)
  • Reproduction steps are written and would work for a third party
  • Severity is set and justified
  • Remediation is specific and actionable

Whole report:

  • Executive summary written for a non-technical reader
  • Attack-path narrative reconstructable from evidence alone
  • Scope and methodology stated
  • Every objective / flag is backed by evidence
  • Consolidated remediation guidance present
  • No raw credentials or sensitive client data left in screenshots/appendices

🔗 Related Nodes