Secret Echo to Build Log
Workflow inadvertently prints a secret (echo $SECRET, set -x, env dump) — public CI log exposes it.
§ Where this technique fits
CI-SECRET-IN-LOG is catalogued under the Credential Access tactic of the offensive-security kill-chain. It appears in 5 approved dossiers in the registry, typically at step 4.6 on average.
§ Dossiers chaining this technique
- step 2 / 6
Secret echoed to public build log → cloud takeover
A workflow accidentally runs `env` or `set -x` during debugging — the AWS access key is now in public CI logs and indexed by Google Cache / GitHub search.
- step 5 / 5
Dependency confusion → internal CI compromise
Publish a public npm package with the name of a target's private internal dependency at a higher version. CI resolves the public one first and runs install scripts in privileged CI.
- step 5 / 5
GitHub Action tag mutation → silent supply-chain hijack
Target pins an action by tag (uses: org/action@v3). Compromise the action repo and move the v3 tag to a malicious commit — every workflow using it pulls in the backdoor.
- step 5 / 7
pull_request_target injection → secrets → cloud takeover
A GitHub Actions workflow runs on pull_request_target and checks out the PR's head SHA. The attacker's PR injects code that runs with the base repo's secrets, including a cloud deploy role.
- step 6 / 6
Self-hosted runner takeover → persistent CI compromise
A public repo with self-hosted GitHub runners accepts external PRs. First malicious PR runs on the runner; the workflow drops a runner-hook that fires before every future job.
§ What commonly comes next
- 01AWS sts:AssumeRole Chainseen 1×C-AWS-ASSUMEROLE-CHAIN · Lateral Movement
- 02Valid Accountsseen 1×T1078 · Initial Access