Listen to this Post
Introduction:
A sophisticated supply chain attack has compromised the official Checkmarx KICS Docker Hub repository, with threat actors pushing trojanized container images capable of harvesting and exfiltrating sensitive credentials from scanned IaC files. The breach, which saw attackers overwrite legitimate tags like `v2.1.20` and `alpine` while introducing a fake `v2.1.21` release, represents a critical escalation in software supply chain threats facing modern DevSecOps pipelines. This article provides a full technical breakdown, detection commands, and a step-by-step incident response plan for teams using affected versions.
Learning Objectives:
- Analyze how threat actors overwrote mutable Docker tags to inject malicious exfiltration code into official Checkmarx KICS images.
- Implement image pinning, integrity verification, and CI/CD pipeline hardening to prevent mutable tag exploitation.
- Deploy detection rules for credential scanning, unauthorized outbound traffic, and suspicious runner behavior in GitHub Actions.
You Should Know:
- How Attackers Poisoned the Official Checkmarx KICS Images
The Checkmarx KICS compromise is not an isolated event but part of a wider campaign likely orchestrated by the TeamPCP threat actor. On April 22, 2026, Docker’s internal monitoring flagged suspicious activity around KICS image tags and promptly alerted Socket researchers. The investigation revealed that attackers had overwritten existing mutable tags, including `v2.1.20` and alpine, and introduced a fraudulent `v2.1.21` tag with no corresponding upstream release. The bundled KICS binary was modified to include unauthorized data collection and exfiltration capabilities. The malware could generate an uncensored scan report, encrypt it, and send it to an external attacker-controlled endpoint. This created a severe risk for teams scanning Terraform, CloudFormation, or Kubernetes configurations — files that routinely contain API keys, database credentials, and cloud access secrets. The incident extended beyond Docker Hub: related Checkmarx VS Code extension versions 1.17.0 and 1.19.0 were found to contain malicious code that downloaded and executed a remote JavaScript add-on via the Bun runtime from a hardcoded GitHub URL without user confirmation or integrity verification. The presence of the malicious behavior in version 1.17.0 and 1.19.0, but its absence in 1.18.0, suggests deliberate insertion and potential testing of the attack. Organizations that used the affected images should treat any secrets exposed to those scans as compromised and rotate them immediately.
Step‑by‑step guide explaining what this does and how to use it:
First, detect affected images in your environment. Run the following command to list all Docker images pulled from the Checkmarx KICS repository on your system:
List all Docker images from the checkmarx/kics repository
docker images --filter "reference=checkmarx/kics:" --format "table {{.Repository}}:{{.Tag}}\t{{.ID}}\t{{.CreatedAt}}"
Next, check the digest of a suspicious image to verify its integrity against the official version. Mutable tags can change, but the digest is immutable and cryptographically unique:
Get the digest of a pulled image
docker inspect checkmarx/kics:v2.1.20 --format='{{index .RepoDigests 0}}'
Compare the digest against a known good reference from a trusted source. If the digest does not match, the image is compromised.
Then, identify all secrets that may have been exposed during scans performed with the affected images. Review your CI/CD logs for any KICS scan runs between the compromise window and remediation. Search for any unusual outbound network connections from the scanning environment, as the malware encrypted and exfiltrated scan reports:
On Linux, check for unexpected outbound connections from docker containers (requires root)
sudo conntrack -L | grep ESTABLISHED | grep -E "(:443|:80)" | awk '{print $5}' | sort | uniq -c | sort -nr
On Windows (PowerShell as Admin), check for recent outbound connections from the build host
Get-NetTCPConnection | Where-Object { $<em>.State -eq "Established" -and $</em>.RemotePort -ne 443 -and $_.RemotePort -ne 80 } | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess
Finally, rotate all potentially exposed credentials. Any secret that was present in the IaC files scanned by the compromised KICS image must be considered compromised. This includes cloud provider keys (AWS, Azure, GCP), database passwords, API tokens, and any other sensitive configuration data. Perform a full rotation following your organization’s security policy. The attack also involved malicious VS Code extensions; audit your extension versions:
On Linux/macOS, check installed VS Code extensions for the affected versions code --list-extensions --show-versions | grep -E "checkmarx|kics" On Windows (Command Prompt) code --list-extensions --show-versions | findstr /i "checkmarx kics"
If you find versions 1.17.0 or 1.19.0, uninstall the extension immediately and review your environment for any suspicious outbound connections. As a long-term hardening measure, always pin images by digest rather than by mutable tag to prevent silent tag overwrites in future CI/CD pipelines.
2. Hardening CI/CD Pipelines Against Mutable Tag Exploits
This incident demonstrates the critical danger of relying on mutable Docker tags in production and CI/CD environments. By overwriting the latest, alpine, and version tags, the attackers were able to silently distribute malicious code to any user who pulled the image without verifying its content hash. The fundamental issue is that Docker tags are mutable pointers: they can be moved to point to a different image digest at any time. When a pipeline uses `checkmarx/kics:latest` or checkmarx/kics:v2.1.20, it implicitly trusts that the tag has not been tampered with. In this attack, that trust was betrayed. The malicious `v2.1.21` tag, which had no legitimate upstream release, served as an additional vector to trap users searching for the latest version. To defend against this class of attack, teams must adopt immutable references, enforce integrity verification, and implement pipeline-level security controls.
Step‑by‑step guide explaining what this does and how to use it:
Step 1: Pin images by digest, not by tag. Every Docker image has an immutable content-addressable digest (SHA256 hash). Pinning to the digest guarantees that you are running the exact same image content, even if the tag is later changed. To find the digest of a known good image, pull it from a trusted source and inspect it:
Pull the image from a trusted registry (e.g., Docker Hub official)
docker pull checkmarx/kics:v2.1.20
Get the digest
docker inspect checkmarx/kics:v2.1.20 --format='{{index .RepoDigests 0}}'
Example output: checkmarx/kics@sha256:9f7e12b8a4c3d5e6f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f
Then, in your CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins), reference the image by digest:
GitHub Actions example - pinned by digest jobs: kics-scan: runs-on: ubuntu-latest container: image: checkmarx/kics@sha256:9f7e12b8a4c3d5e6f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f steps: - name: Scan IaC run: kics scan -p .
Step 2: Enforce image signature verification. Use Docker Content Trust (DCT) or Sigstore/cosign to verify image signatures before deployment. Enable DCT in your environment:
Enable Docker Content Trust globally export DOCKER_CONTENT_TRUST=1 Pull an image with signature verification (fails if not signed or signature invalid) docker pull checkmarx/kics:v2.1.20
For production clusters, integrate admission controllers like Kyverno or OPA/Gatekeeper to reject unsigned images.
Step 3: Implement CI/CD pipeline security scanning. Scan all container images for vulnerabilities and secrets before they are used in builds. Integrate tools like Trivy, Grype, or Snyk into your pipeline:
Scan a local image for vulnerabilities and secrets trivy image --severity CRITICAL --security-checks vuln,secret checkmarx/kics:v2.1.20 Scan a Dockerfile for misconfigurations trivy config --severity CRITICAL Dockerfile
Step 4: Use a private mirror or registry proxy. Instead of pulling directly from Docker Hub, use a private registry (e.g., JFrog Artifactory, Amazon ECR, Google Artifact Registry) as a caching proxy. This allows you to control which image digests are approved and to scan images before they enter your environment. Pull from your private registry instead:
Configure Docker to use a private registry mirror
Edit /etc/docker/daemon.json
{
"registry-mirrors": ["https://my-mirror.example.com"]
}
Then restart Docker and pull images through the mirror, which can enforce allowlists of approved digests.
- Detecting TeamPCP Malware with Behavioral Indicators and IOCs
The TeamPCP actor, also associated with the Shai Hulud (or Arrakis) campaign, utilizes malicious scripts to scan for credentials and perform exfiltration on GitHub Actions runners. Static IOCs like file hashes and C2 domains are easily changed, so security teams must focus on behavioral detection. The malicious script typically scans common credential locations (e.g., ~/.aws/credentials, ~/.config/gcloud, SSH keys, environment variables) and exfiltrates the collected information to an external server. In the Checkmarx KICS attack, the malware also attempted Kubernetes-based persistence by deploying a highly privileged pod in some environments. Understanding these behaviors allows teams to hunt for compromise even when IOCs change.
Step‑by‑step guide explaining what this does and how to use it:
Step 1: Hunt for credential scanning behavior on GitHub runners. The malicious script often runs under the `github` user or within /usr/local/actions-runner/runsvc.sh. Use the following Linux command to detect unusual access to credential files:
Monitor for access to credential files from unexpected processes auditctl -w /home/github/.aws/credentials -p rwa -k aws_creds_access auditctl -w /home/github/.config/gcloud/credentials.db -p rwa -k gcloud_creds_access auditctl -w /home/github/.ssh/id_rsa -p rwa -k ssh_key_access Review audit logs for accesses by non-expected processes ausearch -k aws_creds_access --format raw | aureport -f -i
In a CI/CD environment, consider using pre-commit hooks or pipeline steps to block scripts that attempt to read credential files.
Step 2: Detect data exfiltration via network monitoring. The malware encrypts and exfiltrates data to an external endpoint. Monitor for large outbound data transfers from build runners, especially to unusual ports or IP addresses. Use `tcpdump` or `nethogs` to identify unexpected traffic:
Capture outbound traffic from the build host to non-standard ports
sudo tcpdump -i eth0 'src host <BUILD_HOST_IP> and (dst port not 443 and dst port not 80)' -c 1000 -w exfil.pcap
Analyze the capture for data patterns (e.g., Base64-encoded blocks)
strings exfil.pcap | grep -E '^[A-Za-z0-9+/]{40,}={0,2}$'
On Windows, use PowerShell to monitor for unusual outbound connections from processes associated with build tools:
Get all outbound connections from processes named "docker", "kics", or "node"
Get-NetTCPConnection | Where-Object {$<em>.State -eq "Established"} | ForEach-Object {
$process = Get-Process -Id $</em>.OwningProcess -ErrorAction SilentlyContinue
if ($process.ProcessName -match "docker|kics|node|python") {
[bash]@{
Process = $process.ProcessName
LocalPort = $<em>.LocalPort
RemoteAddress = $</em>.RemoteAddress
RemotePort = $_.RemotePort
}
}
}
Step 3: Deploy behavioral detection rules in your SIEM/EDR. Palo Alto Networks provides a specific detection rule, ioc.linux.shaihulud.2, designed to detect malicious credential access tools on Linux systems, particularly targeting GitHub Action runners. If you are using Cortex XDR, enable this rule and create custom BIOC (Behavioral Indicator of Compromise) rules under the Credential Access and Exfiltration categories. For other EDRs, create custom rules that alert on:
– A process reading files from ~/.aws, ~/.config/gcloud, ~/.ssh, or `~/.docker` and then making an outbound network connection within a short time window.
– A process with a high entropy command line that includes curl, wget, or `base64` decoding.
– A container running with privileged mode (especially `–privileged` flag) in a CI/CD context.
Step 4: Scan for known IOCs from the Checkmarx KICS compromise. While not comprehensive, the following IOCs have been associated with the TeamPCP campaign and can be used for initial triage:
Malicious file hashes (SHA256)
744c9d61b66bcd2bb5474d9afeee6c00bb7e0cd32535781da188b80eb59383e0
527f795a201a6bc114394c4cfd1c74dce97381989f51a4661aafbc93a4439e90
0d66d8c7e02574ff0d3443de0585af19c903d12466d88573ed82ec788655975c
65bd72fcddaf938cefdf55b3323ad29f649a65d4ddd6aea09afa974dfc7f105d
Search for these hashes on a Linux system
find / -type f -exec sha256sum {} \; 2>/dev/null | grep -E "744c9d61b66bcd2bb5474d9afeee6c00bb7e0cd32535781da188b80eb59383e0|527f795a201a6bc114394c4cfd1c74dce97381989f51a4661aafbc93a4439e90|0d66d8c7e02574ff0d3443de0585af19c903d12466d88573ed82ec788655975c|65bd72fcddaf938cefdf55b3323ad29f649a65d4ddd6aea09afa974dfc7f105d"
Add these hashes to your antivirus or EDR blocklists. However, remember that attackers can easily change these, so behavioral rules are more reliable in the long term.
- Securing VS Code Extensions and Developer Tooling Supply Chain
The Checkmarx compromise extended beyond Docker images to include malicious VS Code extension releases. Versions 1.17.0 and 1.19.0 of the Checkmarx VS Code extension were found to contain code that downloaded and executed a remote JavaScript add-on via the Bun runtime from a hardcoded GitHub URL without user confirmation or integrity verification. This highlights a growing attack vector: developer tooling extensions. Many developers automatically install extension updates or use public registries like the VS Code Marketplace or OpenVSX without verifying the integrity of the code they are adding to their IDE. An attacker who compromises a maintainer’s account or the build pipeline can push a malicious extension that gains the same access as the developer using it — including reading local files, accessing cloud credentials stored in environment variables, and modifying code before it is committed.
Step‑by‑step guide explaining what this does and how to use it:
Step 1: Audit all installed VS Code extensions across your organization. Use the VS Code command-line interface to list extensions and their versions. Compare this list against a known-good inventory:
On Linux/macOS, list all extensions with versions code --list-extensions --show-versions > installed_extensions.txt Check for any Checkmarx extensions and their versions grep -i checkmarx installed_extensions.txt On Windows code --list-extensions --show-versions | findstr /i "checkmarx" > checkmarx_extensions.txt
If you find the affected versions (1.17.0 or 1.19.0), uninstall them immediately:
Uninstall the Checkmarx extension (replace with actual extension ID) code --uninstall-extension checkmarx.kics-extension Clear the extension cache to ensure no residual files remain rm -rf ~/.vscode/extensions/checkmarx.kics-extension-
Step 2: Enforce extension pinning and integrity verification. Use the `settings.json` file to control which extensions are allowed and to prevent automatic updates:
{
"extensions.autoCheckUpdates": false,
"extensions.autoUpdate": false,
"extensions.ignoreRecommendations": true,
"extensions.allowedExtensions": [
"ms-python.python",
"ms-vscode-remote.remote-ssh",
// Only list explicitly approved extensions
]
}
For team-wide enforcement, use Workspace Trust settings and consider using the `–install-extension` flag with a pinned version when provisioning development environments:
Install a specific version of an extension (if available in the marketplace) code --install-extension [email protected] Install from a VSIX file that has been manually verified code --install-extension /path/to/verified-extension.vsix
Step 3: Implement a private extension marketplace. For enterprise environments, consider using a private extension gallery or a proxy that validates extensions before they are distributed. Tools like OpenVSX can be self-hosted, allowing you to control which extensions and versions are available to your developers. Pull extensions from your private registry instead of directly from the public marketplace:
Configure VS Code to use a custom extension gallery (in settings.json)
"extensions.gallery": {
"serviceUrl": "https://your-private-gallery.example.com/vscode/gallery",
"itemUrl": "https://your-private-gallery.example.com/vscode/item"
}
Step 4: Monitor extension behavior. Use OS-level monitoring to detect when an extension performs suspicious actions, such as making unexpected network connections, executing child processes, or accessing credential files. On Linux, use `auditd` to watch for writes to common credential locations from VS Code processes:
Watch for VS Code accessing SSH keys or cloud credentials auditctl -w /home/$USER/.ssh -p r -k vscode_ssh_access auditctl -w /home/$USER/.aws -p r -k vscode_aws_access Review logs for any accesses ausearch -k vscode_ssh_access
On Windows, use PowerShell to monitor for suspicious child processes launched by VS Code:
Enable Process Tracking via Auditpol
auditpol /set /subcategory:"Process Creation" /success:enable
Query the Security log for process creation events (Event ID 4688) where the parent process is code.exe
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4688} | Where-Object { $<em>.Properties[bash].Value -like "code.exe" } | Select-Object TimeCreated, @{Name='CommandLine';Expression={$</em>.Properties[bash].Value}}
What Undercode Say:
- Mutable tags are a supply chain liability: The Checkmarx KICS compromise proves that relying on mutable Docker tags like `latest` or version tags is dangerous. Always pin to immutable digests and verify signatures.
-
Developer tooling is the new frontier for attackers: Malicious VS Code extensions represent a highly effective way to compromise developer workstations and steal credentials. Organizations must treat extension management with the same rigor as other software supply chain risks.
-
Behavioral detection beats static IOCs: The TeamPCP campaign changes file hashes and C2 infrastructure frequently. Security teams must implement behavioral rules that detect credential scanning, unauthorized outbound data transfer, and anomalous process execution in CI/CD environments.
-
Assume compromise and rotate proactively: If your organization used the affected KICS images or VS Code extensions, assume that any secret present in scanned IaC files has been exfiltrated. Immediate credential rotation is not optional — it is mandatory.
-
Zero trust applies to CI/CD pipelines: The attack exploited the implicit trust between pipeline components. Implement least privilege for GitHub runners, use ephemeral build environments, and never store long-lived credentials in pipeline secrets unless absolutely necessary.
Prediction:
The Checkmarx KICS compromise is not an isolated event but a harbinger of a new wave of supply chain attacks targeting security and developer tooling. Threat actors like TeamPCP are increasingly focusing on tools that have privileged access to infrastructure secrets, as compromising a single scanner can provide access to hundreds of downstream organizations. Over the next 12 months, expect to see a surge in attacks against CI/CD pipelines, container registries, and IDE extensions, with a particular focus on tools that handle infrastructure-as-code. Organizations that fail to adopt immutable references, enforce software bill of materials (SBOM) verification, and implement runtime behavioral detection will face significant risk of credential theft and lateral movement. The industry must shift from reactive patching to proactive supply chain hardening, treating every dependency as a potential threat vector until proven otherwise.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecuritynews Share – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
