Learn Ethical Hacking (#50) - Red Team Operations - Simulating Real Attacks

avatar

Learn Ethical Hacking (#50) - Red Team Operations - Simulating Real Attacks

leh-banner.jpg

What will I learn

  • What red teaming is and how it differs from penetration testing;
  • Red team planning -- rules of engagement, scope, objectives, and the attack plan;
  • The kill chain -- mapping red team operations to the Lockheed Martin Cyber Kill Chain and MITRE ATT&CK;
  • Adversary emulation -- simulating specific threat actors (APT29, FIN7, Lazarus) with their actual TTPs;
  • Operational security (OPSEC) -- staying undetected while operating inside a target network;
  • Command and Control (C2) -- managing implants, redirectors, and communications infrastructure;
  • Purple teaming -- collaborative exercises where red and blue teams work together;
  • Defense: threat-informed defense, detection engineering, adversary emulation plans.

Requirements

  • A working modern computer running macOS, Windows or Ubuntu;
  • Strong understanding of episodes 1-49 (this episode ties everything together);
  • Familiarity with exploitation frameworks from Episode 41;
  • The ambition to learn ethical hacking and security research.

Difficulty

  • Advanced

Curriculum (of the Learn Ethical Hacking Series):

Learn Ethical Hacking (#50) - Red Team Operations - Simulating Real Attacks

Solutions to Episode 49 Exercises

Exercise 1: Hong Kong deepfake video call heist analysis.

Source material: public video of CFO and colleagues from corporate
  presentations, earnings calls, and LinkedIn video posts.
Participants faked: 4-6 people on a multi-person video call, all
  deepfaked simultaneously in real-time.
Victim's verification: joined the VIDEO CALL specifically to verify
  identity. Saw familiar faces and heard familiar voices. Considered
  this sufficient verification.
Why it failed: video + voice are no longer proof of identity.
  The victim verified through the SAME channel the attack used.

Prevention:
- Callback to known phone number (out-of-band)
- Code word challenge
- Multi-signatory approval (no single person authorizes $25M)
- In-person verification for amounts above threshold

The Hong Kong case is the most important deepfake case study to date because the victim did everything conventional security wisdom told him to do. He was suspicious. He demanded video verification. He saw multiple familiar faces. And he still lost $25.6 million -- because "see the person's face" stopped being proof of anything the moment real-time deepfake tools became good enough to run on consumer hardware during a standard video call.

Exercise 2: Deepfake-resistant wire transfer protocol.

For transfers >$50,000:

1. Request received (any channel) -> logged in ticketing system
2. Requester identity verified via SEPARATE channel:
   - If request by email -> verify by phone (known number)
   - If request by phone -> verify by encrypted Slack DM
   - If request by video -> verify by in-person meeting
3. Challenge-response: requester must provide this quarter's
   code word (rotated quarterly, distributed in person only)
4. Dual authorization: two authorized signers must independently
   verify and approve
5. Cooling period: 24-hour delay for transfers >$200,000
   (allows time for second thoughts or fraud detection)
6. In-person only: transfers >$1,000,000 require physical
   presence of both signers with government-issued ID

No single channel, no single person, no single verification step.

The key design principle: defense in depth applied to business processes, not just network architecture. Every security layer we've discussed in 49 episodes (firewalls, IDS, WAFs, EDR) is a technical implementation of "don't trust any single control." That same principle works for financial authorization. No single channel. No single person. No single verification step. A deepfake can impersonate a voice, a face, and a writing style simultaneously -- but it cannot produce a code word it doesn't know, and it cannot impersonate two people through two independent channels at the same time.

Exercise 3: AI text detection test.

Results with GPTZero:
  Human-written:       98% human (correct)
  AI-generated:        12% human / 88% AI (correct)
  AI-generated + edit: 67% human / 33% AI (partially fooled)

Implication: light editing of AI text defeats most detectors.
A phishing email generated by AI and tweaked by a human would
pass detection. AI text detection is not a reliable defense
against AI-powered social engineering.

The implication for email security is stark: if you were hoping AI text detection would help your email gateway catch AI-generated phishing, the answer is no. A competent attacker who generates 500 personalized phishing emails and spends 10 seconds editing each one (changing a word here, adjusting a phrase there) will sail past every text detection tool. Detection tools are looking for statistical patterns in word choice and sentence structure -- patterns that disappear the moment a human touches the output. The only reliable defenses remain procedural: FIDO2 keys that refuse to authenticate on phishing domains, callback verification, and process controls that don't depend on the recipient's ability to tell real from fake.

Learn Ethical Hacking (#50) - Red Team Operations - Simulating Real Attacks

Episode 49 covered deepfakes and AI deception -- the technologies that have fundamentally broken the trust model human communication relied on since the beginning of civilization. We walked through voice cloning (from 20 hours of studio recordings in 2018 to 3 seconds of reference audio in 2025), real-time video deepfakes on video calls (including the $25.6 million Hong Kong heist where every single person on the call was fake), AI-generated spear phishing at scale (500 perfectly personalized emails for five dollars), synthetic identity fraud (AI-generated people who pass KYC checks), and the procedural defenses that still work regardless of how good the deepfakes get -- code words, out-of-band verification, multi-person authorization, and cryptographic identity proof. The core takeaway: anything based on "does this look/sound/read like the right person" is broken. Only shared secrets, cryptographic keys, and independent channel verification remain viable.

Today is episode 50. We've spent 49 episodes building individual skills: web attacks, network exploitation, privilege escalation, cloud security, social engineering, exploit development, reverse engineering, deepfake awareness, and insider threat detection. Each of those was a single tool in the toolkit.

Red teaming is where you use the entire toolkit at once ;-)

Here we go.

Red Team vs Penetration Test -- The Distinction That Matters

These two terms get used interchangeably in the industry and it drives me absolutely bonkers. They are fundamentally different things with different goals, different scopes, and different value propositions:

#!/usr/bin/env python3
"""engagement_comparison.py -- red team vs pentest side by side"""

ENGAGEMENT_TYPES = {
    'penetration_test': {
        'scope': 'Specific systems or applications',
        'goal': 'Find as many vulnerabilities as possible',
        'duration': '1-2 weeks',
        'stealth': 'Not required (blue team knows it is happening)',
        'output': 'Vulnerability report with severity ratings',
        'question_answered': (
            'How many holes does this application have?'
        ),
        'phases_covered': 'Typically kill chain phases 2-5 only',
        'cost_range': '$15,000 - $50,000',
        'frequency': 'Quarterly to annually',
    },
    'red_team_engagement': {
        'scope': 'The entire organization (people + process + tech)',
        'goal': 'Achieve specific objectives (exfil CEO email, '
                'prove ransomware deployment, access financial DB)',
        'duration': '2-6 weeks (sometimes months)',
        'stealth': 'Required -- blue team does NOT know',
        'output': 'Attack narrative showing complete kill chain',
        'question_answered': (
            'Can a real attacker achieve this objective, '
            'and would our defenses detect and stop them?'
        ),
        'phases_covered': 'All 7 kill chain phases, end to end',
        'cost_range': '$50,000 - $250,000+',
        'frequency': 'Annually to bi-annually',
    },
}

for eng_type, details in ENGAGEMENT_TYPES.items():
    label = eng_type.replace('_', ' ').title()
    print(f"=== {label} ===")
    for key, val in details.items():
        key_label = key.replace('_', ' ').title()
        print(f"  {key_label}: {val}")
    print()

# The key difference in one sentence:
# A pentest finds bugs. A red team tests whether your
# organization can survive a determined, skilled attacker.

A pentest says "your web application has 14 vulnerabilities, 3 of which are critical." A red team says "we started with a phishing email to your HR department (episode 39), used the credentials we harvested to access the VPN (episode 17), escalated privileges on a domain-joined workstation (episode 32), moved laterally to the domain controller (episode 34), and exfiltrated your entire customer database -- and your SOC didn't notice until day 12." The pentest found bugs. The red team tested your actual security posture against a realistic attack.

Having said that, both are valuable. Pentests are cheaper, faster, and focused. Red teams are expensive but answer the question that matters most: can a real attacker achieve their objective?

Rules of Engagement -- Your Get-Out-of-Jail-Free Card

Every red team engagement starts with a legal document. Without it, everything you do is a crime. I cannot stress this enough. The difference between "authorized security professional" and "computer criminal" is literally a piece of paper:

#!/usr/bin/env python3
"""roe_generator.py -- rules of engagement checklist"""

import json

def generate_roe_checklist(engagement):
    """Build a rules of engagement document structure."""

    roe = {
        'engagement_name': engagement['name'],
        'client': engagement['client'],
        'start_date': engagement['start_date'],
        'end_date': engagement['end_date'],
        'scope': {
            'in_scope': engagement.get('in_scope', []),
            'exclusions': engagement.get('exclusions', []),
        },
        'authorized_activities': [
            'Phishing and vishing (social engineering)',
            'Physical access testing (if checked)',
            'Network exploitation and lateral movement',
            'Privilege escalation',
            'Data exfiltration (proof of concept only)',
            'C2 implant deployment',
        ],
        'prohibited_activities': [
            'Denial of service (DoS/DDoS)',
            'Data destruction or modification',
            'Accessing actual customer PII (simulated only)',
            'Physical harm to persons',
            'Attacking third-party infrastructure',
            'Social engineering of executive family members',
        ],
        'emergency_contacts': engagement.get('contacts', []),
        'notification_rules': {
            'critical_finding': 'Notify within 4 hours',
            'system_impact': 'Notify immediately',
            'law_enforcement': 'Notify client legal team first',
        },
        'data_handling': {
            'credentials': 'Encrypted at rest, destroyed 30 days '
                          'post-engagement',
            'evidence': 'Stored on encrypted drive, '
                       'returned to client on completion',
            'exfiltrated_data': 'Proof-of-concept only, no real '
                               'customer data leaves client network',
        },
        'authorization_letter': 'REQUIRED -- signed by C-level '
                               'executive with authority to authorize',
    }

    return roe

# Example engagement
sample = {
    'name': 'Acme Corp Red Team 2026-Q3',
    'client': 'Acme Corporation',
    'start_date': '2026-07-01',
    'end_date': '2026-08-15',
    'in_scope': [
        '10.0.0.0/8 (internal network)',
        '*.acme.com (all subdomains)',
        'All employees (phishing authorized)',
        'Building A and B (physical access)',
    ],
    'exclusions': [
        'Production database servers (read-only access only)',
        'Medical records systems (HIPAA)',
        'CEO personal devices',
        'Building C (data center -- separate engagement)',
    ],
    'contacts': [
        {'name': 'Jane Smith', 'role': 'CISO',
         'phone': '+1-555-0100', 'available': '24/7'},
        {'name': 'Bob Johnson', 'role': 'VP Security',
         'phone': '+1-555-0101', 'available': 'Business hours'},
    ],
}

roe = generate_roe_checklist(sample)
print(json.dumps(roe, indent=2))

That authorization letter -- the "get out of jail free" letter as we call it in the industry -- is the single most important document in the entire engagement. Keep a printed copy on your person at all times during the operation. If you're doing physical security testing at 2 AM and a security guard calls the police, you need that letter in your pocket, not on a SharePoint somewhere. I've heard stories of red teamers spending hours in holding cells because their authorization letter was "in the office" while they were on-site at the client's building.

The Kill Chain -- Mapping Red Team Operations

Red team operations map to the Lockheed Martin Cyber Kill Chain or MITRE ATT&CK framework. Every episode in this series corresponds to one or more phases:

#!/usr/bin/env python3
"""kill_chain_mapper.py -- map our curriculum to kill chain phases"""

KILL_CHAIN = {
    1: {
        'phase': 'Reconnaissance',
        'description': 'Gather intelligence about the target',
        'episodes': [4, 5, 47],
        'episode_titles': [
            'Reconnaissance', 'Active Scanning',
            'Physical Security and OSINT'
        ],
        'red_team_actions': [
            'OSINT on employees (LinkedIn, social media)',
            'Infrastructure scanning (Shodan, nmap)',
            'Physical reconnaissance of buildings',
            'Identify high-value targets for phishing',
        ],
    },
    2: {
        'phase': 'Weaponization',
        'description': 'Build or obtain the attack payload',
        'episodes': [42, 43],
        'episode_titles': [
            'Custom Exploit Development',
            'Exploit Development Advanced'
        ],
        'red_team_actions': [
            'Craft phishing payloads (macro docs, HTA files)',
            'Build custom implants to evade EDR',
            'Set up C2 infrastructure (redirectors, team server)',
            'Prepare domain infrastructure (aged domains, SSL)',
        ],
    },
    3: {
        'phase': 'Delivery',
        'description': 'Send the payload to the target',
        'episodes': [8, 39, 46, 49],
        'episode_titles': [
            'Social Engineering', 'Email Security',
            'The Human Factor', 'Deepfakes and AI Deception'
        ],
        'red_team_actions': [
            'Send phishing emails (spear phishing preferred)',
            'Vishing calls to employees',
            'USB drop attacks in parking lots',
            'Physical delivery (tailgating, badge cloning)',
        ],
    },
    4: {
        'phase': 'Exploitation',
        'description': 'Execute the payload on target system',
        'episodes': [12, 13, 14, 15, 17, 18, 19, 20, 41],
        'episode_titles': [
            'SQL Injection', 'SQLi Advanced', 'XSS', 'XSS Advanced',
            'Auth Bypass', 'SSRF', 'Deserialization',
            'File Upload', 'Exploitation Frameworks',
        ],
        'red_team_actions': [
            'Exploit web application vulnerabilities',
            'Execute phishing payload on target workstation',
            'Leverage framework exploits (Cobalt Strike, Sliver)',
        ],
    },
    5: {
        'phase': 'Installation',
        'description': 'Establish persistence on compromised system',
        'episodes': [31, 32],
        'episode_titles': [
            'Privilege Escalation Linux',
            'Privilege Escalation Windows'
        ],
        'red_team_actions': [
            'Deploy persistent implant (scheduled task, service)',
            'Escalate from standard user to admin/root',
            'Install C2 beacon with encrypted comms',
        ],
    },
    6: {
        'phase': 'Command & Control',
        'description': 'Establish ongoing communication channel',
        'episodes': [41],
        'episode_titles': ['Exploitation Frameworks'],
        'red_team_actions': [
            'Configure C2 beaconing through redirectors',
            'Establish DNS or HTTPS C2 channel',
            'Deploy multiple fallback C2 paths',
        ],
    },
    7: {
        'phase': 'Actions on Objective',
        'description': 'Achieve the engagement goal',
        'episodes': [33, 34, 48],
        'episode_titles': [
            'Active Directory Attacks', 'Pivoting and Lateral Movement',
            'Insider Threats'
        ],
        'red_team_actions': [
            'Dump domain admin credentials',
            'Access target data (CEO email, financial DB)',
            'Prove ransomware deployment capability',
            'Exfiltrate proof-of-concept data',
        ],
    },
}

print("=== Cyber Kill Chain -> Curriculum Map ===\n")
for phase_num, data in KILL_CHAIN.items():
    episodes = ', '.join(f"#{e}" for e in data['episodes'])
    print(f"Phase {phase_num}: {data['phase']} (Episodes {episodes})")
    print(f"  {data['description']}")
    for action in data['red_team_actions']:
        print(f"  - {action}")
    print()

print("A pentest typically covers phases 2-5.")
print("A red team covers ALL seven phases end to end.")

Look at that mapping. We have literally been building the red team playbook for 49 episodes without calling it that. Every skill you learned -- from OSINT to SQL injection to privilege escalation to lateral movement to deepfake awareness -- is one link in a chain that a red team welds together into a single continuous operation.

Adversary Emulation -- Becoming the Threat

The highest form of red teaming is adversary emulation: simulate a specific threat actor using their documented tools, techniques, and procedures (TTPs). Instead of "attack however works best," you constrain yourself to the exact playbook a known adversary uses.

#!/usr/bin/env python3
"""adversary_emulation.py -- plan an emulation based on ATT&CK data"""

APT_PROFILES = {
    'APT29': {
        'aliases': ['Cozy Bear', 'The Dukes', 'Midnight Blizzard'],
        'attribution': 'Russian SVR (foreign intelligence)',
        'targets': ['Government', 'Think tanks', 'Healthcare',
                    'Technology', 'Energy'],
        'ttps': {
            'initial_access': {
                'technique': 'Spearphishing Link (T1566.002)',
                'detail': 'Targeted emails with malicious links, '
                         'often mimicking legitimate services '
                         '(OneDrive, SharePoint sharing notifications)',
            },
            'execution': {
                'technique': 'PowerShell (T1059.001), WMI (T1047)',
                'detail': 'Heavy use of encoded PowerShell and WMI '
                         'for fileless execution',
            },
            'persistence': {
                'technique': 'Scheduled Tasks (T1053.005), '
                            'Registry Run Keys (T1547.001)',
                'detail': 'Multiple persistence mechanisms in parallel',
            },
            'defense_evasion': {
                'technique': 'Obfuscated Scripts (T1027), '
                            'Timestomping (T1070.006)',
                'detail': 'String encoding, variable renaming, '
                         'modifying file timestamps to blend in',
            },
            'credential_access': {
                'technique': 'Mimikatz (T1003.001), '
                            'Kerberoasting (T1558.003)',
                'detail': 'LSASS memory dump for plaintext credentials, '
                         'service ticket requests for offline cracking',
            },
            'lateral_movement': {
                'technique': 'WinRM (T1021.006), SMB (T1021.002)',
                'detail': 'Remote command execution over WinRM, '
                         'file transfer and execution over SMB',
            },
            'c2': {
                'technique': 'HTTPS (T1071.001), '
                            'Domain Fronting (T1090.004)',
                'detail': 'C2 traffic disguised as legitimate HTTPS '
                         'to major CDN providers',
            },
            'exfiltration': {
                'technique': 'Encrypted Archive (T1560), '
                            'Exfil Over C2 (T1041)',
                'detail': 'Data compressed and encrypted before '
                         'exfiltration through C2 channel',
            },
        },
        'tools': [
            'Cobalt Strike (documented usage)',
            'Custom PowerShell scripts',
            'OneDrive for C2 (documented technique)',
            'WellMess, WellMail (custom malware families)',
        ],
    },
    'FIN7': {
        'aliases': ['Carbanak', 'Navigator Group'],
        'attribution': 'Cybercriminal (financially motivated)',
        'targets': ['Retail', 'Hospitality', 'Financial services'],
        'ttps': {
            'initial_access': {
                'technique': 'Spearphishing Attachment (T1566.001)',
                'detail': 'Macro-enabled Office documents, often '
                         'disguised as invoices or orders',
            },
            'execution': {
                'technique': 'VBScript (T1059.005), JScript',
                'detail': 'Heavily obfuscated VBA macros that '
                         'download and execute secondary payloads',
            },
            'persistence': {
                'technique': 'Registry Run Keys (T1547.001)',
                'detail': 'Simple but effective persistence via '
                         'HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run',
            },
            'c2': {
                'technique': 'DNS (T1071.004), HTTPS',
                'detail': 'DNS tunneling for restricted environments, '
                         'HTTPS for primary communication',
            },
        },
        'tools': [
            'Carbanak (custom banking trojan)',
            'Cobalt Strike',
            'Metasploit (early campaigns)',
        ],
    },
}

def plan_emulation(apt_name, org_sector):
    """Generate an adversary emulation plan."""
    apt = APT_PROFILES.get(apt_name)
    if not apt:
        print(f"Unknown APT: {apt_name}")
        return

    print(f"=== Adversary Emulation Plan: {apt_name} ===")
    print(f"Aliases: {', '.join(apt['aliases'])}")
    print(f"Attribution: {apt['attribution']}")
    print(f"Target sector match: {'YES' if org_sector in apt['targets'] else 'NO'}")
    print(f"\nEmulation TTPs:")

    for tactic, ttp in apt['ttps'].items():
        label = tactic.replace('_', ' ').title()
        print(f"\n  {label}:")
        print(f"    Technique: {ttp['technique']}")
        print(f"    Detail: {ttp['detail']}")

    print(f"\nTools to use: {', '.join(apt['tools'])}")
    print(f"\nValue: this tells the defender 'if {apt_name} targeted")
    print(f"us tomorrow, would our defenses detect their playbook?'")

plan_emulation('APT29', 'Technology')

The value of adversary emulation is that it transforms "are we secure?" (an unanswerable question) into "are we secure against THIS specific threat?" (a question you can actually answer). If you're a government contractor, your primary threat is likely APT29 or APT28. If you're in retail, it's FIN7 or Magecart. If you're in critical infrastructure, it's Sandworm or Volt Typhoon. The MITRE ATT&CK Navigator (https://mitre-attack.github.io/attack-navigator/) lets you visualize exactly which techniques a specific threat actor uses, map your existing detections against those techniques, and identify the gaps. Those gaps are what your red team should test.

Operational Security -- Not Getting Caught

The red team must remain undetected. This sounds obvious, but it's the difference between a valuable engagement and a waste of money. If the blue team catches you because you were sloppy, you've proven that they can detect sloppy attackers -- which tells them nothing about their ability to detect a skilled adversary. The entire point of a red team is to simulate a skilled adversary.

#!/usr/bin/env python3
"""opsec_checklist.py -- red team operational security framework"""

OPSEC_REQUIREMENTS = {
    'infrastructure': {
        'domains': {
            'requirement': 'Register 30+ days before engagement',
            'reason': 'Fresh domains are flagged by threat intel '
                     'feeds. Domain age is a trust signal.',
            'common_mistake': 'Registering domains the day before',
        },
        'redirectors': {
            'requirement': 'Minimum 2 redirector layers between '
                          'C2 server and target network',
            'reason': 'If the blue team burns a redirector, your '
                     'team server survives. Redirectors are disposable.',
            'common_mistake': 'Pointing implants directly at the '
                            'team server IP',
        },
        'ssl_certificates': {
            'requirement': 'Valid SSL on ALL infrastructure',
            'reason': 'Self-signed certs trigger alerts in any '
                     'modern network monitoring tool',
            'common_mistake': 'Using Cobalt Strikes default self-signed cert',
        },
        'separation': {
            'requirement': 'Separate infrastructure per engagement',
            'reason': 'Cross-contamination between engagements is '
                     'a liability and evidence handling nightmare',
            'common_mistake': 'Reusing C2 servers across clients',
        },
    },
    'on_target': {
        'timing': {
            'requirement': 'Operate during business hours',
            'reason': 'Activity at 3 AM on a Saturday from a '
                     'finance workstation triggers every UEBA '
                     'baseline (episode 48)',
            'common_mistake': 'Running tools at night "when nobody '
                            'is watching" -- the SIEM is watching',
        },
        'footprint': {
            'requirement': 'Minimal tooling -- use LOLBins',
            'reason': 'Dropping custom binaries triggers EDR. '
                     'Living-off-the-land (PowerShell, certutil, '
                     'bitsadmin) blends with legitimate admin work.',
            'common_mistake': 'Uploading an entire toolkit to the '
                            'target on day one',
        },
        'beacon_timing': {
            'requirement': 'Sleep intervals of 30-60 minutes '
                          'with 20-30% jitter',
            'reason': 'Beaconing every second is trivially detected '
                     'by network monitoring. Long sleep intervals '
                     'with random jitter mimic human browsing.',
            'common_mistake': 'Default Cobalt Strike beacon interval '
                            'of 60 seconds',
        },
        'cleanup': {
            'requirement': 'Remove all tools and artifacts after '
                          'each session',
            'reason': 'Forensic artifacts from the red team become '
                     'attack surface if a real attacker finds them',
            'common_mistake': 'Leaving Mimikatz on the target "in '
                            'case I need it later"',
        },
    },
}

for category, items in OPSEC_REQUIREMENTS.items():
    label = category.replace('_', ' ').title()
    print(f"=== OPSEC: {label} ===")
    for item, details in items.items():
        print(f"\n  {item.replace('_', ' ').title()}:")
        print(f"    Req: {details['requirement']}")
        print(f"    Why: {details['reason']}")
        print(f"    Mistake: {details['common_mistake']}")
    print()

The beacon timing point is worth emphasizing. Default Cobalt Strike beaconing -- once every 60 seconds -- produces a traffic pattern that any network monitoring tool can detect: perfectly regular 60-second intervals, all night long, to the same external IP. Real humans don't make HTTPS requests with metronome precision. A properly configured beacon sleeps for 30-60 minutes between check-ins, with 20-30% random jitter, and only during business hours. The implant looks like an employee checking their email -- not a clock signal ;-)

C2 Infrastructure -- The Nervous System

Command and Control is the communication channel between the red team operators and their implants on the target network. The architecture matters enormously:

C2 architecture for a professional red team:

Internet
   |
[Redirector 1] --- [Redirector 2]    (cheap VPS, disposable)
   |                    |
   +--------+-----------+
            |
     [Team Server]                    (long-lived, protected)
            |
     [Operator 1] [Operator 2]       (the red team members)

Redirectors:
- Apache/Nginx with C2 profile matching rules
- Only forward traffic that matches the expected C2 pattern
- Everything else returns a legitimate-looking website
- If the blue team investigates the IP, they see a normal site

Team Server:
- Cobalt Strike, Sliver, or Mythic
- Not directly reachable from the internet
- Only redirectors can connect
- All operator actions logged for the report

Communication protocols:
- HTTPS (looks like normal web browsing)
- DNS  (looks like normal DNS resolution -- for restricted nets)
- SMB named pipes (for internal pivoting, no network traffic)

#!/usr/bin/env python3
"""c2_profile_comparison.py -- major C2 frameworks compared"""

C2_FRAMEWORKS = {
    'cobalt_strike': {
        'type': 'Commercial',
        'license_cost': '$3,500/year per operator',
        'language': 'Java (server), C/C++ (beacon)',
        'key_features': [
            'Malleable C2 profiles (customize traffic patterns)',
            'Beacon payload (HTTPS, DNS, SMB)',
            'Built-in credential harvesting',
            'Lateral movement automation',
            'Extensive logging for reports',
        ],
        'opsec_rating': 'HIGH (with custom malleable profiles)',
        'detection_difficulty': 'MEDIUM -- default configs widely signatured, '
                               'but custom profiles evade most tools',
        'industry_use': 'The standard for commercial red teams. '
                       'Also the most abused by real threat actors.',
    },
    'sliver': {
        'type': 'Open source (BishopFox)',
        'license_cost': 'Free',
        'language': 'Go (server + implant)',
        'key_features': [
            'Implant generation with unique per-build encryption',
            'Multiple C2 protocols (HTTPS, mTLS, WireGuard, DNS)',
            'Built-in SOCKS5 proxy for pivoting',
            'Armory for extensions (BOFs, .NET assemblies)',
            'Multiplayer support (multiple operators)',
        ],
        'opsec_rating': 'HIGH (compiled Go implants, per-build crypto)',
        'detection_difficulty': 'HIGH -- each implant is cryptographically '
                               'unique, harder to signature',
        'industry_use': 'Growing rapidly. Preferred by teams that '
                       'want Cobalt Strike capabilities without '
                       'the licensing cost or leak concerns.',
    },
    'mythic': {
        'type': 'Open source',
        'license_cost': 'Free',
        'language': 'Python/Go (server), agents in multiple languages',
        'key_features': [
            'Web-based UI for operator collaboration',
            'Multiple agent types (C#, Python, Go, JavaScript)',
            'Custom C2 profile support',
            'Extensive task logging and reporting',
            'Plugin architecture for extensions',
        ],
        'opsec_rating': 'MEDIUM-HIGH (depends on agent choice)',
        'detection_difficulty': 'VARIES by agent -- some are well-known, '
                               'custom agents are harder to detect',
        'industry_use': 'Popular in red team training and labs. '
                       'Production use growing.',
    },
}

for name, data in C2_FRAMEWORKS.items():
    label = name.replace('_', ' ').title()
    print(f"=== {label} ===")
    print(f"  Type: {data['type']}")
    print(f"  Cost: {data['license_cost']}")
    print(f"  OPSEC: {data['opsec_rating']}")
    print(f"  Detection: {data['detection_difficulty']}")
    print(f"  Features:")
    for feat in data['key_features']:
        print(f"    - {feat}")
    print()

The irony with Cobalt Strike is that it's used both by professional red teams AND by real threat actors (APT29, FIN7, Conti ransomware group, and dozens of others all use pirated copies). This means defenders who detect Cobalt Strike beacons can't immediately tell whether it's a sanctioned red team exercise or an actual breach. Some organizations solve this by requiring the red team to use a different C2 framework entirely, so that any Cobalt Strike detection is treated as a real incident. Sliver is increasingly popular for exactly this reason -- it provides comparable capability without the "is this our red team or an actual attacker?" ambiguity.

Purple Teaming -- The Collaborative Model

Purple teaming is where the adversarial wall between red and blue dissolves. Instead of the red team attacking in secret and delivering a report three months later, the two teams work together in real time:

#!/usr/bin/env python3
"""purple_team_exercise.py -- structured purple team session"""

PURPLE_TEAM_SCHEDULE = {
    'day_1': {
        'theme': 'Initial Access',
        'techniques': [
            {
                'id': 'T1566.001',
                'name': 'Spearphishing Attachment',
                'red_action': 'Send macro-enabled Word doc to '
                             'target mailbox via simulated phish',
                'blue_check': [
                    'Did the email gateway flag the attachment?',
                    'Did the sandbox detonate the macro?',
                    'Did EDR alert on the macro execution?',
                ],
                'detection_built': None,  # filled during exercise
            },
            {
                'id': 'T1059.001',
                'name': 'PowerShell Execution',
                'red_action': 'Execute encoded PowerShell download '
                             'cradle from the macro payload',
                'blue_check': [
                    'Did Windows Event Log capture the command?',
                    'Did AMSI flag the encoded script?',
                    'Does our Sigma rule for base64 PS trigger?',
                ],
                'detection_built': None,
            },
        ],
    },
    'day_2': {
        'theme': 'Credential Access + Lateral Movement',
        'techniques': [
            {
                'id': 'T1003.001',
                'name': 'LSASS Memory Dump',
                'red_action': 'Run Mimikatz or comsvcs.dll '
                             'MiniDump on target workstation',
                'blue_check': [
                    'Did EDR detect LSASS access?',
                    'Did Sysmon Event ID 10 fire (process access)?',
                    'Is the Sigma rule for LSASS dump active?',
                ],
                'detection_built': None,
            },
            {
                'id': 'T1021.006',
                'name': 'WinRM Lateral Movement',
                'red_action': 'Use captured creds to WinRM into '
                             'domain controller',
                'blue_check': [
                    'Did Windows Security Log capture logon?',
                    'Did network monitoring see WinRM traffic '
                    'from an unusual source?',
                    'Is the lateral movement alert configured?',
                ],
                'detection_built': None,
            },
        ],
    },
    'day_3': {
        'theme': 'Persistence + Defense Evasion',
        'techniques': [
            {
                'id': 'T1053.005',
                'name': 'Scheduled Task Persistence',
                'red_action': 'Create scheduled task for C2 beacon '
                             'persistence on compromised host',
                'blue_check': [
                    'Did Sysmon Event ID 1 log schtasks.exe?',
                    'Did our scheduled task creation rule fire?',
                    'Is the task visible in Task Scheduler audit?',
                ],
                'detection_built': None,
            },
            {
                'id': 'T1070.001',
                'name': 'Event Log Clearing',
                'red_action': 'Clear Windows Security event log '
                             'to cover tracks',
                'blue_check': [
                    'Did Event ID 1102 (log cleared) fire?',
                    'Is the log forwarded to SIEM before clearing?',
                    'Did our log deletion alert trigger?',
                ],
                'detection_built': None,
            },
        ],
    },
}

print("=== Purple Team Exercise Plan ===\n")
for day, session in PURPLE_TEAM_SCHEDULE.items():
    label = day.replace('_', ' ').title()
    print(f"--- {label}: {session['theme']} ---")
    for tech in session['techniques']:
        print(f"\n  [{tech['id']}] {tech['name']}")
        print(f"  Red: {tech['red_action']}")
        print(f"  Blue checks:")
        for check in tech['blue_check']:
            print(f"    [ ] {check}")
    print()

print("Each gap found -> detection rule built ON THE SPOT.")
print("End result: measured detection coverage map + new rules.")

The advantage of purple teaming over traditional red teaming is speed of feedback. In a traditional red team, the blue team only learns what they missed when the report arrives weeks or months later. In a purple team, the learning happens in real time. The red team executes a technique, the blue team checks their tools, and if the detection is missing they build it together right there and then. Three days of purple teaming can produce more detection improvement than six weeks of traditional red teaming -- because the feedback loop is measured in minutes, not months.

The Red Team Report -- Telling the Story

The deliverable of a red team engagement is NOT a list of vulnerabilities. It's a narrative -- the story of how the attack unfolded:

Red Team Report Structure:

1. Executive Summary (1 page, non-technical)
   - Objectives defined: access CEO email, exfiltrate customer DB,
     prove ransomware deployment capability
   - Objectives achieved: all three, within 11 days
   - Time to first detection: 12 days (blue team did NOT detect
     the attack -- it was revealed at engagement end)
   - Business risk: CRITICAL -- a real attacker with these
     objectives would have succeeded undetected

2. Attack Narrative (5-20 pages, chronological story)
   Day 1-2: Reconnaissance
     - OSINT gathered from LinkedIn, company website, job postings
     - Technology stack identified: Azure AD, Exchange Online,
       Windows 10 fleet, Palo Alto firewall, CrowdStrike EDR
     - Phishing targets selected: 3 HR staff, 2 finance staff

   Day 3: Initial Access
     - Spearphishing email sent to HR coordinator (invoice pretext)
     - Macro-enabled document opened, PowerShell beacon deployed
     - C2 established via HTTPS to redirector infrastructure
     - CrowdStrike EDR did NOT alert (custom beacon, jittered sleep)

   Day 4-6: Privilege Escalation + Lateral Movement
     - LSASS dump on HR workstation: obtained domain user hashes
     - Kerberoasted 3 service accounts, cracked 2 offline
     - WinRM to file server using cracked service account
     - Accessed HR file share: employee records, salary data

   Day 7-9: Domain Compromise
     - DCSync attack from file server (service account had
       replicating directory changes permission -- misconfigured)
     - Obtained domain admin NTLM hash
     - Lateral movement to domain controller via PsExec
     - Full domain compromise achieved

   Day 10-11: Objectives Completed
     - Accessed CEO mailbox via Exchange admin privileges
     - Exported 6 months of email (proof of concept: 3 emails)
     - Copied customer database (proof of concept: 100 rows)
     - Staged ransomware deployment script (NOT executed)
     - All evidence collected, screenshots, timestamps, logs

3. Detection Gaps (mapped to MITRE ATT&CK)
   - T1566.001 -- phishing email: NOT detected by email gateway
   - T1059.001 -- PowerShell execution: NOT detected by EDR
   - T1003.001 -- LSASS dump: NOT detected (comsvcs.dll method)
   - T1558.003 -- Kerberoasting: NOT detected
   - T1003.006 -- DCSync: NOT detected (no alert on replication)

4. Recommendations (prioritized)
   Priority 1: Fix DCSync permissions (service account should NOT
     have replicating directory changes rights)
   Priority 2: Deploy canary tokens in sensitive file shares
   Priority 3: Implement Kerberoasting detection rule
   Priority 4: Tune EDR policy for LSASS access patterns
   Priority 5: Email gateway macro detection improvements

The narrative format is critical because it answers questions a vulnerability list cannot: how did these individual weaknesses chain together into a complete compromise? A misconfigured service account permission is a "medium" finding in a vulnerability report. In the red team narrative, that same misconfiguration was the single pivotpoint that turned a compromised HR workstation into full domain compromise. Context matters.

The AI Slop Connection

AI is transforming red team operations on both sides of the equation, and the transformation is not symetric.

On the offense side, AI accelerates every phase of the kill chain. Reconnaissance gets faster (feed LinkedIn data to a model, get a targeting package). Phishing gets more effective (episode 49 showed how AI generates personalized emails at scale). Exploit development gets faster (AI can suggest exploitation strategies for known vulnerability classes). And OPSEC gets better (AI can analyze C2 traffic patterns and suggest improvements to avoid detection signatures).

On the defense side, AI powers next-generation SIEM correlation, behavioral analytics, and automated threat hunting. AI-powered EDR products can detect anomalous PowerShell patterns that signature-based tools miss. AI UEBA (as we discussed in episode 48) builds behavioral baselines and flags deviations. The blue team is getting smarter too.

The uncomfortable reality: AI makes a mediocre attacker significantly more dangerous. A script kiddie with AI assistance can now plan and execute attacks that previously required years of experience. But AI also makes a mediocre defender significantly more capable -- AI-powered tools catch things that would have gone unnoticed. The question every organization needs to answer is whether their AI-augmented defense is evolving faster than the AI-augmented offense targeting them. The red team exists to answer that question empirically, not hypothetically.

What Comes Next

Episode 50 marks a turning point. We've spent the first half of this series on offense -- finding vulnerabilities, exploiting them, moving through networks, engineering humans, and now orchestrating all of those skills into coordinated operations. The attacker's toolkit is comprehensive.

The next phase shifts to the other side of the equation. What happens when an organization gets breached -- not the red team's simulated breach, but the real thing? The first 48 hours after detection are where most organizations either contain the damage or let it spiral. And before that response can be effective, the organization needs intelligence -- understanding who is attacking them, what they're after, and what techniques they use. The shift from "how do we attack?" to "how do we respond, and how do we build intelligence that gives us structural advantages?" is where security matures from reactive to proactive.

Exercises

Exercise 1: Create a red team operation plan for a hypothetical company (invent a fictional target: name, industry, employee count, technology stack). The plan must include: (a) three specific objectives (e.g., "access CEO email," "prove ransomware deployment," "exfiltrate customer database"), (b) rules of engagement checklist, (c) attack phases mapped to the kill chain with specific techniques for each phase (reference MITRE ATT&CK IDs), (d) OPSEC requirements for infrastructure and on-target operations. This is a planning exercise -- do not execute. Save to ~/lab-notes/red-team-plan.md.

Exercise 2: Use the MITRE ATT&CK Navigator (https://mitre-attack.github.io/attack-navigator/) to create a detection coverage map. Choose a threat actor relevant to your industry (or use APT29 as a default). Mark each of their known techniques as: (a) green = we can detect this, (b) yellow = partial detection, (c) red = no detection. Export the navigator layer as JSON. Identify the top 5 detection gaps and propose a detection rule for each (specify data source, detection logic, and expected false positive rate). Save to ~/lab-notes/detection-coverage-map.md.

Exercise 3: Set up a mini purple team exercise in your lab. Deploy a Sliver or Metasploit implant on a lab VM that has Sysmon installed and configured with the SwiftOnSecurity config. Execute 5 common ATT&CK techniques: (a) T1059.001 PowerShell execution, (b) T1003.001 LSASS credential dump, (c) T1053.005 scheduled task creation, (d) T1021.006 WinRM lateral movement, (e) T1070.001 event log clearing. For each technique, check the Sysmon logs and write a detection query. Document which techniques produced detectable events and which did not. Save to ~/lab-notes/purple-team-exercise.md.

De groeten!

@scipio

stem stemsocial steemstem security programming
0
0
0.000
0 comments