Red Teaming 101: Master Index

BLUF: This series provides a structured roadmap for transitioning from traditional penetration testing to advanced red team operations using the Harada OW64 methodology.

Master OW64 Grid — Harada Mandala Chart

Operational Overview

graph TB
    Goal((Red Team Operator))
    style Goal fill:#ff6600,stroke:#333,stroke-width:4px

    subgraph P1[Linux]
        L1[Enumeration]
        L2[PrivEsc]
        L3[Persistence]
    end

    subgraph P2[Windows/AD]
        W1[BloodHound]
        W2[Kerberoasting]
        W3[Trusts]
    end

    subgraph P3[Web]
        WB1[Recon & Enum]
        WB2[Injection & Auth]
        WB3[API & SSRF]
    end

    subgraph P4[Network]
        N1[Tunneling]
        N2[Pivoting]
        N3[Segmentation]
    end

    subgraph P5[Cloud]
        CL1[IAM/Identity]
        CL2[Azure/AWS]
        CL3[Serverless]
    end

    subgraph P6[EDR]
        E1[AV/AMSI]
        E2[ETW/Unhooking]
        E3[Syscalls]
    end

    subgraph P7[C2]
        C1[Frameworks]
        C2[Redirectors]
        C3[Covert Channels]
    end

    subgraph P8[Reporting]
        R1[Technical]
        R2[Executive]
        R3[Portfolio]
    end

    Goal --- P1
    Goal --- P2
    Goal --- P3
    Goal --- P4
    Goal --- P5
    Goal --- P6
    Goal --- P7
    Goal --- P8

Execution Model

Daily Micro-Practice (30–60 min total):

• 1 task from Pillar 1: Linux
• 1 task from Pillar 2: Windows/AD
• 1 task from Pillar 3: Web

Rotating Deep Pillar (60–120 min — pick one per day):

Progress Tracking

Prerequisites

Before starting this series, ensure you are comfortable with the concepts in the Recon series:

• 1. External Recon
• 2. Internal Recon (No Creds)
• 3. Authenticated Pivot
• 4. C2 & SOCKS
• 7. Blue Team Detection
• 9. Detection Event IDs (Splunk)

Navigation

AI Usage

Good uses:

• Generate code scaffolding and boilerplate
• Summarize research papers and CVEs
• Generate payload variants for testing
• Draft initial report sections

Bad uses (avoid):

• Letting AI solve labs for you (you learn nothing)
• Copy/pasting exploits without understanding them
• Using AI as a crutch instead of building intuition

Career Progression

What Elite Firms Look For :

• Custom tooling that bypasses "off-the-shelf" detections
• Deep Windows/Linux internals knowledge (APIs, Syscalls, Kernel)
• Purple team mindset — help Blue Team improve, not just "win"
• Publicly demonstrable thinking (writeups, tools, research)

Portfolio Reminder

Red Team 101 — Operational Doctrine

BLUF: Technical skill is table stakes. What separates an operator from a hobbyist is how they plan, document, communicate, and manage risk throughout an engagement.

Pre-Ops: Planning & Authorization

Nothing executes without paper. If you don't have written authorization you are committing a crime, not running a red team engagement.

Required Before Day 1:

RoE Must Explicitly Address:

• Goals / Objectives — Crown jewels, specific flags, detection testing
• Constraints — No DDoS, no destructive actions, no production DB writes
• Off-Limits — Named systems, subnets, third-party hosted services
• Working Hours — Active ops window (e.g., 09:00–17:00 local or 24/7)
• Escalation Path — Who approves going out-of-scope if an opportunity arises
• Get-Out-of-Jail Contact — Single POC who can authorize you to law enforcement on the spot

Op Plan

Sections:

1. Objective — What does success look like? (e.g., "Achieve DA without triggering a SOC alert")
2. Target Profile — Known intel: tech stack, AV/EDR, network segmentation, users
3. Phasing — Recon → Initial Access → Post-Ex → Lateral Movement → Objectives → Reporting
4. TTP Selection — Specific techniques planned per phase, mapped to MITRE ATT&CK
5. Contingency — What happens if you get caught? How do you re-establish access?
6. Exit Criteria — When do you stop?

Infrastructure

Standard Red Team Infra Stack:

Infrastructure Rules:

• Separate infrastructure per engagement — no cross-contamination
• Age domains weeks in advance and warm up with legitimate traffic
• Use IaC (Terraform + Ansible) to provision and teardown quickly
• Never expose the team server IP directly — always behind a redirector
• Document every IP, domain, credential, and port used — add to op notes

