← Back to Cybersecurity News Center
Severity
CRITICAL
CVSS
9.5
Priority
0.850
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
Beginning March 23, 2026, threat actors attributed to LAPSUS$ (also tracked as TeamPCP by threat intelligence sources) compromised multiple components of the Checkmarx developer security toolchain, including KICS Docker images, GitHub Actions workflows, VS Code extensions distributed via Open VSX, and the Bitwarden CLI npm package. LAPSUS$ claimed responsibility for exfiltrating Checkmarx GitHub repository content, including source code, API keys, and database credentials, and published alleged data on a dark web leak site. Any development team that executed the compromised tooling during the exposure window faces elevated risk of credential theft, code integrity compromise, and downstream supply chain contamination in their own software pipelines.
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
CRITICAL
Critical severity — immediate action required
Actor Attribution
HIGH
TeamPCP, LAPSUS$
TTP Sophistication
HIGH
9 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
Checkmarx KICS Docker image, Checkmarx GitHub Actions workflows, Open VSX plugins, Bitwarden CLI (npm package), VS Code extensions, Trivy (supply chain vector)
Are You Exposed?
⚠
Your industry is targeted by TeamPCP, LAPSUS$ → Heightened risk
⚠
You use products/services from Checkmarx KICS Docker image → Assess exposure
⚠
9 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
Business Context
Development teams that ran Checkmarx security tooling between March 23 and April 22, 2026, may have inadvertently executed attacker-controlled code inside their own software build environments, creating a path for credentials, source code, and secrets to be stolen from their organizations. If compromised credentials were used to access internal systems or cloud environments, the downstream impact extends beyond the Checkmarx incident itself into the organization's own software supply chain and customer-facing products. Organizations in regulated industries whose development pipelines touched the affected tooling face potential compliance exposure if customer or sensitive data passed through those environments.
You Are Affected If
You ran Checkmarx KICS Docker images pulled after March 23, 2026, without digest pinning to a pre-compromise image version
Your CI/CD pipelines used Checkmarx GitHub Actions workflows executed between March 23 and April 22, 2026
Developers in your organization installed VS Code extensions sourced from Open VSX during the exposure window
Your environment installed the Bitwarden CLI via npm and the installed version has not been verified against known-good package hashes
API keys, database credentials, or private keys were present in environment variables or secrets stores accessible to the affected pipeline components during the exposure window
Board Talking Points
Attackers compromised the security scanning tools Checkmarx provides to development teams, turning those tools into a channel for stealing credentials and source code from any organization that ran them between March 23 and April 22, 2026.
Development and security teams should audit all pipeline activity from that window this week, rotate any exposed credentials immediately, and verify no malicious code was introduced into internally developed software.
Organizations that do not act risk persistent attacker access through stolen credentials, potential exposure of proprietary source code, and downstream compromise of their own software products.
Technical Analysis
The attack chain attributed to LAPSUS$ targeted Checkmarx infrastructure across multiple vectors simultaneously.
Malicious KICS Docker images were published and distributed as legitimate scanning tools; GitHub Actions workflows were tampered to execute attacker-controlled code during CI/CD pipeline runs; VS Code extensions were poisoned and pushed via the Open VSX registry.
The Bitwarden CLI npm package was compromised; evidence suggests the compromise resulted from credential-stealing malware propagated through the Checkmarx toolchain, though the exact infection vector has not been publicly confirmed.
Relevant CWEs: CWE-494 (Download of Code Without Integrity Check), CWE-312 (Cleartext Storage of Sensitive Information), CWE-798 (Use of Hard-coded Credentials), CWE-506 (Embedded Malicious Code). MITRE ATT&CK techniques include T1195.001 and T1195.002 (Supply Chain Compromise), T1528 (Steal Application Access Token), T1078 (Valid Accounts), T1552.001 and T1552.004 (Credentials in Files, Private Keys), T1059 (Command and Scripting Interpreter), T1567.001 (Exfiltration to Code Repository), T1213 (Data from Information Repositories). Checkmarx confirmed unauthorized access to its GitHub repository. The company states no customer production data is stored in the affected repository, but the scope of credential exposure from compromised tooling remains unresolved. No CVE has been assigned. Checkmarx issued a security update on April 22, 2026; affected version ranges and patch details are documented in the official advisory at checkmarx.com. Specific IOC hashes and malicious image digests have not yet been published in available reporting; monitor Checkmarx's security advisory page for updated indicators as the investigation progresses. Source confidence: moderate (0.64 on 0.0-1.0 scale), pending official threat intelligence corroboration.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to executive leadership, legal counsel, and potentially regulatory authorities immediately if forensic review of GitHub Actions logs or secrets manager audit trails confirms that production database credentials, customer PII, or regulated data (PCI card data, PHI, or data subject to GDPR/CCPA breach notification thresholds) were accessible to compromised KICS, Bitwarden CLI, or Open VSX extension processes during the March 23–April 22 window, or if LAPSUS$ dark web publications are confirmed to contain your organization's identifiers, source code, or credentials.
1
Step 1: Containment — Audit all CI/CD pipelines, Docker image registries, and VS Code extension installations for Checkmarx components executed since March 23, 2026. Cross-reference all pipeline tooling against your software inventory to identify unauthorized or unverified assets. Immediately revoke and rotate all credentials, API keys, and tokens present in environments where affected components executed. Suspend Bitwarden CLI npm package usage pending integrity verification. Apply AC-6 (Least Privilege) by restricting pipeline service account permissions to the minimum required while containment is active. Apply D3-CRO (Credential Rotation) for all secrets exposed to affected pipeline steps. Apply D3-UAP (User Account Permissions) to restrict access to affected pipeline environments during investigation. (Cite: NIST AC-6, NIST AC-2 / CIS 2.1, CIS 5.1 / D3-CRO, D3-UAP)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy (CSF [RS]: Execute IR plan, categorize, contain, communicate, mitigate)
NIST IR-4 (Incident Handling)
NIST AC-2 (Account Management) — revocation of exposed credentials and API keys
NIST CM-2 (Baseline Configuration) — isolating deviations from known-good pipeline configurations
CIS 2.3 (Address Unauthorized Software) — removing unauthorized or suspect KICS Docker images and Open VSX extensions
CIS 5.1 (Establish and Maintain an Inventory of Accounts) — identifying all service accounts and tokens exposed to compromised pipeline steps
Compensating Control
For a 2-person team without enterprise tooling: (1) Run `docker images --filter reference='checkmarx/*'` and `docker ps -a` on all build hosts to enumerate pulled KICS images; cross-reference digests against Checkmarx's April 22 advisory hashes. (2) Query GitHub Actions run history via `gh run list --limit 200 --json conclusion,workflowName,createdAt` to surface all workflow executions since 2026-03-23. (3) Scan `.env` files, GitHub Actions secrets, and CI environment variable exports with truffleHog (`trufflehog filesystem --directory=.`) to enumerate secrets accessible during the exposure window. (4) For npm: run `npm list --depth=0 @bitwarden/cli` across all developer workstations using a simple bash loop or Ansible ad-hoc command.
Preserve Evidence
BEFORE revoking credentials or removing images, preserve the following: (1) Docker image digests (`docker inspect --format='{{index .RepoDigests 0}}' <image>`) for every pulled Checkmarx KICS image — these are the forensic anchors for integrity comparison. (2) Full GitHub Actions workflow run logs from March 23–present, downloadable via `gh run view <run-id> --log`; look specifically for `actions/checkout` steps, outbound curl/wget calls in KICS scan steps, and any `env` export commands. (3) npm install logs at `~/.npm/_logs/` and `package-lock.json` snapshots showing the exact `@bitwarden/cli` version hash installed on each affected system. (4) A snapshot of all environment variables accessible to the compromised pipeline steps — export via `printenv` executed in the same execution context before teardown.
2
Step 2: Detection — Review CI/CD pipeline logs per AU-2 (Event Logging) for unexpected outbound network connections, anomalous process execution (T1059), and unauthorized repository access from KICS, GitHub Actions, or VS Code extension processes between March 23 and April 22, 2026. Per AU-3 (Content Of Audit Records), confirm logs capture what occurred, when, where, from what source, and by which identity. Audit secrets management systems and environment variable stores for API keys or credentials exposed to compromised pipeline steps (T1552.001, T1552.004). Apply D3-LAM (Local Account Monitoring) to detect unauthorized local account activity on pipeline runner nodes. Apply D3-SFA (System File Analysis) to check pipeline configuration files and GitHub Actions workflow YAML files for unauthorized modifications. Use AU-6 (Audit Record Review, Analysis, And Reporting) to drive structured review of collected pipeline telemetry. (Cite: NIST AU-2, NIST AU-3, NIST AU-6 / CIS 8.2 / D3-LAM, D3-SFA)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis (CSF [DE]: Monitor, detect, analyze, correlate, triage adverse events)
NIST SI-4 (System Monitoring) — monitoring CI/CD runtime environments for anomalous process and network behavior
NIST AU-6 (Audit Record Review, Analysis, and Reporting) — structured review of GitHub Actions, Docker daemon, and npm logs for indicators of LAPSUS$/TeamPCP activity
NIST IR-5 (Incident Monitoring) — tracking and documenting all pipeline executions and credential exposure events across the March 23–April 22 window
CIS 8.2 (Collect Audit Logs) — ensuring pipeline execution logs, Docker daemon logs, and npm audit logs are collected and retained
CIS 7.1 (Establish and Maintain a Vulnerability Management Process) — cross-referencing installed component versions against the compromised version list from Checkmarx's advisory
Compensating Control
For a 2-person team: (1) Use `falco` (free, open source) with a custom rule targeting container image names matching `checkmarx/kics*` to alert on anomalous syscalls (unexpected `connect()`, `execve()` of shells, file writes outside expected scan output paths). (2) On build hosts, run `ss -tnp` or `netstat -tnp` and cross-reference outbound connections from KICS container PIDs against expected Checkmarx scan endpoints — any connection to non-Checkmarx IPs during scan execution is a high-fidelity IOC. (3) For GitHub Actions log analysis without SIEM, use `gh api` to pull workflow run logs and pipe through `grep -E '(curl|wget|nc |ncat|/bin/sh|/bin/bash|base64 -d)'` to surface common exfiltration or shell-spawn patterns embedded in compromised workflow steps. (4) For Bitwarden CLI npm compromise detection, compare the SHA-512 hash of the installed package tarball (`npm cache verify` or manually via `sha512sum $(npm root -g)/@bitwarden/cli/package.json`) against the known-clean version hash from the npm registry integrity field.
Preserve Evidence
Preserve before analysis is complete: (1) GitHub Actions runner audit logs — specifically look for OIDC token requests, `secrets.*` variable references, and outbound HTTPS POSTs in KICS and Bitwarden CLI steps; these are the primary exfiltration vectors LAPSUS$ would have used to harvest API keys and database credentials. (2) Docker daemon logs (`/var/log/docker.log` or `journalctl -u docker`) for the exposure window, filtering on KICS image names — look for unexpected `iptables` changes or network namespace escapes. (3) VS Code extension host logs at `~/.config/Code/logs/` (Linux) or `%APPDATA%\Code\logs\` (Windows), specifically `exthost*.log` entries for Open VSX-sourced Checkmarx extensions — malicious extensions may log credential reads or outbound API calls here. (4) npm audit output (`npm audit --json > npm_audit_snapshot.json`) and the `package-lock.json` integrity hashes for `@bitwarden/cli` on all affected developer workstations, preserved as timestamped evidence before any remediation.
3
Step 3: Eradication — Replace all KICS Docker images, GitHub Actions workflow files, and Open VSX extensions with versions verified against Checkmarx's official integrity guidance from the April 22, 2026 security update. Remove and reinstall the Bitwarden CLI npm package after confirming a clean, verified version is available. Per CIS 2.3 (Address Unauthorized Software), remove any unauthorized or unverified software versions identified during containment. Per CIS 4.6 (Securely Manage Enterprise Assets and Software), manage replacement tooling through version-controlled configuration to prevent re-introduction of compromised components. Rotate all secrets, API keys, private keys, and database credentials accessible in any environment where compromised components executed, applying D3-CRO (Credential Rotation) and D3-CH (Credential Hardening). (Cite: NIST AC-2, NIST AC-6 / CIS 2.3, CIS 4.6 / D3-CRO, D3-CH)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication (CSF [RS]: Remove threat from environment, verify eradication)
NIST SI-2 (Flaw Remediation) — replacing compromised KICS Docker images, GitHub Actions workflows, and Bitwarden CLI npm package with integrity-verified clean versions per Checkmarx's April 22 advisory
NIST SI-7 (Software, Firmware, and Information Integrity) — verifying Docker image digests and npm package integrity hashes against Checkmarx-published values before reintroduction to pipelines
NIST AC-2 (Account Management) — rotating all service account credentials, API keys, and database credentials exposed during the March 23–April 22 window
CIS 7.2 (Establish and Maintain a Remediation Process) — executing credential rotation and component replacement on a risk-prioritized basis, starting with database credentials and production API keys
CIS 4.6 (Securely Manage Enterprise Assets and Software) — managing replacement pipeline components through version-controlled configuration to prevent re-introduction of compromised versions
Compensating Control
For a 2-person team: (1) Pull the clean KICS Docker image with explicit digest pinning: `docker pull checkmarx/kics@sha256:<digest-from-april22-advisory>` — do not pull by tag alone, as tags are mutable and were the likely injection point. (2) Use `cosign verify` (free, Sigstore project) to validate image signatures if Checkmarx has published signed manifests in their April 22 update. (3) For Bitwarden CLI npm replacement: `npm uninstall -g @bitwarden/cli && npm cache clean --force && npm install -g @bitwarden/cli@<verified-clean-version>` — verify the installed package hash with `npm ls --json @bitwarden/cli`. (4) For GitHub Actions workflow replacement, use `git diff HEAD~30 -- .github/workflows/` to compare current workflow files against pre-March 23 state and verify no unauthorized steps were introduced before replacing with Checkmarx-verified workflow content.
Preserve Evidence
Before eradicating components, preserve: (1) Full filesystem snapshot or container layer export (`docker save checkmarx/kics:<compromised-tag> -o kics_compromised_evidence.tar`) of each affected KICS image for post-incident forensic analysis — these images are the primary malware delivery vehicle and must not be deleted without preservation. (2) A copy of all GitHub Actions `.yml` workflow files in their current compromised-window state, committed to an evidence branch with `git stash` or archived — diff against Checkmarx's official workflow templates to identify injected steps. (3) npm package tarball of the compromised Bitwarden CLI version, preserved from npm cache (`~/.npm/_cacache/`) before cache flush. (4) HashiCorp Vault, AWS Secrets Manager, or equivalent audit logs showing which secrets were accessed or read by pipeline service accounts during the exposure window — this defines the full credential rotation scope.
4
Step 4: Recovery — Validate that rebuilt pipeline environments produce expected checksums and exhibit no anomalous runtime behavior before restoring production workloads. Per CIS 2.2 (Ensure Authorized Software is Currently Supported), confirm all reinstalled pipeline components are currently supported versions from authorized sources. Re-run security scans of your own codebase using verified, clean tooling to confirm no malicious modifications were introduced during the window of compromise. Per AU-11 (Audit Record Retention), retain all pipeline and authentication logs from the incident window to support post-incident review and potential forensic needs. Monitor authentication logs and privileged account activity for 30 days post-remediation using D3-LAM (Local Account Monitoring) to detect persistent access via stolen credentials (T1078). Ensure AU-4 (Audit Storage Capacity) is sufficient to sustain elevated log volume during the extended monitoring period. (Cite: NIST AU-11, NIST AU-4 / CIS 2.2 / D3-LAM)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery (CSF [RC]: Execute recovery plan, restore systems, verify integrity, communicate)
NIST IR-4 (Incident Handling) — executing recovery consistent with the incident response plan, verifying system integrity before returning pipelines to production
NIST SI-6 (Security and Privacy Function Verification) — verifying correct operation of rebuilt CI/CD pipeline components and security scan tooling before production use
NIST AU-6 (Audit Record Review, Analysis, and Reporting) — structured 30-day monitoring of authentication logs and privileged account activity for credential-based persistent access by LAPSUS$
CIS 7.3 (Perform Automated Operating System Patch Management) — ensuring build host operating systems are patched as part of pipeline environment rebuild
CIS 6.2 (Establish an Access Revoking Process) — verifying that all rotated credentials from Step 3 are confirmed revoked across all downstream systems (databases, cloud providers, third-party SaaS) before pipeline restoration
Compensating Control
For a 2-person team: (1) Validate rebuilt pipeline integrity by running KICS scans against a known-static test repository and comparing output hashes — any deviation from expected scan results (false negatives, missing rule sets) indicates the replacement image may still be tampered. (2) Deploy a free osquery scheduled query (`SELECT * FROM process_open_sockets WHERE pid IN (SELECT pid FROM processes WHERE name='node')`) on build hosts to detect Node.js processes (VS Code extensions, Bitwarden CLI) making unexpected outbound connections post-recovery. (3) For the 30-day credential abuse monitoring window, use free SIEM alternatives: ship GitHub audit logs, AWS CloudTrail, and SSH auth logs to a self-hosted Grafana + Loki stack and create alerts on logins with rotated-credential usernames from unexpected source IPs — these patterns are characteristic of LAPSUS$ re-entry attempts using harvested credentials.
Preserve Evidence
During the recovery monitoring window, collect and retain: (1) GitHub audit log entries (`gh api /orgs/{org}/audit-log --paginate`) covering all repository access, secret reads, and workflow dispatches for 30 days post-remediation — LAPSUS$ commonly re-enters via stolen OAuth tokens or PATs rather than rotated passwords, so token-based access from unexpected IPs is the primary re-entry indicator. (2) Authentication logs for all database systems and cloud provider accounts whose credentials were accessible in compromised pipeline environments — filter on source IPs and user agents inconsistent with your normal CI/CD runner pool. (3) Checksums (`sha256sum`) of all rebuilt pipeline configuration files (workflow YAML, Dockerfile, npm lock files) at recovery completion, stored as a signed baseline for future integrity comparison.
5
Step 5: Post-Incident — This attack exploited the absence of cryptographic integrity verification for third-party tooling in CI/CD pipelines (T1195.002, T1195.001). Implement mandatory digest pinning for all Docker image pulls and npm package installs. Per CIS 2.1 (Establish and Maintain a Software Inventory), maintain a current inventory of all pipeline dependencies including Docker images, GitHub Actions, npm packages, and VS Code extensions. Per CIS 7.1 (Establish and Maintain a Vulnerability Management Process) and CIS 7.2 (Establish and Maintain a Remediation Process), formalize a documented process for identifying and remediating compromised or outdated supply chain components. Per AC-20 (Use Of External Systems), establish terms and conditions governing the use of external registries including Docker Hub, Open VSX, and npm before components from those sources are permitted in pipelines. Apply D3-SICA (System Init Config Analysis) to analyze pipeline startup configurations for unauthorized modifications. Apply D3-FMBV (File Magic Byte Verification) as an integrity check on downloaded artifacts before execution. Per AU-13 (Monitoring For Information Disclosure), monitor open-source repositories and dark web sources for organizational identifiers or leaked credentials associated with this incident. (Cite: NIST AC-20, NIST AU-13 / CIS 2.1, CIS 7.1, CIS 7.2 / D3-SICA, D3-FMBV)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity (CSF [GV, ID]: Lessons learned, update policies, improve detection, share intelligence)
NIST SI-7 (Software, Firmware, and Information Integrity) — implementing digest pinning, cosign signature verification, and artifact proxy enforcement to prevent recurrence of the CWE-494 supply chain injection that enabled this LAPSUS$/TeamPCP campaign
NIST SI-2 (Flaw Remediation) — establishing a documented process to rapidly identify and replace compromised third-party tooling (KICS, Bitwarden CLI, Open VSX extensions) when future supply chain advisories are issued
NIST IR-8 (Incident Response Plan) — updating the IR plan to include CI/CD supply chain compromise as a named scenario with specific detection indicators and response procedures based on lessons from this incident
NIST AU-12 (Audit Record Generation) — mandating audit logging of Docker image digest pulls, npm install integrity validation results, and GitHub Actions workflow hash verification in all pipeline environments
CIS 2.1 (Establish and Maintain a Software Inventory) — extending the software inventory to include all CI/CD pipeline components (Docker images by digest, npm packages by integrity hash, VS Code extensions by version and publisher)
CIS 2.2 (Ensure Authorized Software is Currently Supported) — establishing a formal approved-tooling list for CI/CD components that requires integrity verification before authorization, preventing future use of unverified Checkmarx or similar third-party tooling
CIS 7.1 (Establish and Maintain a Vulnerability Management Process) — incorporating supply chain compromise advisories (such as Checkmarx's April 22 update) into the vulnerability management intake process with defined SLAs for CI/CD component replacement
Compensating Control
For a 2-person team without enterprise tooling: (1) Implement digest pinning immediately in all Dockerfiles and GitHub Actions workflow files — replace `uses: checkmarx/kics-github-action@v1` with `uses: checkmarx/kics-github-action@sha256:<digest>` and `FROM checkmarx/kics:latest` with `FROM checkmarx/kics@sha256:<digest>`. (2) Deploy a free Verdaccio npm proxy (self-hosted, open source) as an artifact mirror — configure it to validate npm package integrity hashes against the public registry before serving to CI/CD pipelines, blocking unsigned or hash-mismatched packages like the compromised Bitwarden CLI. (3) Use the free `in-toto` framework to generate and verify software supply chain attestations for your own pipeline outputs, creating a tamper-evident record of what tooling produced each build artifact. (4) Write a Sigma rule targeting GitHub Actions runner logs for patterns consistent with this attack: process spawns from `node` or `docker` processes making outbound connections to non-allowlisted IPs during scan steps — share with the community via the Sigma HQ repository as a threat intelligence contribution.
Preserve Evidence
For the post-incident lessons learned and future detection baseline: (1) Preserve the complete incident timeline — all GitHub Actions run logs, Docker pull records, and npm install logs from March 23–April 22 — as a reference dataset for tuning future supply chain compromise detection rules. (2) Document the specific LAPSUS$/TeamPCP TTPs observed: initial access via compromised Open VSX publisher account or Checkmarx GitHub repository (MITRE ATT&CK T1195.001 — Compromise Software Dependencies and Development Tools), credential harvesting from CI/CD environment variables (T1552.001 — Credentials in Files), and data exfiltration to dark web leak site (T1567 — Exfiltration Over Web Service). (3) Archive the dark web leak site claim details (screenshots, hashes of published data if safely obtainable via threat intel feeds) to support future breach notification assessments and legal proceedings.
Recovery Guidance
Before restoring any CI/CD pipeline to production, validate every rebuilt component against cryptographic digests published in Checkmarx's April 22 security advisory — do not rely on image tags or package version numbers alone, as these were the mutable identifiers exploited in this campaign. Re-run full SAST scans of your own codebase using verified clean KICS and alternative tooling (e.g., Semgrep OSS) to detect any malicious code modifications that compromised pipeline steps may have injected into your own repositories during the exposure window. Maintain elevated monitoring of all service account authentications, GitHub repository access events, and cloud provider API calls for a minimum of 30 days post-remediation, with specific alerting on access patterns using credentials that were rotated during eradication, as LAPSUS$ is known to cache and reuse harvested credentials weeks after initial compromise.
Key Forensic Artifacts
GitHub Actions workflow run logs (March 23–April 22, 2026): downloadable via `gh run list` and `gh run view --log` — primary artifact for identifying injected pipeline steps, outbound exfiltration calls, and secrets variable accesses introduced by compromised Checkmarx GitHub Actions workflows
Docker image layer filesystem (`docker save checkmarx/kics:<tag> | tar -xO | tar -tv`): layer-by-layer inspection of pulled KICS images to identify injected binaries, modified entrypoints, or added cron jobs that would constitute the malware delivery mechanism in this supply chain attack
npm package tarball integrity records (`~/.npm/_cacache/` and `package-lock.json` integrity SHA-512 fields): the forensic record of exactly which Bitwarden CLI package version and hash was installed on each developer workstation, enabling comparison against known-compromised version hashes from the advisory
VS Code extension host logs (`~/.config/Code/logs/exthost*.log` on Linux, `%APPDATA%\Code\logs\exthost*.log` on Windows): runtime behavior logs for Open VSX-sourced Checkmarx extensions that would capture credential reads, unexpected file system access, or outbound API calls made by malicious extension code
Secrets manager and environment variable access audit logs (AWS Secrets Manager CloudTrail events for `GetSecretValue`, HashiCorp Vault audit log `secret/data/*` read events, or GitHub Actions `secrets.*` access records): the definitive evidence of which credentials and API keys were read by compromised pipeline steps, defining the full blast radius of the LAPSUS$/TeamPCP credential harvesting operation
Detection Guidance
Detection for this LAPSUS$ supply chain campaign focuses on three control-grounded areas.
1.
CI/CD Pipeline Telemetry (AU-2, AU-3, AU-6, CIS 8.2): Per AU-2 (Event Logging), confirm logging is enabled for all pipeline runner nodes, container execution environments, and GitHub Actions workflow runs.
Per AU-3 (Content Of Audit Records), ensure logs capture event type, timestamp, source identity, and originating process for every pipeline action.
Query pipeline logs for the March 23–April 22, 2026 window for: outbound network connections from KICS container processes or GitHub Actions runners to non-approved endpoints (T1567.001 ); unexpected process spawning within container or runner contexts (T1059 ); and unauthorized repository access or data exfiltration events (T1213 ). Apply AU-6 (Audit Record Review, Analysis, And Reporting) to drive structured, documented analysis of collected telemetry. Use D3-SFA (System File Analysis) to inspect GitHub Actions workflow YAML files and pipeline configuration files for unauthorized modifications introduced during the exposure window.
2. Credential Exposure and Account Activity (AU-6, AC-2, CIS 5.1, D3-LAM, D3-CRO): Apply D3-LAM (Local Account Monitoring) to analyze local and service accounts on pipeline runner nodes for unauthorized activity following the exposure window. Per AC-2 (Account Management), review account access logs for API keys, database credentials, and service accounts that were accessible to affected pipeline steps; flag any authentication events from unexpected IP addresses or geolocations after March 23, 2026 (T1078 ). Check secrets management systems and CI/CD environment variable stores for credentials that intersected with compromised workflow steps (T1552.001 , T1552.004 ). Verify D3-CRO (Credential Rotation) has been applied to all identified exposed credentials before closing this detection lane.
3. Package and Extension Integrity (CIS 2.1, CIS 2.3, D3-FMBV, D3-SICA): Per CIS 2.1 (Establish and Maintain a Software Inventory), query your software inventory for the specific Bitwarden CLI npm package version installed across all developer workstations and pipeline environments; compare installed package hashes against known-good hashes published by Bitwarden. Apply D3-FMBV (File Magic Byte Verification) to validate the integrity of downloaded Docker images and npm packages before execution. For VS Code environments, review extension installation logs in Open VSX-sourced extension directories for unexpected modifications or additions during the exposure window (T1195.002 ). Apply D3-SICA (System Init Config Analysis) to inspect container and runner startup configurations for attacker-inserted initialization scripts. Per AU-13 (Monitoring For Information Disclosure), monitor open-source information channels and dark web sources for organizational identifiers, leaked source code, or credentials claimed in LAPSUS$ postings.
Note: The KB does not include SI-family controls (e.g., SI-3, SI-7) in the provided reference data. Those controls are directly relevant to malware scanning and software integrity verification for this threat. If SI-family controls are available in your full NIST implementation, prioritize SI-7 (Software, Firmware, and Information Integrity) for digest pinning and integrity monitoring of pipeline artifacts.
Indicators of Compromise (2)
Export as
Splunk SPL
KQL
Elastic
Copy All (2)
2 urls
Type Value Enrichment Context Conf.
🔗 URL
https://thehackernews.com/2026/04/checkmarx-confirms-github-repository.html
VT
US
The Hacker News reporting on Checkmarx GitHub repository compromise and LAPSUS$ claim — source URL, not a malicious indicator
LOW
🔗 URL
https://checkmarx.com/blog/checkmarx-security-update-april-22/
VT
US
Official Checkmarx security update — consult for authoritative IOCs and affected version details as investigation matures
LOW
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.
IOC Detection Queries (1)
2 URL indicator(s).
KQL Query Preview
Read-only — detection query only
// Threat: LAPSUS$ Claims Checkmarx Data After Supply Chain Attack Cascades Through Develop
let malicious_urls = dynamic(["https://thehackernews.com/2026/04/checkmarx-confirms-github-repository.html", "https://checkmarx.com/blog/checkmarx-security-update-april-22/"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (malicious_urls)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
MITRE ATT&CK Hunting Queries (2)
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: 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
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
T1528
T1195.002
T1078
T1195.001
T1567.001
T1213
+3
CM-7
SA-9
SR-3
SI-7
AC-2
AC-6
+6
MITRE ATT&CK Mapping
T1528
Steal Application Access Token
credential-access
T1195.002
Compromise Software Supply Chain
initial-access
T1078
Valid Accounts
defense-evasion
T1195.001
Compromise Software Dependencies and Development Tools
initial-access
T1567.001
Exfiltration to Code Repository
exfiltration
T1213
Data from Information Repositories
collection
T1552.001
Credentials In Files
credential-access
T1059
Command and Scripting Interpreter
execution
Guidance Disclaimer
