Red Team Reporting: The Document IS The Product

Level: All Levels

The Harsh Truth

You can be the greatest hacker in the world. You can write custom zero-day exploits, bypass the most advanced EDRs, and domain admin the entire Fortune 500.

But if your report sucks, you failed.

The report is the only tangible thing the client pays for. It is the artifact that stays behind after you disconnect your C2. It is the document that the CISO takes to the Board of Directors to ask for budget.

If your report is just a dump of tool output, you are a script kiddie, not a professional.

The Two Audiences

A Red Team report has a split personality. It must speak to two radically different groups simultaneously.

1. The Executive (The "So What?")

They will read exactly one page: The Executive Summary. They care about: * Risk: Did you access the money/data? * Impact: What would this cost us in a real attack? * Strategic Fixes: Do we need more people? Better tools? A culture change?

Bad Executive Summary:

"We found 14 instances of MS17-010 and exploited SMBv1 using EternalBlue."

Good Executive Summary:

"The Red Team successfully accessed the Customer Billing Database within 4 hours. This was possible because legacy systems in the Finance network were missing critical updates, allowing us to bypass authentication. This path demonstrates a high risk of ransomware capable of halting payment processing."

2. The Engineer (The "How?")

They will read the Technical Narrative and Findings. They care about: * Reproduction: Exact commands to reproduce the issue. * Evidence: Screenshots, logs, HTTP requests. * Remediation: Specific config changes or patches.

structure of a Killer Report

The Attack Narrative

Don't just list vulnerabilities (Finding 1, Finding 2). Tell the story. Chronological order is key.

t+00:00 - Attackers launched phishing campaign. t+04:00 - User J.Doe clicked the link. t+04:15 - Beacon established on workstation. t+06:00 - Attackers harvested credentials from LSASS.

This helps the Blue Team cross-reference their logs. "Ah, at 4:15 PM we saw a weird HTTPS connection. We missed it then, but now we know what to look for."

The Finding Block

Every technical finding needs: 1. Severity: Critical/High/Medium/Low (Use a standard like CVSS, but adjust for context). 2. Affected Hosts: IP addresses / Hostnames. 3. Description: What is the issue? 4. Proof of Concept: The screenshot of the shell, the dumped hash, the sensitive file. 5. Remediation: "Disable NTLMv1" or "Apply Patch KB123456".

The "Tone" of the Report

Arrogance is forbidden. Avoid language like "The security team failed to detect..." or "It was trivial to bypass..."

Use professional, objective language: * "The Red Team observed that alerts were not triggered..." * "Using open-source tooling, access was obtained..."

Remember, the person reading this report (the Blue Team manager) might be fearing for their job. If you humiliate them, they will bury your report and fix nothing. If you help them, they will hire you again.

Debriefing

The report delivery should always be accompanied by a meeting (The Debrief). Walk through the attack. Show the demos. Answer questions. Ideally, hold a separate Technical Workshop with the defenders to replay the attack and help them build the detection rules live.

That is how you turn a PDF into a security upgrade.