Findings documentation¶

The Assassins’ Guild has a saying: an inhumation that cannot be documented never happened. Mr. Teatime brought this philosophy to red team reporting. A vulnerability found and not clearly communicated is a vulnerability that may not get fixed, and a vulnerability that does not get fixed might eventually be discovered by someone who does not announce their presence at all. The engagement report is, therefore, not an administrative afterthought. It is the product.

Report structure¶

Every engagement produces a report with the following sections, in this order.

Executive summary: two pages maximum. Written for Adora Belle and the Royal Bank liaison, not for technical staff. Describes what was tested, what was found at a high level, what the business risk is, and what the overall assessment is (“Red team achieved objective”, “Blue team successfully defended”, “Partial success: red team reached staging, not production”). Adora Belle reads the executive summary. The rest of the report is read by Carrot and Angua.

Methodology: how the engagement was conducted. Engagement type, duration, tools used, team members involved, starting conditions (external attacker, assumed breach, etc.). This section does not describe findings; it provides context for them.

Findings: the core of the report. Each finding is documented in a standard format (see below). Findings are ordered by severity: Critical, High, Medium, Low, Informational. Within each severity level, findings are ordered by the stage of the kill chain at which they appear (initial access findings before lateral movement findings, and so on).

Attack narrative: a chronological account of what the red team did and when, from first action to engagement end. Written as a story, not a findings list. The narrative shows how individual findings chain together into an attack path. Even a finding that is individually rated Medium may appear Critical in the narrative if it was the necessary link between two more severe steps.

Indicators of compromise: all IP addresses, domain names, file hashes, user agents, and other technical indicators generated by the red team during the engagement. These are imported into MISP as a red team exercise event (tagged tlp:red and golemtrust:exercise) so that they can be excluded from real threat intelligence.

Recommendations: prioritised list of remediations. Each recommendation references one or more findings, specifies an owner (infrastructure, application, SOC, HR for training-related findings), and suggests a target timeline consistent with the finding severity SLAs.

Finding format¶

Each finding uses this template:

## Finding RT-2025-Q4-003: Cached SMB credentials enabled lateral movement

Severity: High
Affected system: staff workstation fleet (Windows), specifically sam-vimes-jr-ws01
ATT&CK technique: T1550.002 Pass the Hash
CVSS: 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

### Evidence
Screenshot: [attachment: rt-2025-q4-003-screenshot-01.png]
Zeek log excerpt showing SMB authentication attempts at 10:47:
  [log excerpt in code block]

### Attack path
1. Sam Vimes Jr. clicked phishing link; sandcat agent installed.
2. Agent extracted NTLM hash from LSASS process memory.
3. Hash used to authenticate to file server fs01.internal without knowing plaintext password.
4. File server had mapped drive to payments-prep share.

### Recommendation
Enable Windows Defender Credential Guard on all workstations to prevent
LSASS memory extraction. Apply within 30 days (High severity SLA).
Owner: Infrastructure team (Ponder).

DefectDojo integration¶

Red team findings are imported into DefectDojo as a separate product named “Red Team Assessments”. This product is distinct from the vulnerability management product that handles scanner findings.

The import uses DefectDojo’s generic findings format. Mr. Teatime’s team runs the import after each engagement:

curl -X POST https://defectdojo.golemtrust.am/api/v2/import-scan/ \
  -H "Authorization: Token DEFECTDOJO_API_KEY" \
  -F "scan_type=Generic Findings Import" \
  -F "file=@/tmp/rt-2025-q4-findings.json" \
  -F "product_name=Red Team Assessments" \
  -F "engagement_name=Q4 2025 Full Scope Pentest" \
  -F "verified=true" \
  -F "active=true"

The findings JSON format for DefectDojo:

{
  "findings": [
    {
      "title": "Cached SMB credentials enabled lateral movement",
      "date": "2025-12-10",
      "severity": "High",
      "description": "...",
      "mitigation": "...",
      "impact": "...",
      "references": "T1550.002",
      "active": true,
      "verified": true,
      "false_p": false,
      "duplicate": false,
      "out_of_scope": false,
      "cve": null
    }
  ]
}

Detection gap classification¶

Findings in DefectDojo carry a custom field: finding_type. Two values are used:

• vulnerability: a technical weakness in a system (missing patch, misconfiguration, weak credential)

• detection_gap: an attacker action that was not detected by the blue team

Detection gap findings are labelled separately because they have different remediation paths. A vulnerability is fixed by the infrastructure or application team. A detection gap is addressed by Angua, through new or improved detection rules. Tracking both types separately allows the quarterly report to Adora Belle to show progress on both axes: are vulnerabilities being fixed, and is detection coverage improving?

First engagement findings summary¶

The Q3 2025 engagement produced five findings:

Findings 004 and 005 are Informational because they represent controls that worked. The engagement report documents what worked as well as what failed; a blue team that only hears about failures loses the ability to understand which controls are load-bearing.

Embargo policy¶

Engagement reports are classified as confidential for 30 days after the remediation deadline of the highest-severity finding. This embargo exists to protect the remediation timeline: if a Critical finding with a 7-day SLA is fixed on day 5, the report remains confidential until day 37. The rationale is that publishing a report that describes a recently-fixed vulnerability, before confirming the fix is fully deployed, creates an unnecessary window.

After the embargo period, reports are stored in the security team’s GitLab repository at security/red-team/reports/YYYY-QN-report.pdf, accessible to Carrot, Adora Belle, Mr. Teatime, and Angua.