Workstation Hardening (Assessment Laptop)

Your laptop is the most sensitive device in the engagement. If it's compromised or stolen, the client's network is compromised too.

OS & Build:

• Use a dedicated assessment OS — don't dual-purpose your daily driver. Kali, ParrotOS, or a hardened Debian/Ubuntu install
• Full disk encryption (LUKS on Linux) — enabled before anything else. No exceptions

  Why "before anything else": Once loot, creds, SSH keys, C2 configs, or VPN profiles are written to an unencrypted disk you can't retroactively protect them. A lost or seized laptop becomes full compromise of the client environment — your C2 keys, their credentials, and your entire op are readable by whoever has the machine. "No exceptions" because the usual exception is convenience, which is not an acceptable risk when you're carrying client crown jewels.

• Auto-lock on screen after ≤ 5 minutes of inactivity; require password to unlock
• Keep the OS and all tools fully patched before each engagement
• Disable Bluetooth when not in use; disable USB auto-mount to prevent accidental execution from dropped drives

How to:

# Enable LUKS full-disk encryption during OS install (Kali/Ubuntu installer — check "Encrypt" option)
# Or encrypt an existing partition post-install:
cryptsetup luksFormat /dev/sdX
cryptsetup luksOpen /dev/sdX encrypted_vol

# Auto-lock (GNOME)
gsettings set org.gnome.desktop.session idle-delay 300
gsettings set org.gnome.desktop.screensaver lock-enabled true

# Patch before engagement
sudo apt update && sudo apt full-upgrade -y

# Disable Bluetooth
sudo systemctl disable bluetooth --now

# Disable USB auto-mount (GNOME)
gsettings set org.gnome.desktop.media-handling automount false

Compartmentalization:

• Run each engagement in an isolated VM — take a snapshot before connecting to the client environment
• Use separate browser profiles (or separate browsers) for: client portals vs. personal vs. research
• Keep loot and client data inside the engagement VM only — never copy to the host
• Use VPN from the host before the VM connects out — adds a layer of separation from your real IP

How to:

# Create a new KVM/QEMU VM for the engagement (or use VirtualBox)
virt-manager  # GUI — create new VM, allocate disk, take snapshot before connecting

# VirtualBox snapshot before connecting to client
VBoxManage snapshot "EngagementVM" take "pre-client-connect" --description "Clean state"

# Verify VPN is up on host BEFORE starting VM
curl ifconfig.me  # confirm you're hitting VPN exit IP, not home ISP

Network Discipline:

• Use a dedicated SIM / mobile hotspot for engagements — your home ISP appears in OSINT
• Connect to the client environment only through agreed VPN or jump server — never direct from your laptop IP
• Kill split tunneling on your VPN — all traffic should route through the tunnel when connected
• Use DNS over HTTPS or DNSSEC to prevent local DNS leakage during recon

How to:

# Verify no split tunnel — all traffic should exit VPN
ip route show   # default route should point to tun0/wg0, not eth0/wlan0

# Check for DNS leakage
cat /etc/resolv.conf          # should show VPN DNS, not home router
dig +short myip.opendns.com @resolver1.opendns.com   # verify exit IP

# Enable DNS over HTTPS (systemd-resolved)
sudo nano /etc/systemd/resolved.conf
# Set: DNS=1.1.1.1  DNSOverTLS=yes
sudo systemctl restart systemd-resolved

Credential & Key Hygiene:

• Store all credentials, SSH keys, and API tokens in a password manager (Bitwarden, KeePassXC) — not in plaintext files or shell history
• Use a unique SSH keypair per engagement — rotate and destroy at engagement close
• Never save client credentials in the browser or SSH known_hosts on the host — put them inside the engagement VM
• Set HISTFILE=/dev/null or export HISTCONTROL=ignorespace in your shell to suppress logging of sensitive commands

How to:

# Generate a per-engagement SSH keypair
ssh-keygen -t ed25519 -C "eng-clientname-2026" -f ~/.ssh/id_eng_clientname

# Suppress shell history for the session
unset HISTFILE
# Or prefix sensitive commands with a space (requires HISTCONTROL=ignorespace in .bashrc)
export HISTCONTROL=ignorespace

# Destroy keypair at engagement close
shred -u ~/.ssh/id_eng_clientname ~/.ssh/id_eng_clientname.pub

