pull_request_target injection → secrets → cloud takeover

§ Context

Assumed environment: target uses GitHub Actions; at least one workflow triggers on pull_request_target (commonly because it needs secrets for labelling / commenting). The workflow checks out github.event.pull_request.head.sha.

§ Steps

1. 01
   Fork target repo + push payloadInitial Access

   T1078— Valid Accounts
2. 02
   Spot pull_request_target workflowReconnaissance

   W-RECON-GITHUB-DORK— GitHub / GitLab Dorking
3. 03
   Use AWS deploy creds to assume admin roleLateral Movement

   C-AWS-ASSUMEROLE-CHAIN— AWS sts:AssumeRole Chain
4. 04
   Backdoor IAM userPersistence

   C-AWS-IAM-BACKDOOR— AWS IAM Backdoor User / Access Key
5. 05
   Open PR — workflow runs in base context with secretsInitial Access

   CI-PR-TARGET— GitHub Actions pull_request_target Injection
6. 06
   Exfil all $SECRETS to attacker hostCredential Access

   CI-SECRET-IN-LOG— Secret Echo to Build Log
7. 07
   Workflow step executes attacker codeExecution

   CI-WORKFLOW-INJECT— Workflow Command Injection

§ References

• T1078Valid Accounts

§ Frequently asked

What is the "pull_request_target injection → secrets → cloud takeover" attack path?

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. It chains 7 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Fork target repo + push payload (T1078) — a initial access primitive. Assumed environment: target uses GitHub Actions; at least one workflow triggers on pull_request_target (commonly because it needs secrets for labelling / commenting).

What is the final impact of this kill-chain?

The final step lands on Workflow step executes attacker code (CI-WORKFLOW-INJECT), which falls under Execution. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques3

  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.

• Shared techniques3

  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.

• Shared techniques2

  Mass SMS phish → Okta-style portal → SaaS sprawl (0ktapus)

  Wide SMS phishing campaign targeting employees of ~130 organisations with a single phishlet that captures Okta credentials + push approval. Mass automated logins to Twilio, MailChimp, DoorDash et al.

• Shared techniques2

  Dev workstation → cloud backup keys → encrypted vault store (LastPass 2022)

  Attacker compromised a single LastPass DevOps engineer's home machine via outdated Plex Media Server, harvested AWS keys for the encrypted-vault backup bucket, exfiltrated production vault data.

• Shared techniques2

  Build-system implant → signed supply-chain backdoor (SolarWinds-class)

  Compromise the target vendor's build server. A small implant rewrites a single source file at compile time — every official signed release downstream now ships the backdoor.

• Shared techniques2

  Vish helpdesk → Okta MFA reset → admin → ransomware (MGM-class)

  Identify an Okta admin via LinkedIn. Vish the helpdesk pretending to be that admin, get MFA reset. Sign in, plant attacker MFA factor, then push policy changes that disable MFA for chosen apps before mass-deploying ransomware.