← Back to Cybersecurity News Center
Severity
HIGH
CVSS
9.5
Priority
0.775
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
LAPSUS$, using credentials stolen in a prior supply chain compromise of the open-source Trivy scanner, gained access to Checkmarx's private GitHub repositories and published malicious Docker images and IDE extensions for the KICS infrastructure-as-code security scanner. Approximately 96GB of data was exfiltrated and published across dark web and clearnet extortion portals. Security and development teams that downloaded Checkmarx KICS artifacts recently, Docker images, VSCode extensions, or Open VSX extensions, may have introduced trojanized tooling directly into their build and development pipelines.
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
HIGH
High severity — prioritize for investigation
Actor Attribution
HIGH
LAPSUS$, TeamPCP
TTP Sophistication
HIGH
12 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
Checkmarx KICS (malicious Docker images, VSCode extensions, Open VSX extensions), Trivy (supply chain compromise attributed to TeamPCP), GitHub private repositories
Are You Exposed?
⚠
Your industry is targeted by LAPSUS$, TeamPCP → Heightened risk
⚠
You use products/services from Checkmarx KICS (malicious Docker images → Assess exposure
⚠
12 attack techniques identified — review your detection coverage for these TTPs
✓
Your EDR/XDR detects the listed IOCs and TTPs → Reduced risk
✓
You have incident response procedures for this threat type → Prepared
Assessment estimated from severity rating and threat indicators
Business Context
A trojanized security scanner embedded in your development pipeline means credentials, secrets, and source code may have been harvested from the machines that run your builds — the same machines that have access to production infrastructure. If malicious KICS artifacts executed in your environment, the blast radius extends beyond the scanner itself to every secret accessible from those build agents. The 96GB data leak from Checkmarx's own repositories also raises the possibility that proprietary scan configurations, rule sets, or integration details belonging to Checkmarx customers were included in that exfiltration.
You Are Affected If
Your team uses Checkmarx KICS to scan infrastructure-as-code and pulled Docker images or installed VSCode/Open VSX extensions from public marketplaces in the past 90 days
Your CI/CD pipelines invoke Trivy as a vulnerability scanner and those pipelines share credentials or token stores with other tooling
Your build agents or developer workstations store credentials, API keys, SSH keys, or CI/CD secrets in locations accessible by scanner processes
Your organization uses Checkmarx KICS extensions installed from VSCode Marketplace or Open VSX without artifact hash verification
You have not audited your pipeline toolchain for artifact integrity following the Checkmarx incident disclosure
Board Talking Points
Attackers compromised a security tool used inside software development pipelines and may have stolen credentials and source code from affected organizations before the breach was discovered.
Security and development teams should audit all recent downloads of the affected tooling within 48 hours and rotate any credentials accessible from those systems.
Organizations that take no action risk persistent attacker access through stolen credentials and the potential for further data exfiltration or supply chain propagation.
Technical Analysis
Attack chain: Threat actor TeamPCP compromised Trivy's supply chain and harvested credentials (CWE-522: Insufficiently Protected Credentials).
LAPSUS$ leveraged those credentials via valid account abuse (T1078 ) to authenticate to Checkmarx's private GitHub repositories (T1213 ).
Attackers staged and published malicious artifacts, Docker Hub images and VSCode/Open VSX Marketplace extensions associated with Checkmarx KICS, containing trojanized binaries (T1554 ) assembled outside your organization's artifact provenance controls (CWE-829).
Downstream consumers who pulled these artifacts without integrity verification (CWE-494) were exposed to credential, key, token, and config file theft via malicious KICS tooling (T1552 ). Exfiltration of 96GB of data was routed over web services (T1567.001 /T1567.002 ). No CVE has been assigned; this is a supply chain compromise, not a software vulnerability. Affected artifact classes: Docker Hub images tagged as Checkmarx KICS, VSCode Marketplace extensions for KICS, Open VSX extensions for KICS. No vendor-confirmed safe version range has been published at the time of this item's creation, treat all recently pulled KICS artifacts as suspect pending Checkmarx's integrity verification guidance. CWEs: CWE-522, CWE-829, CWE-295, CWE-494. MITRE techniques: T1195.001 , T1554 , T1552 , T1078 , T1213 , T1567.001 , T1567.002 , T1059.004 , T1199 , T1608.001 , T1588.001 .
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to executive leadership, legal counsel, and your breach notification team immediately if GitHub audit logs confirm unauthorized access to repositories containing customer data, PII, PHI, PCI-scoped code, or regulated infrastructure configurations, as LAPSUS$'s confirmed 96GB exfiltration and public clearnet/dark web publication triggers breach notification obligations under GDPR Article 33, HIPAA 45 CFR §164.410, and applicable state breach notification laws; also escalate if rotated credentials show any post-rotation authentication activity indicating LAPSUS$ retains persistent access.
1
Step 1: Containment — Immediately quarantine hosts that pulled Checkmarx KICS Docker images or installed KICS VSCode/Open VSX extensions within the past 90 days. Block outbound connections from those hosts pending investigation. Cross-reference your asset inventory to confirm scope of affected endpoints. Consult the Checkmarx incident update for the vendor's confirmed artifact inventory and revocation list. (Cite: NIST AC-4 — Information Flow Enforcement / CIS 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory / CIS 4.4 — Implement and Manage a Firewall on Servers / D3-UAP — User Account Permissions)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy: isolate affected systems to prevent further credential exfiltration or lateral movement while preserving forensic state
NIST IR-4 (Incident Handling)
NIST SC-7 (Boundary Protection)
CIS 4.4 (Implement and Manage a Firewall on Servers)
CIS 4.5 (Implement and Manage a Firewall on End-User Devices)
Compensating Control
Use iptables or Windows Firewall to block all outbound traffic from affected build agents except to approved update servers: `iptables -I OUTPUT -j DROP` on Linux CI runners, then allowlist only internal registries. For Docker hosts, run `docker network disconnect <network> <container>` to isolate running KICS containers without destroying forensic state. Cross-reference Docker pull timestamps using `docker inspect --format='{{.Created}}' <image>` against the 90-day window. For VSCode, check `%APPDATA%\Code\User\extensions\` (Windows) or `~/.vscode/extensions/` (Linux/Mac) for KICS extension directories and record install timestamps before removal.
Preserve Evidence
BEFORE quarantine, capture: full outbound network connection state from build agents using `ss -tnp` (Linux) or `netstat -anob` (Windows) to document any active C2 or exfiltration connections initiated post-KICS execution; Docker daemon logs at `/var/log/docker` or `journalctl -u docker` showing exact image pull timestamps and image digests for all KICS images; VSCode extension manifest files at `~/.vscode/extensions/checkmarx.kics-*/package.json` recording the installed version hash; container runtime logs showing KICS process tree, environment variable exposure, and any volume mounts that could have exposed secrets.
2
Step 2: Detection — Audit Docker pull history and container registries for KICS image tags. Query IDE extension logs (Intune, Jamf, or local manifests) for KICS VSCode or Open VSX installation events. Review CI/CD pipeline logs for Trivy and KICS invocations. Search SIEM for outbound connections from build agents to unrecognized external hosts post-KICS execution. Examine processes spawned by KICS binaries accessing credential files, .env files, ~/.ssh/, or CI/CD secret variables. Pull GitHub audit logs for service account authentication events associated with Trivy or Checkmarx-adjacent tokens. (Cite: NIST AU-2 — Event Logging / NIST AU-6 — Audit Record Review, Analysis, And Reporting / NIST AU-12 — Audit Record Generation / CIS 8.2 — Collect Audit Logs / D3-SFA — System File Analysis / D3-LAM — Local Account Monitoring)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis: correlate artifact pull events, process execution chains, and GitHub authentication anomalies to establish the full scope of LAPSUS$ access and malicious artifact execution
NIST IR-5 (Incident Monitoring)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST AU-12 (Audit Record Generation)
NIST SI-4 (System Monitoring)
CIS 8.2 (Collect Audit Logs)
Compensating Control
For teams without SIEM: use `docker history <image>` and `docker inspect <image>` to enumerate layers and environment variables baked into pulled KICS images; compare image digest SHA256 against any vendor-published clean hashes. Query GitHub audit log via API (`GET /orgs/{org}/audit-log?phrase=actor:kics+action:git.clone`) filtering for service account activity. On CI runners (Jenkins, GitLab, GitHub Actions), grep pipeline logs for Trivy and KICS execution: `grep -rE '(trivy|kics)' /var/log/jenkins/` or equivalent. Use osquery to hunt credential file access: `SELECT * FROM file_events WHERE path LIKE '%/.ssh/%' OR path LIKE '%/.aws/credentials' AND time > <epoch_90_days_ago>;`. Write a Sigma rule targeting process creation where parent process matches KICS or Trivy executables spawning curl, wget, or python with outbound IP arguments — reference MITRE ATT&CK T1552.001 (Credentials in Files) and T1041 (Exfiltration Over C2 Channel).
Preserve Evidence
GitHub organization audit log entries for the 90-day window showing: OAuth token authentications, repository clone/fork events from Trivy or KICS service accounts, and any `git.push` or package publish events from non-human actors consistent with LAPSUS$ TTPs (MITRE T1586.002 — Compromise Accounts); CI/CD pipeline execution logs from GitHub Actions (`.github/workflows/` runner logs), Jenkins build history, or GitLab CI job traces showing KICS and Trivy invocation arguments, environment variable injection, and any unexpected network calls during scan steps; Docker registry pull logs (Docker Hub access logs or internal registry logs) with image digests for `checkmarx/kics` pulls, specifically flagging any digest that does not match Checkmarx's pre-incident verified hash list; process execution telemetry (Sysmon Event ID 1 or auditd `execve`) on build agents showing child processes spawned by KICS or Trivy binaries, particularly shell spawns, curl/wget calls, or SSH invocations inconsistent with normal scanner behavior.
3
Step 3: Eradication — Remove all KICS Docker images and IDE extensions sourced from Docker Hub or marketplace registries. Per CIS 2.3, treat these as unauthorized software until Checkmarx publishes verified clean artifact hashes. Rotate all credentials, API keys, tokens, and SSH keys present on systems where malicious artifacts executed — prioritize CI/CD pipeline secrets and repository tokens. Revoke and reissue secrets stored in any repository or pipeline accessible from a compromised host. Do not reinstall KICS tooling until Checkmarx confirms a clean release with verified hashes. (Cite: NIST AC-2 — Account Management / CIS 2.3 — Address Unauthorized Software / CIS 5.1 — Establish and Maintain an Inventory of Accounts / D3-CRO — Credential Rotation / D3-CH — Credential Hardening)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication: remove malicious KICS and Trivy artifacts from all execution environments and eliminate all credentials that were accessible to those artifacts, given LAPSUS$'s established pattern of credential harvesting and repository exfiltration
NIST IR-4 (Incident Handling)
NIST SI-2 (Flaw Remediation)
NIST IA-5 (Authenticator Management)
CIS 5.2 (Use Unique Passwords)
CIS 7.2 (Establish and Maintain a Remediation Process)
Compensating Control
Remove KICS Docker images from all hosts: `docker rmi -f $(docker images | grep kics | awk '{print $3}')` and purge from local cache with `docker system prune -a`. For VSCode, run `code --uninstall-extension checkmarx.kics` or manually delete from `~/.vscode/extensions/`. Enumerate all secrets accessible to CI runners during the suspect window using GitHub's secret scanning API (`GET /repos/{owner}/{repo}/secret-scanning/alerts`) and revoke any flagged tokens immediately. For SSH key rotation, audit `~/.ssh/authorized_keys` and `known_hosts` on all build agents, revoke any key pairs generated before or during the suspect window, and reissue using `ssh-keygen -t ed25519`. For GitHub Actions, rotate all repository and organization secrets via Settings > Secrets and re-scope service account PATs to minimum required permissions. Use `truffleHog` or `git-secrets` CLI to scan repository history for any secrets inadvertently committed during the period KICS had repository access.
Preserve Evidence
Before credential rotation, preserve forensic copies of: the full list of GitHub repository secrets, Actions environment variables, and CI/CD pipeline variable stores accessible from compromised runners (document names only, not values, for chain-of-custody); SSH `authorized_keys` and `known_hosts` files from all build agents to establish which keys were present during the exposure window; any `.env` files, `kubeconfig` files, cloud provider credential files (`~/.aws/credentials`, `~/.azure/`, `~/.config/gcloud/`) found on compromised hosts; Docker image layer contents extracted via `docker save <image> | tar xv` to identify what malicious payload was embedded in the KICS image layers, specifically looking for added scripts in `/usr/local/bin/`, modified entrypoints, or injected environment variable exfiltration routines.
4
Step 4: Recovery — Verify artifact integrity against vendor-published hashes before reinstalling any KICS tooling. Re-scan all code and infrastructure previously analyzed by KICS during the suspect window using a verified clean instance or an alternative scanner. Per NIST AC-2, confirm no unauthorized service accounts or tokens persist with access to affected repositories. Monitor GitHub audit logs and SIEM for anomalous authentication events using rotated credentials for at least 30 days post-remediation. Confirm audit logging is continuous and storage capacity is sufficient for the retention window. (Cite: NIST AC-2 — Account Management / NIST AU-4 — Audit Storage Capacity / NIST AU-11 — Audit Record Retention / CIS 6.2 — Establish an Access Revoking Process / D3-LAM — Local Account Monitoring)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery: restore pipeline integrity only after verified clean artifacts are available, and implement 30-day anomalous authentication monitoring to detect any LAPSUS$-held credentials being used post-rotation
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST IR-4 (Incident Handling)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
CIS 7.3 (Perform Automated Operating System Patch Management)
CIS 7.4 (Perform Automated Application Patch Management)
Compensating Control
Verify KICS artifact integrity using `sha256sum` against Checkmarx-published hashes before any reinstallation: `echo '<vendor_hash> checkmarx-kics-<version>.tar.gz' | sha256sum -c`. For Docker images, verify digest: `docker pull checkmarx/kics:<version>@sha256:<vendor_digest>`. Re-scan IaC previously processed by KICS using Semgrep (free tier), Checkov, or Terrascan as alternative scanners — specifically re-analyze any Terraform, CloudFormation, Kubernetes, or Dockerfile content that KICS scanned during the 90-day window, as LAPSUS$ may have exfiltrated those files. Monitor GitHub audit logs daily for 30 days using: `GET /orgs/{org}/audit-log?phrase=action:git&after=<rotation_date>` and alert on any authentication from IP addresses not matching known CI/CD egress ranges. Use `fail2ban` or equivalent on CI runners to alert on repeated authentication failures with new credentials, which could indicate LAPSUS$ testing rotated credential validity.
Preserve Evidence
During recovery validation, collect and retain: GitHub audit log exports covering the 30-day post-rotation monitoring window, specifically filtering for `git.clone`, `git.push`, and OAuth token usage events; re-scan outputs from the alternative IaC scanner (Checkov, Semgrep) for the same codebase scope previously covered by KICS, preserving diff reports that could indicate LAPSUS$ had access to sensitive infrastructure configurations; network flow logs or firewall logs from CI/CD egress points during the monitoring window to confirm no outbound connections to the same external IPs or domains observed during the initial KICS execution period; authentication logs from cloud providers (AWS CloudTrail, Azure Activity Log, GCP Audit Log) for API calls using credentials that were present on compromised hosts, covering the full 90-day suspect window plus 30-day post-rotation monitoring period.
5
Step 5: Post-Incident — Conduct a pipeline dependency audit using D3-ODM to map every open-source tool in your CI/CD chain and document the trust boundary for each. Implement artifact signing and hash verification for all third-party tooling pulled into pipelines. Apply least privilege (NIST AC-6) to all scanner service accounts — KICS and Trivy should carry read-only, scoped permissions with no exfiltration-capable access. Enforce MFA on all accounts with repository or pipeline access. Review and harden credential storage across repositories and pipelines. Add CI/CD pipeline steps to startup configuration review scope. (Cite: NIST AC-6 — Least Privilege / NIST AC-2 — Account Management / CIS 5.4 — Restrict Administrator Privileges to Dedicated Administrator Accounts / CIS 6.3 — Require MFA for Externally-Exposed Applications / CIS 6.5 — Require MFA for Administrative Access / D3-ODM — Operational Dependency Mapping / D3-CH — Credential Hardening / D3-SICA — System Init Config Analysis)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity: lessons learned from LAPSUS$'s exploitation of Trivy's supply chain trust to pivot into Checkmarx must drive systematic hardening of all open-source scanner integrations and CI/CD trust boundaries
NIST IA-5 (Authenticator Management)
NIST SC-28 (Protection of Information at Rest)
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST CM-7 (Least Functionality)
NIST IR-8 (Incident Response Plan)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 5.4 (Restrict Administrator Privileges to Dedicated Administrator Accounts)
CIS 2.2 (Ensure Authorized Software is Currently Supported)
Compensating Control
Implement SLSA provenance verification using the free `slsa-verifier` CLI tool (`slsa-verifier verify-artifact`) for any open-source scanner binary pulled into CI/CD pipelines, starting with Trivy and KICS as the two tools directly implicated in this campaign. Pin all Docker image references in pipeline configs to immutable SHA256 digests rather than mutable tags (e.g., replace `checkmarx/kics:latest` with `checkmarx/kics@sha256:<digest>`). Enforce least-privilege for scanner service accounts: GitHub Actions KICS and Trivy steps should run with a scoped token granting `contents:read` only — add `permissions: contents: read` to the workflow YAML block. Use `cosign` (free, Sigstore project) to verify image signatures: `cosign verify <image>` before any pipeline pull. Document each open-source tool in your CI/CD chain in a software bill of materials (SBOM) using `syft` CLI: `syft <image> -o spdx-json > sbom.json` — this gives you a baseline to detect future supply chain tampering. Schedule a quarterly review of all CI/CD-integrated scanners against their upstream project health indicators (release cadence, maintainer activity, recent security advisories).
Preserve Evidence
For lessons-learned documentation and future detection baselining, preserve: the complete CI/CD dependency map produced by the pipeline audit, including all Docker image references, their pull sources, and pinned vs. floating tag usage — this becomes the baseline for detecting future supply chain drift; SBOM outputs generated by `syft` or equivalent for all scanner images currently in use, establishing a known-good artifact inventory against which future image digests can be compared; GitHub Actions workflow YAML files from the incident period documenting the permission scopes granted to KICS and Trivy steps, to evidence the over-privileged access that enabled LAPSUS$ to reach repository secrets; a documented trust boundary map identifying which CI/CD service accounts had access to which secret stores, repository scopes, and cloud provider credentials — this directly addresses the attack path LAPSUS$ used to pivot from Trivy's supply chain compromise into Checkmarx's GitHub repositories and ultimately to the 96GB exfiltration.
Recovery Guidance
Before restoring KICS or Trivy to any pipeline, require Checkmarx to publish SHA256 hashes and SLSA provenance attestations for the clean release, then verify each artifact independently using `sha256sum` and `slsa-verifier` before deployment. Re-execute all IaC security scans performed by KICS during the 90-day suspect window using a verified alternative scanner (Checkov, Semgrep, or Terrascan) and treat any previously clean scan results as untrusted until re-validated, since the malicious KICS artifact may have suppressed or falsified findings. Maintain enhanced GitHub audit log monitoring and cloud provider API call alerting for a minimum of 30 days post-credential rotation, given LAPSUS$'s documented pattern of maintaining persistent access through secondary credential stores and OAuth token abuse.
Key Forensic Artifacts
Docker daemon pull logs and image digests: `/var/log/docker` or `journalctl -u docker` on Linux build agents — cross-reference all `checkmarx/kics` image digests pulled during the 90-day window against Checkmarx's pre-incident verified digest list to identify exactly which hosts executed the malicious image layers
GitHub organization audit log (REST API or exported CSV): filter for `git.clone`, `git.push`, OAuth token creation/use, and repository permission changes attributed to service accounts associated with Trivy or KICS CI/CD integrations — this directly maps LAPSUS$'s lateral movement path from the Trivy supply chain compromise into Checkmarx's private repositories
CI/CD pipeline execution logs with KICS and Trivy invocation records: GitHub Actions runner logs, Jenkins build logs, or GitLab CI job traces capturing process arguments, environment variable exposure, and any unexpected network calls (curl/wget to non-registry endpoints) during scanner execution steps — these establish what credentials KICS had access to and whether exfiltration occurred
File system access audit records on build agents for credential file paths: auditd logs (`ausearch -k credential_access`) or Sysmon Event ID 11 (FileCreate) and Event ID 10 (ProcessAccess) filtered on paths matching `~/.ssh/`, `~/.aws/credentials`, `~/.kube/config`, `.env` files, and GitHub Actions runner `_work/` directories — identifies which secrets the malicious KICS artifact accessed or staged for exfiltration
VSCode extension install records and VSIX package manifests: `~/.vscode/extensions/checkmarx.kics-*/` directory contents including `package.json` (version and publisher hash), any bundled JavaScript with obfuscated network calls, and VSCode extension host logs at `~/.config/Code/logs/` — the malicious Open VSX/VSCode extension would leave behavioral artifacts in the extension host process logs distinct from the legitimate KICS scanner extension
Detection Guidance
Log sources and behavioral indicators grounded in KB controls:
**Container and Artifact Integrity (D3-SFA / D3-FMBV / NIST AU-2 / CIS 8.2):** Query Docker registry pull logs for KICS image tags pulled from Docker Hub within the past 90 days.
Compare image digests against vendor-confirmed clean hashes when published.
Use D3-FMBV (File Magic Byte Verification) to validate that container image layers and binary payloads match expected magic bytes — flag discrepancies as tampered artifacts.
Enable NIST AU-12 (Audit Record Generation) on container runtime environments to capture all pull and execution events.
**IDE and Extension Monitoring (D3-SFA / NIST AU-6 / CIS 2.1):** Query endpoint management platforms (Intune, Jamf, or local extension manifests) for KICS VSCode or Open VSX extension installation events. Cross-reference installed extensions against CIS 2.1 (Establish and Maintain a Software Inventory) and flag any KICS extension not present in the approved software inventory. Use D3-SFA to monitor extension directories and configuration files for unauthorized modification post-installation.
**CI/CD Pipeline and Process Behavior (D3-SFA / D3-SICA / NIST AU-6 / CIS 8.2):** Review pipeline execution logs for Trivy and KICS invocations. Per D3-SICA (System Init Config Analysis), inspect startup configuration and pipeline step definitions for unexpected additions or modifications that could indicate trojanized tooling. Flag any pipeline step that initiates outbound connections to hosts not in your approved egress list — particularly cloud storage endpoints (S3, GCS, Azure Blob) consistent with T1567.002 exfiltration behavior. NIST AU-6 (Audit Record Review, Analysis, And Reporting) requires periodic review of these records for anomalous indicators.
**Credential and Secret Access (D3-SFA / D3-LAM / NIST AU-6 / NIST AU-12):** Monitor processes spawned by KICS or Trivy binaries for file access events targeting .env files, ~/.ssh/ directories, token stores, or CI/CD secret variable paths. D3-SFA applies directly — treat these as monitored system files. D3-LAM (Local Account Monitoring) should cover service accounts used by scanner processes; alert on any local account activity outside expected scanner execution patterns.
**GitHub and Repository Access (D3-LAM / NIST AU-6 / NIST AU-3 / CIS 5.1):** Pull GitHub audit logs for repository access events authenticated with service accounts or tokens associated with Checkmarx or Trivy integrations. Per NIST AU-3 (Content Of Audit Records), ensure log entries capture: event type, timestamp, source identity, and resource accessed. Flag authentication events from unexpected source IPs, token reuse across multiple source addresses, or access to private repositories by accounts not in CIS 5.1 (Establish and Maintain an Inventory of Accounts).
**Network Egress (NIST AC-4 / CIS 4.4 / CIS 4.5 / D3-PBWSAM):** Alert on outbound traffic from build agents or developer workstations to previously unobserved external destinations. Apply NIST AC-4 (Information Flow Enforcement) controls to CI/CD network segments — scanner processes should not initiate connections outside approved artifact registries. D3-PBWSAM (Proxy-based Web Server Access Mediation) can enforce and log egress from pipeline runners through an inspecting proxy, enabling detection of anomalous exfiltration attempts consistent with T1567.001 and T1567.002 .
**Audit Log Integrity and Retention (NIST AU-4 / NIST AU-9 / NIST AU-11):** Confirm audit log storage capacity (NIST AU-4) is sufficient to retain CI/CD, container, and GitHub audit events for the full suspect window. Protect audit logs from unauthorized modification per NIST AU-9 (Protection Of Audit Information) — treat pipeline and registry pull logs as audit artifacts. Retain records per NIST AU-11 (Audit Record Retention) to support post-incident forensic analysis.
Indicators of Compromise (3)
Export as
Splunk SPL
KQL
Elastic
Copy All (3)
3 urls
Type Value Enrichment Context Conf.
🔗 URL
https://hub.docker.com/ (KICS-tagged images — specific malicious image digests to be confirmed via Checkmarx advisory)
VT
US
Malicious Docker images published under Checkmarx KICS branding on Docker Hub
MEDIUM
🔗 URL
VSCode Marketplace — KICS extension (specific extension ID and version to be confirmed via Checkmarx advisory)
VT
US
Trojanized VSCode extension for Checkmarx KICS distributed via official marketplace
MEDIUM
🔗 URL
Open VSX Registry — KICS extension (specific extension ID and version to be confirmed via Checkmarx advisory)
VT
US
Trojanized Open VSX extension for Checkmarx KICS
MEDIUM
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
Hard indicator (direct match)
Contextual (behavioral query)
Shared platform (review required)
IOC Detection Queries (2)
2 URL indicator(s).
KQL Query Preview
Read-only — detection query only
// Threat: LAPSUS$ Exploits Trivy Supply Chain Breach to Compromise Checkmarx GitHub, Publi
let malicious_urls = dynamic(["VSCode Marketplace — KICS extension (specific extension ID and version to be confirmed via Checkmarx advisory)", "Open VSX Registry — KICS extension (specific extension ID and version to be confirmed via Checkmarx advisory)"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (malicious_urls)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Malicious URLs hosted on legitimate platforms. The domain is safe — the specific URL path is the indicator.
KQL Query Preview
Read-only — detection query only
// Threat: LAPSUS$ Exploits Trivy Supply Chain Breach to Compromise Checkmarx GitHub, Publi
// Specific malicious URLs on shared platforms
let suspicious_urls = dynamic(["https://hub.docker.com/ (KICS-tagged images — specific malicious image digests to be confirmed via Checkmarx advisory)"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (suspicious_urls)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
MITRE ATT&CK Hunting Queries (4)
Sentinel rule: Ransomware activity
KQL Query Preview
Read-only — detection query only
DeviceFileEvents
| where Timestamp > ago(7d)
| where ActionType == "FileRenamed"
| where FileName endswith_any (".encrypted", ".locked", ".crypto", ".crypt", ".enc", ".ransom")
| summarize RenamedFiles = count() by DeviceName, InitiatingProcessFileName, bin(Timestamp, 5m)
| where RenamedFiles > 20
| sort by RenamedFiles desc
Sentinel rule: Suspicious PowerShell command line
KQL Query Preview
Read-only — detection query only
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe")
| where ProcessCommandLine has_any ("-enc", "-nop", "bypass", "hidden", "downloadstring", "invoke-expression", "iex", "frombase64", "new-object net.webclient")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName, InitiatingProcessFileName
| sort by Timestamp desc
Sentinel rule: Sign-ins from unusual locations
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Locations = make_set(Location), LoginCount = count(), DistinctIPs = dcount(IPAddress) by UserPrincipalName
| where array_length(Locations) > 3 or DistinctIPs > 5
| sort by DistinctIPs desc
Sentinel rule: Supply chain / cross-tenant access
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where HomeTenantId != ResourceTenantId
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, HomeTenantId, ResourceTenantId
| sort by TimeGenerated desc
No actionable IOCs for CrowdStrike import (benign/contextual indicators excluded).
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
T1486
T1213
T1195.001
T1608.001
T1588.001
T1552
+6
CP-9
CP-10
CM-7
SI-3
SI-4
AC-2
+8
A04:2021
A07:2021
A02:2021
A08:2021
5.2
3.10
2.5
2.6
6.3
15.1
164.308(a)(5)(ii)(D)
164.312(d)
MITRE ATT&CK Mapping
T1486
Data Encrypted for Impact
impact
T1213
Data from Information Repositories
collection
T1195.001
Compromise Software Dependencies and Development Tools
initial-access
T1608.001
Upload Malware
resource-development
T1552
Unsecured Credentials
credential-access
T1078
Valid Accounts
defense-evasion
T1567.002
Exfiltration to Cloud Storage
exfiltration
T1199
Trusted Relationship
initial-access
T1567.001
Exfiltration to Code Repository
exfiltration
T1554
Compromise Host Software Binary
persistence
Guidance Disclaimer
The analysis, framework mappings, and incident response recommendations in this intelligence
item are derived from established industry standards including NIST SP 800-61, NIST SP 800-53,
CIS Controls v8, MITRE ATT&CK, and other recognized frameworks. This content is provided
as supplemental intelligence guidance only and does not constitute professional incident response
services. Organizations should adapt all recommendations to their specific environment, risk
tolerance, and regulatory requirements. This material is not a substitute for your organization's
official incident response plan, legal counsel, or qualified security practitioners.
View All Intelligence →