TeamPCP Targeting Checkmarx: CI/CD Credentials Stolen in GitHub Action Heist
Looks like TeamPCP is back at it again. After the Trivy supply chain mess, they've managed to compromise Checkmarx's GitHub Actions by leveraging stolen CI credentials. Specifically, checkmarx/ast-github-action and checkmarx/kics-github-action were affected.
The attackers reportedly used the compromised credentials to inject malicious code into the workflows, designed to exfiltrate repository secrets. It is particularly ironic that supply chain security tools are being used as the entry point for supply chain attacks.
If you are running these actions, you should assume your environment is at risk and rotate any secrets exposed in those workflows immediately. I've whipped up a quick GitHub CLI command to help you hunt down usage across your orgs:
# Search for affected Checkmarx actions in your organization's workflows
gh search code --org --filename .github/workflows/*.yml "checkmarx/ast-github-action"
gh search code --org --filename .github/workflows/*.yml "checkmarx/kics-github-action"
Once again, this highlights the danger of using mutable tags (like @v2) instead of immutable commit SHAs. How is everyone handling this? Are you manually pinning SHAs, or have you adopted an automated policy (like dependabot or custom pre-commit hooks) to block mutable action references?
This is exactly why we enforce step-security/harden-runner on all critical jobs. It doesn't stop the initial compromise if you pull a malicious image, but it creates a network egress policy that alerts us if the action tries to phone home to a non-whitelisted IP.
For detection, you can query your GitHub Audit Logs for these specific actions running during the compromise window. Here is a basic KQL-style filter for Sentinel or whatever SIEM you use:
GitHubAuditLogs
| where Operation == "workflow_run"
| where Workflow contains "checkmarx"
| project RepoName, Actor, CreatedAt, HeadBranch
If you see anything unusual, rotate those tokens immediately.
We started pinning commit SHAs religiously after the actions/checkout hijack scare last year. It is a maintenance nightmare, honestly. But it's better than explaining to a client why their production keys are for sale on a dark web forum.
I recommend using a script to validate your workflow files before commit. A simple Python script using the pyyaml library can parse your YAML and fail the build if it detects a mutable tag like @v1 instead of a full SHA hash.
From a pentester's perspective, we are seeing this exploit pattern constantly. Attackers don't hunt for zero-days in the product anymore; they hunt for the CI/CD pipeline. The CI/CD is the 'crown jewels' because it usually has write access to production and artifacts.
I'd suggest checking if your CI runners have unnecessary permissions. The principle of least privilege applies here—if the runner only needs to read code, don't give it the ability to push to the registry or access secrets.
The weaponization of security tools is a harsh reality. Since we can't rely solely on prevention, immediate detection is key. We should audit if these specific workflows ran in our environments recently. You can use the GitHub CLI to scan for them:
gh run list -- name,conclusion,createdAt --jq '.[] | select(.name | contains("checkmarx"))'
If you find runs around the compromise timeline, prioritize scanning the logs for unexpected API calls to external domains.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access