# Wipe known_hosts entries for client hosts
ssh-keygen -R <client-ip>

Physical Security:

• Never leave your laptop unattended and unlocked in any client facility
• Use a privacy screen filter when working in client offices or public spaces
• If your laptop is lost or stolen during an engagement, treat it as a breach — notify the client immediately and initiate their incident response process

Risk Management

Risk-Adverse Mindset:

• Always prefer reversible actions over destructive ones
• Test exploits in your lab first — never run untested code against production
• Before running any command that modifies state, ask: Can I undo this?
• If you break something, stop immediately, document exactly what happened, notify the client POC

Attack vs. Defend Mindset:

Knowledge Management

What to Capture:

• Op Notes — Real-time operational log (see below)
• Loot — Credentials, hashes, tickets, keys, sensitive files — organized and indexed
• Screenshots — Every significant finding, timestamped and annotated
• Network Maps — Running diagram of discovered hosts, subnets, and pivot paths
• Tool Configs — Save exact configurations used (C2 profiles, Ansible playbooks)

Repository & Data Transfer Plan:

• Use an encrypted, access-controlled repo (private GitHub or self-hosted Gitea)
• Use SCP / SFTP over SSH to transfer loot — never plain HTTP or email
• Define a data transfer plan in the op plan: how is loot moved, stored, and destroyed
• Client data must be securely deleted per SoW at engagement close

Op Notes

Op notes are your real-time log. They are the source of truth for the final report and any deconfliction.

Every Entry Must Include:

[TIMESTAMP UTC]  ACTION
Command:   <exact command run>
Target:    <IP / hostname / URL>
Result:    <exact output or summary>
Artifacts: <file dropped, service created, key used, etc.>
Screenshot: <filename or link>
Note:      <why you did this / what you expected vs got>

Op Note Discipline:

• Log before you execute — note your intent
• Copy exact commands — never paraphrase
• If something fails or behaves unexpectedly, log it in full
• Use a dedicated tool: CherryTree, Obsidian (this vault), or a timestamped Markdown file
• Back up op notes to the encrypted repo at the end of every session

Analyst Journal (Narrative Log)

Separate from op notes — a narrative account written in past tense. This is the raw material for the attack narrative in the final report.

Journal Format:

[DATE TIME UTC] — Narrative sentence describing what happened and why.

Example:
[2026-03-08 14:32 UTC] — Performed Kerberoasting against all SPN accounts.
Identified svc_sql with RC4 encryption. Hash cracked in 4 minutes via rockyou.txt.
Used resulting credential to authenticate to SQL01 as a domain user.

Journal vs Op Notes:

TTPs

Document every TTP used. This drives the MITRE ATT&CK mapping in the final report and helps the blue team build detections.

TTP Log Format:

TTP Discipline:

• Maintain the TTP log throughout the engagement — do not reconstruct from memory later
• Every technique maps back to a specific op note entry
• Flag any TTP where an alert was or was not triggered — feeds the detection gap analysis

Reporting Cadence

Daily Sitrep Template:

Date:             [DATE]
Operator:         [NAME]
Objective Today:  [WHAT YOU PLANNED]
Accomplished:     [WHAT YOU DID]
Systems Accessed: [IP / HOSTNAME LIST]
Findings:         [NEW FINDINGS SUMMARY]
Blockers:         [ANYTHING STOPPING PROGRESS]
Plan Tomorrow:    [NEXT STEPS]
Risk Items:       [ANYTHING NEEDING CLIENT ATTENTION]

Mishap Report Triggers — Stop and report immediately if you:

• Caused an unintended service disruption or outage
• Accessed a system marked off-limits
• Exfiltrated data beyond what was agreed
• Triggered a security response not part of the engagement exercise
• Lost control of a payload or implant

Post-Engagement Debrief

Cleanup Checklist:

• All implants / beacons killed and removed from target systems
• All created accounts, services, and scheduled tasks removed
• Infrastructure torn down (or isolation confirmed if retained)
• All loot / client data securely wiped per SoW
• Final report delivered and walkthrough scheduled
• Lessons-learned documented internally

Debrief Meeting Agenda:

1. Walk the client through the attack narrative — show the path, not just the findings
2. Demonstrate key findings with live reproduction (if safe)
3. Map each finding to a defensive control that would have blocked or detected it
4. Discuss detection gaps identified from the TTP log
5. Agree on a remediation timeline