offensive-supply-chain

Offensive Supply Chain Attacks

Software supply chain attacks exploit the trust relationships between developers, package registries, build systems, and deployment pipelines. You target the components and processes that organizations depend on but rarely audit with the same rigor as their own code. A single compromised dependency can propagate across thousands of downstream consumers, making supply chain the highest leverage attack surface in modern software ecosystems.

This skill covers the offensive lifecycle: reconnaissance of internal package names, exploitation of registry resolution logic, build system hook abuse, CI/CD pipeline tampering, and container image supply chain attacks. Every technique maps to authorized red team engagement patterns with safe callback mechanisms.

Quick Workflow

1. Enumerate internal package names from target artifacts (lock files, source maps, error messages, GitHub repos).
2. Identify the package ecosystem (npm, PyPI, NuGet, Maven, Go, Ruby) and registry configuration.
3. Select attack vector: dependency confusion, typosquatting, build hook injection, CI/CD tampering, or container supply chain.
4. Prepare a safe proof-of-concept package with DNS canary or HTTP callback -- no destructive payload.
5. Register the package on the public registry or stage the artifact for injection.
6. Monitor for callback to confirm execution in the target environment.
7. Document the attack path, affected systems, and remediation guidance.

---

Dependency Confusion

Dependency confusion exploits the resolution order when an organization uses both private and public package registries. If the private registry is not configured as the exclusive source, the package manager may prefer a higher-versioned public package over the internal one.

npm Dependency Confusion

When a project references an unscoped private package and the .npmrc does not pin the registry exclusively, npm falls back to the public registry.

# Recon: extract package names from package-lock.json or yarn.lock
cat package-lock.json | jq -r '.dependencies | keys[]' | sort -u > pkg_names.txt

# Check which names are unclaimed on the public npm registry
while read pkg; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "https://registry.npmjs.org/$pkg")
  if [ "$status" = "404" ]; then
    echo "[AVAILABLE] $pkg"
  fi
done < pkg_names.txt