Discover the details of the TeamPCP hackers arrested in Australia for executing devastating open-source supply chain attacks using the Mini Shai-Hulud worm.
The SANDCLOCK LiteLLM supply-chain attack exposed credentials across 2,038 repositories, affecting technology, finance, healthcare, retail and more.
Resecurity (USA)estimated the most affected sectors by the “SANDCLOCK” backdoor, which was planted as a result of the code repository compromise. According to cybersecurity experts, LiteLLM / TeamPCP Supply-Chain Attack will have long-lasting consequences.
By compromising a well-known component in AI applications, adversaries will multiply the blast radius—some of the victim organizations are still unaware of the backdoor and its impact. LiteLLM is a popular open-soure AI gateway and utility library that unifies API calls for over 100 large language model providers, such as OpenAI, Anthropic, Google Gemini, and local Ollama models.
Such incidents involve substantial MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond). The threat actor group “TeamPCP” compromised maintainer credentials for LiteLLM and published malicious package versions 1.82.7 and 1.82.8 to PyPI around March 2026 – creating a window of exposure lasting at least a few months.
Over 2,500+ organizations and hundreds of thousands of CI/CD environments suffered full-credential exposure, compromising cloud infrastructure keys, repository access tokens, SSH credentials, Kubernetes secrets, and AI provider API keys (such as OpenAI and Anthropic).
Resecurity has acquired the 150GB archive attributed to the LiteLLM supply-chain attack conducted by TeamPCP using the “SANDCLOCK” credential-stealer. Per published incident reporting — accompanying victim manifests enumerate 898 compromised GitHub owners (organisations/accounts) across 2,038 repositories. The affected owners include major global enterprises — among them Microsoft, Azure, IBM, NVIDIA, PayPal (Zettle), Deloitte, Bosch, S&P Global, Elevance Health, 84.51° (Kroger), Adeo (Leroy Merlin), Kärcher, Dräger, ID.me and 1inch.
Top 10 the most impacted sectors (by victim organization profile):
Technology / Software
Banking / Finance / Insurance
Healthcare / Pharma / Medtech
Retail / E-Commerce
Media / Gaming / Adtech
Manufacturing / Industrial
Professional Services
Cybersecurity
Crypto
Government
Resecurity enumerated 2,146 records by key name (values never inspected beyond structural masking). The composition is overwhelmingly GitHub CI-CD identity material, with a long tail of high-value cloud and registry credentials.
Victim manifests (owners.txt, repos.txt) enumerate 898 distinct compromised GitHub owners across 2,038 repositories. The distribution is long-tailed: 631 owners have a single affected repo, while the most-affected owner (Cencosud-Cencommerce) has 64. Critically, the owner list includes major global enterprises and regulated organisations.
Every organization affected by the LiteLLM incident should revoke or rotate GitHub App private keys, PATs, AWS/GCP/Firebase credentials, ECR/JFrog tokens, SSH keys, and signing passwords, and invalidate sessions.
XCSSET v40 malware infects macOS developers through poisoned Xcode projects on GitHub, then hides in memory. Unit 42 found 17 modules and Chrome hijacking.
Microsoft Threat Intelligence identified a large-scale npm supply chain attack affecting more than 400 packages across multiple unrelated publishers, including packages associated with major enterprise software ecosystems such as keyv, flat-cache, cache-manager, and others. The malicious releases contain a Mini Shai-Hulud variant, a self-propagating credential-stealing worm delivered through a large, heavily obfuscated Bun-based JavaScript payload. The malware typically executes automatically through an npm preinstall lifecycle hook before package installation completes.
Once executed, the malware searches developer workstations and continuous integration and continuous delivery (CI/CD) environments for npm, GitHub, cloud, and infrastructure credentials. It uses recovered identities to authenticate to npm, GitHub, Amazon Web Services (AWS), Kubernetes, and HashiCorp Vault, enabling it to enumerate packages, repositories, workflow secrets, cloud parameters, and secret-store values. Collected data is encrypted and transmitted through an attacker-controlled HTTPS endpoint, with GitHub repositories serving as a fallback exfiltration channel.
The payload’s most significant capability is automated propagation. After obtaining an npm publishing token, it enumerates packages available to the compromised identity, downloads their latest tarballs, inserts the malware and setup loader, adds a preinstall hook, increments the patch version, and republishes the modified packages. The malware can also use stolen GitHub credentials to inject Claude and Visual Studio Code configuration files into repositories, establishing persistence and creating an additional developer-to-developer infection path.
In this blog, we’re sharing our analysis of this supply chain attack, along with protection, detection, amd hunting guidance. Organizations that installed an affected package with lifecycle scripts enabled should treat the associated developer workstation or build runner as potentially compromised. Investigations should prioritize credentials accessible to the affected identity, unauthorized npm releases, unexpected repository or workflow modifications, suspicious cloud and secret-store access, and artifacts produced by affected build systems. Organizations should revoke and rotate exposed credentials from a known-clean environment and rebuild affected systems and downstream artifacts from trusted sources.
Attack chain overview
The campaign appeared as a rapid sequence of unauthorized patch releases across more than 400 npm packages maintained by otherwise unrelated publishers. Many malicious versions had no corresponding source-code commit, pull request, tag, or legitimate release, indicating that the attackers modified and published package tarballs directly rather than compromising each public source repository.
Affected releases typically added a preinstall lifecycle script that launched a malicious file, setup.mjs, contained within the package, which launched the large, obfuscated Bun JavaScript bundle included in the package. Because npm runs preinstall scripts before installation completes, the payload could execute on developer workstations and build runners before application tests or conventional security checks began.
After execution, the malware performs the following actions:
Determines whether it is running on a developer workstation or in a CI/CD environment. On workstations, it detaches itself to continue after installation; on CI/CD systems, it remains in the active job to access workflow secrets, runner credentials, and OpenID Connect (OIDC) publishing permissions. Both paths could support further package or repository propagation when suitable credentials are found.
Collects credentials from local files, environment variables, command-line tools, and GitHub Actions runner memory.
Authenticates to npm, GitHub, AWS, Kubernetes, and HashiCorp Vault to enumerate additional accessible resources and secrets.
Encrypts and exfiltrates collected data through an HTTPS channel, using GitHub repositories as a fallback.
Uses recovered npm publishing access to modify and republish additional packages.
Uses GitHub credentials to inject files into Claude and Visual Studio Code configurations across repository branches for persistence.
The payload’s package-propagation routine downloads each publisher’s latest release, inserts itself, increments the patch version, and publishes the resulting archive. This mechanism can rapidly transform one compromised npm identity into many malicious package releases.
Figure 1. Attack chain.
0. Initial publisher access
Evidence points towards stolen maintainer credentials as the attack vector for initial compromise. Later propagation used stolen npm publishing tokens and, in targeted workflows, GitHub Actions OIDC publishing access.
1. Payload startup and background execution
The malicious npm package uses a lifecycle hook to launch its bundle.
During preflight, the payload checks the environment, exits on Russian-language systems, avoids duplicate instances, and starts a detached copy in the background on developer systems.
Figure 2. Platform identification and execution.
In CI environments, the payload remains attached so it can access credentials available to the active build job.
2. Initial credential discovery
The payload first collects information that is immediately available from the local system, shell, and GitHub Actions runner.
Figure 3. Credential discovery.
The shell collector attempts to obtain the GitHub CLI token and captures the values of all process environment variables. The filesystem collector searches credential files, shell histories, cloud configuration, Secure Shell (SSH) keys, and other sensitive locations.
3. Cloud and secret store enumeration
The recovered code then creates dedicated collectors for cloud and infrastructure services.
Figure 4. Credential enumeration.
These modules do not merely scan files for token patterns; they use available credentials to call service APIs, verify access, and retrieve additional secrets permitted to those identities.
The following snippet shows the authentication attempt made using the found credentials:
Figure 5. Credential validation.
4. GitHub credential theft and enumeration
Discovered GitHub tokens are validated before being used for additional collection or repository access.
Figure 6. GitHub credential collector.
The payload checks token scopes, enumerates writable repositories, and identifies repositories where workflow execution could expose additional secrets.
6. GitHub Actions OIDC abuse
The payload also contains a targeted publishing path for GitHub Actions workflows configured as npm trusted publishers.
Figure 7. Re-publishing package using GitHub OIDC token.
Packages published through this route can carry valid provenance because the publication originates from a legitimate workflow identity.
7. Exfiltration and fallback
Collected results are serialized as JSON, gzip-compressed, and encrypted with a randomly generated AES-256-GCM using a randomly generated 32-byte key and 12-byte initialization vector (IV). The AES key is then encrypted with the attacker’s RSA public key using RSA-OAEP-SHA256.
The payload first attempts delivery through an attacker-controlled dynamic HTTPS endpoint. The active domain can change through on-chain contract (0xE1f2395ee43e45A1556EC6438a88c31B83493103, selector 0x53ed5143) or, as a fallback, from a cryptographically verified signed GitHub commit (Signed fallback marker: thebeautifulmarchoftime). If that channel is unavailable, it creates a public GitHub repository with the description Shai-Hulud: Here We Go Again.
Encrypted results are committed as files such as: results-<timestamp>-<counter>.json.
At the time of analysis, the live contract returns npm-cache[.]com. Earlier candidates include pypi-get[.]com and js-mirror[.]com.
Figure 8. Exfiltrating stolen information.
In one fallback path, a stolen GitHub token is added separately using double Base64 encoding. This token field is encoded, not encrypted.
8. Repository persistence and secondary spread
The payload can use stolen GitHub credentials to inject the malware and supporting setup files into eligible repository branches. The recovered code targets Claude and Visual Studio Code configuration paths, including .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, and .vscode/setup.mjs.
These changes create a secondary infection route: future Claude or Visual Studio Code activity can restart the payload even after the original npm installation has completed. In a conditional GitHub fallback path, the payload also attempts to install a token-monitor component that maintains credential access and contains a destructive handler if the monitored token is revoked.
Figure 9. Injecting the malicious code into development ecosystems.
9. Worm behavior: Package modification and publication
The npm tokens found in collected data are checked for package-write permission and two-factor authentication (2FA)-bypass capability.
Figure 10. Republishing the package using stolen NPM token.Figure 11. Malicious update to existing package and republishing.
The propagation routine downloads a package’s latest tarball, copies the current malware bundle into it, adds a loader, and replaces its lifecycle scripts. This creates the worm-like propagation pattern: one stolen token can produce malicious patch releases across every package available to that publisher. This also explains why malicious releases frequently appeared as an otherwise ordinary patch-version increment without corresponding source commits or pull requests.
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of this threat.
Review dependency trees, lockfiles, artifact repositories, and CI caches for the five compromised versions, including transitive references.
Pin known-good package versions.
Purge npm and yarn caches on affected developer endpoints and build hosts, especially if the compromised tarballs were written into shared CI caches.
Rotate credentials and secrets from a clean host if a build system or workstation imported a compromised version, because second-stage execution can expose tokens and compromise build integrity.
Ensure that Microsoft Defender Antivirus cloud-delivered protection, Microsoft Defender for Endpoint telemetry, Microsoft Defender for Containers, and Microsoft Defender XDR investigation workflows are enabled across developer and CI assets.
Organizations that produce software artifacts should also review their own release hardening because this incident appears consistent with CI/CD pipeline abuse through GitHub Actions OIDC publishing. Defenders should review token scopes, workflow approvals, protected environments, release provenance, and anomaly detection around automated package publication. Supply chain response cannot stop at host triage; it must also include verification that the release process itself has not been subverted.
After remediation, validate recovery deliberately. Rebuild affected projects from a known-good dependency baseline, confirm that compromised hashes are absent from package caches and artifact stores, and review endpoint telemetry for any lingering NodeJS directory artifacts such as Math_Symbol.js, Math_init.js, or names similar to math_<guid>.js, or suspicious node child processes. For development organizations that share base images or golden build runners, rebuild those images as well so future jobs do not silently inherit poisoned caches or post-compromise persistence.
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Initial access / Execution
Malicious files embedded in compromised npm packages execute the embedded payload automatically through a malicious preinstall lifecycle hook.
Microsoft Defender Antivirus – Trojan:NPM/ShaiLoader.BY – Trojan:NPM/MalBun.A – Trojan:NPM/ShaiWorm.DAY!MTB
Microsoft Defender for Endpoint – Suspicious Node.js process behavior – Suspicious Node.js script execution
Execution / Defense evasion
The preinstall loader launches a heavily obfuscated Bun-based JavaScript payload designed to hinder analysis and evade Node.js-focused monitoring.
Microsoft Defender Antivirus – Behavior:Linux/SuspBunActivity.A – Behavior:Win32/SuspBunActivity.A
Microsoft Defender for Endpoint – Suspicious usage of Bun runtime – Suspicious installation of Bun runtime – Suspicious Node.js process behavior – Suspicious script execution via Bun – Suspicious Node.js script execution
Microsoft Defender for Cloud – Suspicious npm supply-chain compromise activity detected
Credential access / Collection
The malware searches developer workstations and CI/CD environments for npm, GitHub, cloud, Kubernetes, and secrets.
Microsoft Defender for Endpoint – Credential access attempt – Suspicious cloud credential access – Enumeration of files with sensitive data – Suspicious access of sensitive files
Microsoft Defender for Cloud – Sha1-Hulud Campaign Detected: Possible command injection to exfiltrate credentials
Advanced hunting queries
Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:
Execution of the preinstall script
DeviceProcessEvents
| where Timestamp > ago(3d)
| where FileName in~ ("node", "node.exe")
| where ProcessCommandLine in~ ("node setup.mjs", "node setup.mjs")
CloudProcessEvents
| where Timestamp > ago(3d)
| where FileName in~ ("node", "node.exe")
| where ProcessCommandLine in~ ("node setup.mjs", "node setup.mjs")
Execution of second-stage JavaScript using Bun runtime
DeviceProcessEvents
| where Timestamp > ago(3d)
| where InitiatingProcessFileName in~ ("node", "node.exe")
| where InitiatingProcessCommandLine in~ ("node setup.mjs", "node setup.mjs")
| where FileName in~ ("bun", "bun.exe")
| where FolderPath contains "bun-dl-" or ProcessCommandLine has "node_modules"
Malicious JavaScript from malicious packages
DeviceFileEvents
| where Timestamp > ago(3d)
| where SHA256 in~ ("9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc", "fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1eb", "54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668")
Credential access by malicious JavaScript
DeviceProcessEvents
| where Timestamp > ago(3d)
| where ProcessCommandLine has_any ('gh auth token', 'gcloud config config-helper', 'az account get-access-token', "azd auth token")
| where InitiatingProcessFileName in~ ("bun", "bun.exe")
| where InitiatingProcessFolderPath contains "bun-dl-" or InitiatingProcessCommandLine has "node_modules"
Microsoft Security Copilot
Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate investigation and response tasks related to this threat. Useful promptbooks for this activity include Incident investigation, Microsoft User analysis, Threat actor profile, Threat Intelligence 360 report based on MDTI intelligence, and Vulnerability impact assessment. Some promptbooks require access to Microsoft Defender XDR, Microsoft Sentinel, or related Microsoft security plugins.
For this campaign, Security Copilot can help analysts summarize affected devices, pivot from the package hashes to endpoint evidence, identify hosts that communicated with the IPFS path or C2 infrastructure, and build remediation actions such as cache purge, credential rotation, and containment sequencing for impacted developer systems and build runners.
Threat intelligence reports
Microsoft customers can use Microsoft Defender XDR Threat analytics and related Microsoft threat intelligence reporting to stay current on the malicious activity, indicators, detection coverage, and recommended response actions associated with this compromise. These reports provide investigation context, protection guidance, and updated intelligence that security teams can use to prevent, mitigate, or respond to related activity in customer environments.
As with other active supply-chain investigations, defenders should monitor for updated intelligence on package status, additional affected versions, infrastructure changes, and newly surfaced post-compromise tradecraft. Microsoft will continue to incorporate validated indicators and detections into Microsoft security products as the investigation evolves.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
On July 14, 2026, Microsoft Threat Intelligence identified a coordinated supply chain compromise of the @asyncapi npm organization, a widely used set of packages for the AsyncAPI specification and code generation. Five package versions across four package names were republished within roughly ninety minutes, each carrying the same maliciously injected loader: @asyncapi/specs (in both the 6.11.2-alpha.1 prerelease and 6.11.2 stable release), @asyncapi/generator@3.3.1, @asyncapi/generator-components@0.7.1, and @asyncapi/generator-helpers@1.1.1.
Because @asyncapi/specs is a transitive dependency of numerous AsyncAPI tooling packages, this attack affected developer workstations, CI/CD pipelines, container builds, or production services that resolved and imported the affected versions during the exposure window. Unlike the more common postinstall-hook supply-chain pattern, this campaign executes at module-load (import/require) time. When any consuming build or application imports a poisoned package, the injected block runs immediately. Because the trigger is an import rather than an install script, the common npm install –ignore-scripts mitigation does not neutralize it. The second stage decrypts and evaluates a Miasma modular runtime with active command and control (C2), persistence, and decentralized fallback channels. Although disabled in this instance, credential-harvesting, propagation, and additional high-risk modules could be enabled through persistence.
Microsoft Defender Antivirus detects and blocks malicious artifacts as Trojan:JS/MiasmStealer.SC and Trojan:Script/Supychain.A. Microsoft Defender for Endpoint provides behavioral coverage for the suspicious detached Node.js process spawn, IPFS retrieval, and persistence activity. Organizations should immediately remove all five affected versions, purge npm and Yarn caches, hunt for sync.js under the NodeJS masquerade directories, block outbound connections to 85.137.53[.]71 on ports 8080, 8081, and 8091, and rotate all credentials accessible from any environment that imported the compromised packages. Detailed hunting queries, indicators of compromise, and mitigation guidance are provided in the succeeding sections.
Attack chain overview
Figure 1. End-to-end attack chain from CI/CD pipeline compromise through import-time execution to IPFS second-stage fetch, with C2 infrastructure and affected packages.
The compromise originated from a pwn request against asyncapi/generator. A misconfigured GitHub Actions workflow (pull_request_target) executed attacker-controlled pull-request (PR) code, exposed the asyncapi-bot personal access token (PAT), and enabled unauthorized pushes to auto-publish branches. The legitimate GitHub Actions OpenID Connect (OIDC) release workflows then published the poisoned packages under the automated identity npm-oidc-no-reply@github[.]com, producing artifacts with valid provenance signatures built from unauthorized source commits.
The campaign progressed through six phases, shown in Figure 1:
Pipeline compromise. The attacker exploited a vulnerable GitHub Actions workflow to steal a privileged bot token.
Code injection. Heavily obfuscated loaders were inserted into one source file per package.
Staged release. An alpha prerelease was followed by a stable release 24 minutes later, with a byte-identical payload, expanding blast radius.
Delivery. Consumers pulled poisoned versions through normal npm and Yarn dependency resolution; –ignore-scripts was not effective.
Import-time execution. require() or import triggered the malicious main(), which spawned a hidden detached child process.
IPFS second-stage fetch. The child downloaded sync.js from IPFS and wrote it to an OS-specific “NodeJS” masquerade directory.
The Miasma runtime provided encrypted bootstrap, persistence, C2 communication, data return paths, and resilient discovery via Nostr, Ethereum, BitTorrent DHT, libp2p, and IPFS. Six additional capability modules (credential harvest, encrypted exfiltration, supply-chain propagation, metamorphic generation, AI-tool poisoning, and sandbox evasion) were implemented but disabled in this build.
Time (UTC)
Observed event
~07:10
@asyncapi/generator@3.3.1, @asyncapi/generator-components@0.7.1, and @asyncapi/generator-helpers@1.1.1 republished with the injected loader.
08:06:20
@asyncapi/specs@6.11.2-alpha.1 published with the malicious importer prepended to index.js.
08:30:09
@asyncapi/specs@6.11.2 stable published with a byte-identical payload, widening downstream reach.
08:49:22
First observed downstream fetch of the stable 6.11.2 tarball into a Yarn cache during dependency installation.
How the attack started: GitHub Actions pwn request
The attack chain began with a malicious pull request targeting the asyncapi/generator repository’s docs-preview automation. Opened as PR #2155, it carried the attacker-controlled commit 47be388, timestamped 05:08:58 UTC on July 14. The associated Docs Preview (Netlify) workflow started at 05:11:05 UTC.. Although the PR and source fork were later removed, the workflow record remains available.
The pull request PR #2155 targeted manual-netlify-preview.yml, which combined two unsafe choices: it used pull_request_target, placing the job in the base repository’s security context, and it checked out the pull request’s untrusted head commit. The run had a broadly privileged GITHUB_TOKEN, checkout credentials persisted in the local Git configuration until post-job cleanup (the default behavior of actions/checkout), and steps that referenced repository secrets.
The submitted MDX contained code was designed to retrieve JavaScript from rentry[.]co/elzotebo999 and evaluate the response. The public log confirms that the malicious commit was processed by the privileged workflow, but it does not show whether the rentry[.]co web request succeeded or whether a credential was stolen. Later push records identify asyncapi-bot as the authenticated actor. Together, these records establish that the vulnerable workflow ran before the bot-authenticated pushes, but they do not establish how the credential was obtained.
The underlying workflow weakness had been identified before the compromise. On April 29, a proof-of-concept examined whether untrusted pull-request content could be executed in the privileged docs-preview workflow. A May 17 proposal then sought to separate untrusted build activity from steps that received repository secrets and was still under review when the incident occurred.
Trusted publishing became the delivery mechanism
Once the attacker could push commits as asyncapi-bot, there was no need to compromise npm or construct a separate publishing channel. The attacker could ride the project’s normal release path and let its trusted pipeline do the distribution. Commit 3eab3ec carries a timestamp of 06:58:42 UTC, while a surviving push-triggered workflow started at 07:05:42 UTC. Its message, “fix: test release workflow on next”, matched the release workflow’s commit-message condition. The legitimate release-with-changesets.yml workflow then published three poisoned packages at approximately 07:10 UTC.
A closely linked compromise subsequently affected asyncapi/spec-json-schemas. The malicious lineage first triggered workflows on alpha between 07:56 and 08:04 UTC. The same malicious commit was later pushed to master at approximately 08:14 UTC, followed by a child commit at 08:28 UTC. The legitimate if-nodejs-release.yml workflow published @asyncapi/specs@6.11.2-alpha.1 at 08:06 UTC and @asyncapi/specs@6.11.2 at 08:30 UTC.
All five malicious versions were published through npm trusted publishing using GitHub OIDC and carried valid provenance attestations. The attestations accurately identified the legitimate repositories, commits, and workflows that created the packages, even though the triggering commits were unauthorized.
Figure 2. Miasma runtime capabilities recovered from sync.js, including active modules and implemented-but-disabled modules.
The payload operates in multiple stages, each designed to increase evasion and ensure resilient execution. Stage 0 establishes stealth by declaring no npm lifecycle hooks. Stage 1 executes the loader at require-time and spawns a hidden child process. Stage 1b deobfuscates the IPFS fetch logic and downloads sync.js. Stage 2 decrypts the ~8.2 MB encrypted bundle through three cryptographic layers. Stage 3 initializes the full Miasma modular runtime with C2, persistence, and decentralized fallback channels.
Stage 0: No lifecycle hooks declared
The absence of lifecycle hooks is a deliberate evasion choice. Security tooling that focuses on preinstall/postinstall auditing will not flag these packages. All affected packages declared no preinstall, install, or postinstall hooks in package.json. This bypassed hook-focused scanners and left import-time execution as the real trigger path.
Stage 1: Import-time loader
The loader executes the moment any application imports the compromised module; no user action beyond dependency resolution is required. The attacker placed the same bootstrap pattern in each package’s exported entry path, so normal application startup would trigger execution automatically.
The inner payload reveals hard-coded IPFS content identifiers and OS-aware drop logic. This intermediate stage reconstructs the transport routine at runtime, so the larger second stage never appears in cleartext in the published package.
Package set
IPFS CID
specs
Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf
generator-family
QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9
const FILE_URL = 'hxxps://ipfs[.]io/ipfs/';
const FILE_NAME = 'sync.js';
function getTargetDirectory() {
if (process.platform === 'win32') return '%LOCALAPPDATA%\NodeJS';
if (process.platform === 'darwin') return '~/Library/Application Support/NodeJS';
if (process.platform === 'linux') return '~/.local/share/NodeJS';
return '~/.config/NodeJS';
}
Stage 2: Encrypted payload (sync.js)
Despite appearing cryptographically sophisticated, the entire decryption chain uses static embedded key material, meaning the runtime can be recovered offline without execution. The layered design primarily increases analyst effort; every secret required to unwrap the bundle ships inside the loader.
sync.js is ~8.2 MB; all key material is static and embedded.
HKDF-SHA256 uses master string rt-vault-master-key-32b-aaaaaaaa and info string rt-file-key.
AES-256-GCM uses IV = first 12 bytes and auth tag = last 16 bytes of the blob.
The decrypted string is ROT-94de-rotated and then executed with eval().
Stage 3: Miasma runtime
The runtime is a command framework identified as M-RED-TEAM v6.4 with campaign configuration miasma-train-p1. In this build’s configuration, persistence and C2 are active, but data collection and propagation modules remain dormant. The runtime supports traditional remote access trojan (RAT) commands, including directory listing, file retrieval, file upload, remote shell execution, proxying, and data exfiltration. Persistence is installed through platform-specific mechanisms: a Windows HKCU Run key (miasma-monitor), a Linux systemd user unit (miasma-monitor.service), and macOS shell RC injection (.zshrc, .bashrc, or .bash_profile).
Recovered identifiers: M-RED-TEAM v6.4, miasma-train-p1, and miasma-test-org.
Persistence: Win HKCU Run value miasma-monitor, Linux miasma-monitor.service, and macOS user-space shell/launch persistence.
Fallback channels include Nostr, Ethereum, BitTorrent DHT, libp2p, and IPFS.
Disabled in the analyzed build: recon, propagation, AI-poisoning, metamorphic generation, and evasion.
Credential harvesting (disabled in this build)
The framework contains broad credential-access code targeting secrets across major platforms that a developer or continuous integration and continuous delivery (CI/CD) system might access, including browser-saved passwords from multiple browsers.
The framework targets over 100 environment variable names across source control (GITHUB_TOKEN, GITLAB_TOKEN), npm (NPM_TOKEN, NODE_AUTH_TOKEN), AWS (AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY), Azure (AZURE_CLIENT_SECRET), GCP (GCLOUD_SERVICE_KEY), container/Kubernetes (DOCKER_TOKEN, K8S_AUTH_TOKEN), secrets managers (DOPPLER_TOKEN, VAULT_TOKEN), and AI platforms (ANTHROPIC_API_KEY, OPENAI_API_KEY).
Credential files targeted from disk include .npmrc (npm tokens), .aws/credentials (AWS keys), kubeconfig (Kubernetes API), id_rsa/id_ed25519 (SSH keys), .vault-token (HashiCorp Vault), .netrc (Git/HTTPS auth), .docker/config.json (Docker registry), and google_credentials.json (GCP service accounts). When a GITHUB_TOKEN is available, the framework can enumerate accessible repositories and CI/CD context through GitHub APIs.
Mitigation and protection guidance
Review dependency trees, lockfiles, artifact repositories, and CI caches for the five compromised versions, including transitive references.
Pin known-good versions: @asyncapi/specs 6.11.1 or earlier, @asyncapi/generator 3.3.0, @asyncapi/generator-components 0.7.0, and @asyncapi/generator-helpers 1.1.0.
Do not rely on npm install –ignore-scripts as a mitigation; this campaign executes when the module is imported, not through a lifecycle hook.
Purge npm and yarn caches on affected developer endpoints and build hosts, especially if the compromised tarballs were written into shared CI caches.
Hunt for sync.js and the NodeJS masquerade directory on endpoints, and investigate any detached Node.js execution that references the IPFS CID or the sync.js file name.
Block or alert on retrieval of the specific IPFS CID and monitor for network connections to 85.137.53[.]71 on ports 8080, 8081, and 8091.
Rotate credentials and secrets from a clean host if a build system or workstation imported a compromised version, because second-stage execution can expose tokens and build integrity.
Ensure that Microsoft Defender Antivirus cloud-delivered protection, Microsoft Defender for Endpoint telemetry, and Microsoft Defender XDR investigation workflows are enabled across developer and CI assets.
Organizations that do not rely on IPFS for business operations can reduce their attack surface by blocking public IPFS gateways (ipfs.io, dweb.link, cloudflare-ipfs.com, and others) at the network perimeter. This proactive measure removes an increasingly common payload delivery channel used in supply chain campaigns without affecting standard development workflows.
Organizations that produce software artifacts should also review their own release hardening. Because this incident appears consistent with CI/CD pipeline abuse through GitHub Actions OIDC publishing, defenders should review token scopes, workflow approvals, protected environments, release provenance, and anomaly detection around automated package publication. Supply chain response cannot stop at host triage; it must also include verification that the release process itself has not been subverted.
After remediation, validate recovery deliberately. Rebuild affected projects from a known-good dependency baseline, confirm that compromised hashes are absent from package caches and artifact stores, and review endpoint telemetry for any lingering sync.js, NodeJS directory artifacts, or suspicious node child processes. For development organizations that share base images or golden build runners, rebuild those images as well so future jobs do not silently inherit poisoned caches or post-compromise persistence.
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Initial access / Execution
Compromised packages published though GitHub Actions OIDC trusted publishing
Microsoft Defender Antivirus – Trojan:Script/Supychain.A – Trojan:JS/MiasmStealer.SC – Trojan:JS/SpawnLoader.MKV!MTB
Microsoft Defender for Endpoint – Suspicious Node.js process behavior – Suspicious Node.js script execution
Execution / Defense evasion
Module import triggers obfuscated main(), which spawns a hidden detached node
Microsoft Defender Antivirus – Trojan:JS/VaultLoader.MJZ!MTB
Microsoft Defender for Endpoint – Suspicious Node.js process behavior – Suspicious Node.js script execution
Persistence
OS-specific persistence installed
Microsoft Defender for Endpoint – Anomaly detected in ASEP registry – Suspicious modification of shell profile – Suspicious Linux service created
Advanced hunting queries
Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:
Persistence drop and detached spawn
// Query 1: sync.js dropped under a NodeJS directory or related detached execution
union isfuzzy=true
(
DeviceProcessEvents
| where Timestamp > ago(30d)
| where (ProcessCommandLine has "sync.js" and ProcessCommandLine contains_cs "NodeJS")
or ProcessCommandLine has "Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf"
| project Timestamp, DeviceName, Evidence = ProcessCommandLine, Initiator = InitiatingProcessCommandLine, EventType = "Process"
),
(
DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName == "sync.js" and FolderPath contains_cs "NodeJS"
| project Timestamp, DeviceName, Evidence = strcat(FolderPath, "\\", FileName), Initiator = InitiatingProcessFileName, EventType = "File"
)
IPFS CID retrieval
// Query 2: outbound retrieval of the IPFS second stage
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has "ipfs.io"
| where RemoteUrl has "Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf"
| project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName
Poisoned package artifacts in caches
// Query 3: presence of a poisoned tarball in caches
DeviceFileEvents
| where Timestamp > ago(30d)
| where SHA256 in (
"d425e4583cc6185d41e95c45eda00550045a5d1919b9a012236a4520d009dbd7",
"9b2e65db653ca8575c9b10eefb9a80c6006404812c2ec212bf5675e3c690233b",
"bfaeb987faa6de2b5a5eb63b1233d055215b09b0349a9394f2175fd7cdf385e4",
"082d733db0687dcd768104972b065d4b58cb1e6043688c6c20fa3702337f36ab",
"34014776d3d3ff11bc4439b02fd7ac0f02a887eb3a052eeafff236e2f6db8ad1")
| project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName
Suspicious Node.js execution
DeviceProcessEvents
| where Timestamp > ago(3d)
| where FileName in~ ("node", "node.exe")
| where ProcessCommandLine has "node.exe -e \"const _0x5af5e1" or ProcessCommandLine has "node -e \"const _0x5af5e1"
| project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessFolderPath
Microsoft Security Copilot
Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate investigation and response tasks related to this threat. Useful promptbooks for this activity include Incident investigation, Microsoft User analysis, Threat actor profile, Threat Intelligence 360 report based on MDTI intelligence, and Vulnerability impact assessment. Some promptbooks require access to Microsoft Defender XDR, Microsoft Sentinel, or related Microsoft security plugins.
For this campaign, Security Copilot can help analysts summarize affected devices, pivot from the package hashes to endpoint evidence, identify hosts that communicated with the IPFS path or C2 infrastructure, and build remediation actions such as cache purge, credential rotation, and containment sequencing for impacted developer systems and build runners.
Threat intelligence reports
Microsoft customers can use Microsoft Defender XDR Threat analytics and related Microsoft threat intelligence reporting to stay current on the malicious activity, indicators, detection coverage, and recommended response actions associated with this compromise. These reports provide investigation context, protection guidance, and updated intelligence that security teams can use to prevent, mitigate, or respond to related activity in customer environments.
As with other active supply-chain investigations, defenders should monitor for updated intelligence on package status, additional affected versions, infrastructure changes, and newly surfaced post-compromise tradecraft. Microsoft will continue to incorporate validated indicators and detections into Microsoft security products as the investigation evolves.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
AsyncAPI npm packages with 2M weekly downloads were compromised, spreading malware with info-stealing, crypto-theft and RAT capabilities.
OX Security researchers disclosed on July 14 that the AsyncAPI npm organization was compromised, with malicious code injected into four packages that together account for over 2 million weekly downloads. The affected versions are @asyncapi/generator 3.3.1, @asyncapi/generator-components 0.7.1, @asyncapi/generator-helpers 1.1.1, and @asyncapi/specs 6.11.2 and 6.11.2-alpha.1. AsyncAPI is widely used by developers building event-driven APIs, which means the blast radius here touches a broad cross-section of professional development environments.
“This is a highly sophisticated, multi-stage supply chain attack. The malware functions as a hybrid info-stealer, crypto-stealer, and Remote Access Trojan (RAT).” reads the report published by OX. “It actively attempts to confuse analysts by mimicking known campaigns (like Miasma) and targets developers and repository maintainers.”
OX describes what was injected as far more than a simple credential harvester. The malware payload runs to 91,973 lines of code. Whoever wrote this was not in a hurry.
The infrastructure choices are deliberate and designed for resilience. The malware uses IPFS, a legitimate peer-to-peer file storage network, to host its payload and as a fallback command-and-control server if the primary C2 at 85[.]137[.]53[.]71 becomes unavailable.
“The malware uses ipfs.io – a legitimate peer-to-peer network to store and share data – in order to store its malicious payload. Later on it uses it as a fallback server in case the C2 server is not functional.” OX explains. “The malware also uses a wide array of backup communication nodes and beacons to keep communication alive even after the C2 fails, and to bypass network-based blocks.”
Beyond IPFS, the malware maintains communication through BitTorrent bootstrap nodes including router.bittorrent.com, router.utorrent.com, and dht.transmissionbt.com, giving it multiple fallback paths if any single channel is blocked at the network level.
The self-propagation capability is what makes this particularly dangerous for developer environments. If the malware finds valid authentication tokens for npm, PyPI, or Cargo on the compromised machine, it attempts to publish itself into packages the victim maintains on those registries. One compromised developer account becomes a new distribution vector.
The researchers found an embedded Ethereum contract address, 0x12c37A86a0Ed0beBe5d1d6a43E42f07860eAc710, in the code, however, they were not able to fully determine how it’s used operationally.
The malware checks whether it’s running inside a virtual machine, whether an endpoint detection tool is present, and whether the system’s locale is set to Russian. If any of those conditions are true, it terminates. This is standard practice for malware that doesn’t want to infect its operators’ own machines or run inside a security researcher’s sandbox.
“Although the malware has some similarities to the Shai-Hulud and Miasma campaigns, and it contains the Miasma string multiple times inside its code, this malware isn’t the same as them, nor is it attributed to the Miasma/Shai-Hulud/TeamPCP campaigns that we’ve seen in the past.” states the report.
The Miasma references inside the code appear to be deliberate misdirection rather than a genuine connection, a tactic designed to send analysts chasing the wrong attribution trail.
npm’s version 12 introduced restrictions on post-install scripts, specifically to prevent malware from executing code at install time. The attackers here didn’t need that vector.
The malicious payload was injected directly into the main JavaScript file of each affected package, making it indistinguishable from legitimate code at install time and executable the moment the package is imported in a project.
If you use any of the affected package versions, the immediate steps are to revoke all developer tokens associated with npm, PyPI, and Cargo on any machine that may have run these packages, rotate secrets, and audit recent commits and package releases in your own registries for unauthorized changes. Monitor for unexpected outbound connections to BitTorrent bootstrap nodes or IPFS gateways on developer networks, as these are the malware’s communication channels and would be unusual in a typical development environment. Check whether any packages you maintain have had unauthorized versions published while the affected versions were in use on your machines.
“npm’s v12 is out, blocking post-install scripts, but threat actors didn’t need to use them as they just embedded the malicious code inside the main JavaScript file without being blocked.” concludes the report. “This amplifies the message we extensively discussed in npm Is Fighting the Right War With the Wrong Weapons – and we don’t see this trend changing anytime soon.”
In a series of campaigns observed between mid-2025 and mid-2026, Microsoft identified threat actor activity with overlapping tradecraft commonly associated with ShinyHunters, including voice phishing (vishing) and supply chain compromise, to target customer SaaS-based applications such as Salesforce instances. The threat actors abused trusted OAuth relationships for unauthorized access, data exfiltration, and persistence.
Two primary intrusion paths were observed including vishing techniques targeting OAuth consent and supply chain compromise through trusted workflows and integrations such as Salesloft and Gainsight. Abuse of these access paths led to inherited user and application privileges, allowing successful enumeration and querying of customer relationship management (CRM) records while evading conventional authentication detections. These intrusion paths often led to persistent access and exfiltration of data at scale. This tradecraft highlights how a single entry point can rapidly expand to greater enterprise impacts.
Microsoft observed activity associated with these techniques in many tenants from various industries such as retail, education and manufacturing. These findings reinforce the importance of monitoring OAuth-connected applications, validating third-party integrations, reviewing configurations, and enabling Salesforce event monitoring. Leveraging this data, Microsoft consulted with Salesforce to improve granularity in telemetry for Defender for Cloud Apps with near-real-time detection, offering connected application attribution and expanded application permission insights. This activity was not the result of a vulnerability inherent to Salesforce. Rather, the threat actors abused trusted OAuth relationships for unauthorized access, data exfiltration, and persistence.
Attack chain overview
Threat actor campaigns targeting Salesforce customers and using tradecraft associated with ShinyHunters pose a high-impact risk to sensitive data and downstream SaaS ecosystems. These campaigns abuse OAuth trust relationships to operate within pre-existing, legitimate workflows.
Figure 1. Commonly observed attack paths for SaaS applications.
Observed activity can be grouped into two primary intrusion paths:
Voice‑phishing-driven OAuth consent abuse
In campaigns beginning in mid-2025, the threat actors conducted vishing attacks impersonating IT support personnel. Threat actors socially engineered employees into authorizing attacker-controlled connected apps within their Salesforce tenant. In several confirmed cases, threat actors guided users through the OAuth consent workflow to grant access to a malicious application disguised as a legitimate Salesforce Data Loader tool. After users granted consent, these highly privileged OAuth applications enabled threat actors to perform API calls on behalf of the victim user, facilitating:
Enumeration of Salesforce instances belonging to targeted organizations
Persistent access to Salesforce CRM data
Possible lateral movement into other SaaS platforms through discovered credentials
This intrusion path exploits the OAuth authorization flow of trusted SaaS services rather than relying on malware or credential replay. Threat actors exfiltrate data through sanctioned application access inherited from user privileges.
Following initial access campaigns, threat actors escalated into supply‑chain-driven attacks targeting third‑party SaaS vendors offering popular solutions that integrate with Salesforce, often using OAuth tokens. In August 2025, compromised Salesloft Drift credentials enabled attackers to obtain connection secrets used by downstream SaaS applications, enabling the use of OAuth tokens in multiple customer Salesforce instances.
A subsequent campaign in November 2025 targeted Gainsight-published applications integrated with Salesforce, allowing attackers to leverage trusted external connections to maintain persistent API access in multiple Salesforce customer instances. These activities often appeared indistinguishable from legitimate integration behavior. Threat actors performed discovery, bulk data queries, and mass exfiltration of sensitive CRM records, including accounts, contacts, and service case data, without generating traditional sign-in anomalies. More recently, in June 2026, the market intelligence platform Klue experienced an incident where a threat actor, Storm-3138, gained access to its system. Credentials used to access Salesforce customer instances were used in the same fashion, to discover, query, and exfiltrate data.
Investigations into these campaigns exposed a recurring challenge for security teams: malicious activity often appeared indistinguishable from legitimate Salesforce usage because threat actors operated through trusted identities, approved OAuth applications, and authorized integrations. Traditional authentication-focused detections frequently provided limited visibility into the resulting application activity.
To improve investigation and detection of these scenarios, Microsoft expanded Salesforce visibility in Defender for Cloud Apps through additional event telemetry, connected application attribution, and enhanced application permissions insights. These capabilities help security teams identify suspicious OAuth activity, investigate potentially compromised integrations, and better understand how access was obtained and used within customer Salesforce instances.
Key capabilities include:
Near-real-time visibility into Salesforce security and activity events.
Connected application attribution, including application identity and granted OAuth scopes.
Expanded identity, session, and API activity context to support investigations.
Improved correlation within Microsoft Defender to help identify suspicious activity spanning identities, applications, and SaaS environments.
Together with Salesforce Shield: Event Monitoring, these capabilities help security teams investigate suspicious OAuth activity, validate the legitimacy of connected applications, and better understand the potential impact of a compromise.
New posture and governance capabilities for connected OAuth apps
While improved detection is critical, recent incidents have also highlighted the need for stronger preventive controls and ongoing governance of OAuth-connected applications. To address this, Microsoft Defender introduces new posture capabilities for connected and external client apps in Salesforce. Security teams can gain visibility into each OAuth app and its non-human identity, prioritize risk, and reduce the attack surface.
Deep visibility into app permissions and access
Microsoft Defender provides comprehensive visibility into all Salesforce-integrated connected and external client apps, including granted OAuth scopes and privileges.
Figure 2. Complete permission visibility for Salesforce connected apps and external client apps.
Highly privileged apps
Security teams often struggle to identify applications with powerful administrative or sensitive permissions. The highly privileged apps insight highlights applications that have been granted elevated scopes, enabling quick identification of apps that may pose significant risk.
Additionally, security teams can use permission-based filters to identify apps with specific high-risk scopes and validate whether such access is justified.
Figure 3. Identity inventory to identify highly privileged Salesforce apps.
Unused apps
Organizations often create applications for temporary or one-time use, but those applications are rarely removed afterward. These unused apps continue to retain permissions, creating unnecessary exposure. With the recent changes, Defender now allows security teams to identify applications that have been inactive for extended periods (for example, 90 days or more), making it easy to review and revoke access where appropriate to reduce the attack surface.
Figure 4. Identity inventory to discover unused Salesforce apps.
Risk-based prioritization of connected apps
To further streamline investigation and response, Defender introduces a comprehensive risk scoring model for connected applications. Each application is assigned a numerical risk score [0-100] based on multiple risk indicators, such as usage patterns, permission sensitivity, and behavioral signals. This allows security teams to prioritize efforts effectively and focus on applications that require immediate attention. Security teams can create custom policies based on risk thresholds to trigger alerts, actions, and notifications.
Figure 5. Use actionable insights to identify apps exceeding a defined risk threshold.
Risk score investigation
To further investigate the specific Non-Human identity risk details, the factors contributing to the risk score are available in Non-Human Identities Risk score tab.
Figure 6. Detailed risk insights explaining factors contributing to the risk score.
Mitigation and protection guidance
Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.
Microsoft Defender for Cloud Apps customers can connect their Salesforce instance to get improved visibility and threat detection capabilities.
Microsoft Defender customers can refer to the list of applicable detections including new detections powered by the upgraded Microsoft Defender for Cloud Apps Salesforce connector. Microsoft Defender coordinates detection, prevention, investigation, and response for endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.
Tactic
Observed activity
Microsoft Defender coverage
Initial Access
A user’s Salesforce session was hijacked and used
Salesforce detected a possibly hijacked user session
Credential Access
A user was the target of credential stuffing activity
Salesforce detected a successful credential stuffing attack
Lateral Movement
A user with a very high risk score is signing into Salesforce via SSO
Salesforce SSO sign-in by high-risk user
Collection / Exfiltration
API-heavy access, report export, and scraping patterns; potential multi-SaaS expansion depending on victim footprint.
– Possible Salesforce scraping activity – Salesforce detected a user performing anomalous API activity – Salesforce detected a user performing anomalous report activity
Collection / Exfiltration
Anomalous behavior from Salesforce Connected Apps
– Salesforce Connected App activity from a new IP address – Salesforce Connected App activity involving new Salesforce entity – Salesforce Connected App activity involving new endpoint(s)
Collection / Exfiltration
Guest user activity associated with the AuraInspector framework
Suspicious Salesforce Aura Activity
Collection / Exfiltration
Anomalous behavior from a guest user
Salesforce detected a guest user performing anomalous activity
Threat intelligence reports
Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer Salesforce instances.
NOTE: The sample queries let you search one week of events. To inspect events and hunt for threat actor-related indicators over a longer period, go to the Advanced Hunting page > Query tab, and use the calendar dropdown to set the time range to Last 30 days (the maximum for raw data).
Hunt for Salesforce connected-app activity from suspicious infrastructure
CloudAppEvents
| where Application == "Salesforce"
| where ActionType in ("ApiTotalUsage", "API Event")
| extend ConnectedAppId = tostring(
coalesce(
RawEventData.CONNECTED_APP_ID, // from ApiTotalUsage
RawEventData.ConnectedAppId // from API Event
)
)
| where isnotempty(ConnectedAppId)
| where array_length(UncommonForUser) > 0 // at least 1 attribute is flagged as uncommon
Hunt for API activity associated with connected apps and relevant user ids
CloudAppEvents
| where Application == "Salesforce"
| where ActionType in ("ApiTotalUsage", "API Event")
| extend SalesforceUserId=coalesce(tostring(RawEventData.USER_ID), tostring(RawEventData.UserId))
| extend ConnectedAppName=tostring(RawEventData.CONNECTED_APP_NAME) // Connected App Name is not available on the ApiEvent event
| summarize count() by AccountObjectId, AccountId, AccountDisplayName, SalesforceUserId, IPAddress, UserAgent, ConnectedAppName
Hunt for anomalous report export / large data access
CloudAppEvents
| where Application == "Salesforce"
| where ActionType == "ReportExport"
| extend SalesforceUserId = tostring(RawEventData.USER_ID)
| summarize Events=count() by AccountObjectId, AccountId, AccountName, SalesforceUserId, IPAddress, UserAgent
Pivot from a suspicious connected app (name/id) to impacted users and actions
CloudAppEvents
| where Application == "Salesforce"
| where RawEventData has ""
| project Timestamp, AccountId, AccountDisplayName, ActionType, IPAddress, UserAgent, RawEventData
| order by Timestamp desc
Audit queries to verify what objects users are accessing
CloudAppEvents
| where Application == "Salesforce"
| where ActionType == "UniqueQuery"
| extend
QueryText = tostring(RawEventData.QUERY_IDENTIFIER), // Full query text
QueryObject = extract(@"(?i)\bfrom\s+([^\s]+)", 1, tostring(RawEventData.QUERY_IDENTIFIER)), // Extract just the target object
SalesforceUserId = tostring(RawEventData.USER_ID)
| where QueryText != "SOQL"
| project Timestamp, AccountDisplayName, SalesforceUserId, QueryObject, QueryText
Hunt for users with very high Defender risk score signing into Salesforce
let VeryRiskyUsers = IdentityInfo
| where RiskScore >= 90
| distinct AccountObjectId
CloudAppEvents
| where Application == "Salesforce"
| where ActionType has "sso" or ActionType has "saml"
| where AccountObjectId in (VeryRiskyUsers)
| project Timestamp, AccountObjectId, AccountDisplayName, ActionType, UserAgent
| order by Timestamp desc
Indicators of compromise (IOC)
After further investigation, Microsoft has discovered that two of the reported IP addresses belong to a researcher conducting attack research. We have removed the IOCs from this report.
Indicator
Type
Description
138.226.246.94
IP address
Used by the Klue integration to call Salesforce API to perform CRM queries on June 11. Previously disclosed by Klue in their notification about the breach.
212.86.125.24
IP address
213.111.148.90
IP address
94.154.32.160
IP address
MITRE ATT&CK techniques observed
Initial Access
T1566.004 Phishing: Voice Phishing: Impersonating IT support to get victims to grant access.
T1528 Steal Application Access Token: Using stolen OAuth tokens from Salesloft and Gainsight.
Persistence
T1671 Cloud Application Integration: Leveraging Connected Apps for access to a customer Salesforce environment.
Collection
T1213.004 Data from Information Repositories: Customer Relationship Management Software: Stealing data from a customer Salesforce environment.
Exfiltration
T1567 Exfiltration Over Web Service: Usage of the fake Data Loader application to steal data.
This research is provided by Microsoft Defender Security Research, Shruti Ranjit, Doug Cranston, Anand Deshpande, Ronen Rafaeli, and with contributions from members of Microsoft Threat Intelligence.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
LastPass said customer contact and support data were exposed after attackers used stolen Klue OAuth tokens to access its Salesforce environment and CRM records.
Attackers backdoored ShapedPlugin Pro updates, deploying malware that steals credentials, 2FA secrets, and grants full site access.
If you installed a ShapedPlugin Pro plugin between April and June 2026 and kept it updated, your site may be compromised. Not because you did something wrong, but because the vendor’s own build and distribution pipeline was breached. Cybersecurity firm Wordfence confirmed the attack on June 12th after obtaining a backdoored copy of Real Testimonials Pro 3.2.5 directly from ShapedPlugin’s official update endpoint.
ShapedPlugin is a WordPress software company that develops premium and free plugins for WordPress and WooCommerce websites. Founded in 2015, it offers plugins for carousels, galleries, testimonials, weather widgets, accordions, product displays, team showcases, and other website functions. Its products are used by hundreds of thousands of websites worldwide.
The WordPress plugin vendor has over 400,000 active free plugin installations
“During our investigation, we discovered that attackers compromised the vendor’s build and distribution pipeline, injecting backdoor code into Pro plugin releases distributed through official licensed update channels.” reads the report published by Wordfence. “As with all supply chain compromises, this attack is particularly insidious because affected site owners followed security best practices: they purchased legitimate licenses and installed updates directly from the vendor’s official update system. Supply chain compromises are becoming significantly more common in all software, including WordPress software.”
The researchers confirmed that at least three Pro plugins were compromised: Product Slider Pro for WooCommerce, Real Testimonials Pro, and Smart Post Show Pro. Free plugins on WordPress.org were left clean, which was almost certainly deliberate.
The infection runs in two stages. The first is a loader file called LicenseLoader.php that downloads a payload from an attacker-controlled server, installs it as a fake plugin, reports the victim domain back to the attacker, and then deletes itself.
“This self-deleting behavior means the initial infection vector disappears after first execution, complicating forensic analysis for site owners who notice the infection later.” continues the report.
The dropped payload disguises itself as WooCommerce-related plugins, using names like “woocommerce-subscription” in the singular form, one letter away from the legitimate plugin name.
What that payload does once installed is extensive. It hides itself from the WordPress admin plugin list, registers a REST API backdoor that accepts arbitrary file writes, bundles Tiny File Manager and Adminer for direct GUI access to files and databases, and installs a webshell that accepts commands via URL parameters. There’s also a hardcoded login bypass: a single MD5 hash lets the attacker authenticate as any administrator without knowing their password. That’s not a subtle intrusion; that’s a full set of keys.
The malware steals credentials in a more sophisticated way than typical threats.
“What makes this variant particularly concerning is its targeted exfiltration of two-factor authentication secrets. The malware specifically searches for TOTP seeds from multiple 2FA plugins.” continues the report.
Attackers send the stolen passwords and 2FA to generate.2faplugin.org, a domain that blends in with legitimate two-factor traffic. If an attacker has your password and your TOTP seed, changing your password after discovery doesn’t help.
The forensic evidence points to a CI/CD pipeline compromise rather than someone manually tampering with ZIP files. Only four files were modified on May 21st within a two-hour window, consistent with an automated build step. The compromised package also contains git SHA references confirming it was built from a private repository. The attacker had access to deploy updates to both WordPress.org and the Pro distribution system, but only injected malware into some Pro builds — either because WordPress.org scans for malware or because paying customers are higher-value targets. Possibly both.
The C2 infrastructure is registered to AEZA GROUP LLC, tied to Russian-based entities. The exfiltration domain 2faplugin.org was updated on May 10th, about eleven days before the backdoor was injected into Pro builds. Anyone who installed any ShapedPlugin Pro product between April and June 2026 should scan immediately, check for fake plugins under wp-content/plugins/woocommerce-subscription/ or woocommerce-notification/, rotate all WordPress admin passwords, database credentials, and API keys, and, critically, revoke and regenerate 2FA secrets for every user on the site, since existing TOTP seeds should be considered stolen.
“This supply chain attack demonstrates the evolving threat landscape facing WordPress site owners. The attackers did not exploit a vulnerability in the plugin code itself: they compromised the vendor’s build and distribution infrastructure, turning legitimate licensed updates into malware delivery vehicles.” concludes the report. “The inclusion of 2FA secret exfiltration marks a concerning evolution in WordPress-targeted malware.”
In May 2026, malicious code appeared inside packages used across NHS software projects. The software supply chain attack named Mini Shai-hulud by researchers spread through CI/CD systems, package registries, and developer tooling before anyone noticed something was wrong. It was caught quickly. Damage was limited.
The UK's National Cyber Security Centre is using that near-miss to bring into focus a more urgent case. The underlying conditions that made Mini Shai-hulud possible are not unique to that attack, and subsequent similar campaigns have gone undetected for longer and spread far more widely.
The Problem Is Structural
NCSC National Resilience Officer Jack F, is not mainly interested in a particular threat actor or a CVE but in how modern software development works — because that architecture is the vulnerability.
A single application today may rely on dozens, sometimes hundreds, of third-party packages like libraries, frameworks, SDKs, and code snippets pulled in automatically when a developer runs a single install command. Node.js, Python, and Rust are singled out as especially exposed because their minimal standard libraries push developers toward external registries for even basic functionality. Once a package is in a dependency tree, it often pulls in further packages of its own — transitive dependencies that the original developer never consciously chose.
This is not a flaw in the ecosystem's design. It is the design. The efficiency gains from reusable, trusted components are real, and the NCSC is not arguing against open source development. The argument is more specific to the combination of automation, implicit trust, and scale that turns a single compromised package into a vector capable of spreading malicious code across hundreds of organizations before any single one of them detects it.
Four Techniques Defenders Need to Know
The NCSC documents four attacker techniques active in recent campaigns. The first is maintainer account compromise — attackers steal credentials or tokens that allow them to push malicious updates to a trusted, legitimate package. This is how the Axios npm attack in March 2026 worked. The maintainer account was hijacked, a malicious dependency injected, and the backdoor distributed to an estimated 80% of cloud environments before the window closed.
The second technique is abandoned package takeover where attackers claim ownership of packages whose original maintainers have let their domains lapse or transferred control elsewhere. The third is typosquatting, in which, publishing packages with names that closely mimic popular legitimate ones, waiting for a developer to make a spelling error in an install command. The fourth is self-propagation, meaning, using credentials stolen from one package compromise to access or modify additional packages, creating a cascading contamination chain across an ecosystem.
All four techniques exploit the same structural feature. Once a package enters a trusted registry, downstream consumers inherit whatever trust that registry confers, automatically, at scale, with no human checkpoint.
What Defenders Are Being Asked to Do
The NCSC's immediate guidance falls into three categories. The first is visibility. Organizations must audit recent package updates and version changes, identify newly introduced or unexpected dependencies, and maintain a software bill of materials — a documented inventory of every component a codebase relies on. Without that inventory, it is impossible to know whether a compromised package is present at all.
The second is detection. Teams should monitor CI/CD activity, network traffic, and credential use for anomalies, and run dependency scanning tools against known indicators of compromise published after supply chain incidents.
And the third is remediation posture. If a compromise is suspected, automatic dependency updates should be paused immediately, new updates and versions reviewed manually before redeployment, and any potentially exposed API keys, tokens, and credentials rotated without waiting for confirmation of active exploitation. Enforcing multi-factor authentication on developer and package registry accounts is singled out specifically — the absence of universally enforced MFA on registry accounts is identified as a structural gap that maintainer account compromises directly exploit.
The NCSC also flags developer environments themselves as a soft target. Developer devices are typically less tightly controlled than managed corporate endpoints, making credential theft from developer workstations a reliable path to registry access that bypasses enterprise security controls entirely.
As supply chain attacks on PyPI and npm packages have become a near-weekly occurrence across security news feeds, rhe NCSC's guidance refers defenders to the Software Security Code of Practice as the authoritative framework for strengthening development and supply chain management. It also notes that its SSCoP implementation guidance will be updated shortly to reflect the specific attack scenarios.
The software supply chain has become one of the most attractive targets for modern adversaries, but the attacks seen in 2025 did not focus solely on poisoning dependencies or hijacking packages. Increasingly, attackers are targeting the infrastructure that powers the software delivery lifecycle itself.
Build servers, CI/CD runners, package managers, and developer workstations all sit inside an organization’s trusted delivery path. They are designed to execute code automatically, often with elevated privileges, and to move artifacts through the environment without scrutiny. Those same design principles make them ideal attack surfaces. Once an adversary gains access to this trusted infrastructure, malicious activity can blend seamlessly into legitimate build and release workflows.
Now, adversaries are increasingly adopting “shift-left” tactics to subvert build runners, poison development dependencies, and weaponize automation tools before code can even reach a production server. Instead of breaching the perimeter and forcing malware inward, attackers are compromising the systems that organizations inherently trust to deliver software. The result is a class of intrusion that is harder to detect, faster to scale, and capable of bypassing traditional security controls by abusing automation itself.
The Subversion of Trusted Infrastructure
Build servers and runners are high-value targets because they routinely execute privileged actions. They compile code, pull dependencies, move artifacts, and deploy software – all activities that mirror the behavior of an attacker attempting to establish persistence or distribute malware.
Threat actors have recognized that compromising build infrastructure gives them an opportunity to weaponize trust. In one case, attackers exploited a vulnerable self-hosted TeamCity server and remained undetected for more than a year. After gaining access, they created a benign-looking build configuration that was executed by a trusted build agent running with SYSTEM privileges. That build job then deployed a backdoor into internal environments.
Since the malicious code was delivered through a legitimate CI/CD task, it appeared indistinguishable from normal operational activity. No suspicious external binary was introduced, no obvious malware delivery mechanism was observed, and the deployment path blended into routine release workflows. This kind of attack points to the core challenge defenders face: In CI/CD environments, malicious behavior often looks exactly like expected behavior.
Turning Automation Against the Organization
Pipeline compromise does not always require direct malware execution on the build server. In many cases, attackers simply manipulate automation workflows to make the organization’s own tools carry out the intrusion.
One observed intrusion, noted in this year’s Annual Threat Report, involved the compromise of a GitLab service account token. The attacker used the token to create projects containing malicious Ansible playbooks, which were then automatically executed by the organization’s CI/CD pipeline. The build system treated the attacker’s commands as authorized automation, effectively turning the deployment pipeline into the orchestration mechanism for the compromise. This is what makes CI/CD subversion so dangerous. Rather than needing to evade the build process, the attacker simply inherits it.
Once inside the pipeline, the adversary gains the same benefits as the automation itself. This includes trusted execution, access to internal resources, and the ability to move laterally under the guise of legitimate activity. Traditional security tools often struggle to distinguish malicious pipeline actions from expected operational tasks, especially when those tasks are executed under valid service identities.
The Human Layer Is Part of the Pipeline
Some of the most effective “shift-left” attacks in 2025 targeted the developers themselves, bypassing the targeting of target code or infrastructure first. Campaigns like Contagious Interview used fraudulent job offers to compromise developers working in cryptocurrency and blockchain sectors. Victims were directed to fake skill-assessment sites where they encountered fabricated technical errors and were instructed to run commands to “fix” the issue. Those commands silently deployed malware on the developer’s workstation. This approach gave attackers direct access to the developer’s local environment, including SSH keys, repository access, tokens, and credentials. From there, the path into source code repositories and CI/CD systems became significantly easier.
By compromising the human operators behind the development process, attackers gain access at the earliest stage of the software lifecycle – what might be the ultimate “shift left” advantage. Instead of attacking production systems, they infiltrate the environments where software is built, tested, and trusted. This reinforces an important reality in which the software pipeline extends beyond infrastructure. Developers, maintainers, and service accounts are all part of the attack surface.
Unauthorized Runners and Persistent Access
Another growing tactic is the unauthorized registration of attacker-controlled systems as legitimate build runners. In the Sha1-Hulud campaign, malware infected systems and registered them as self-hosted GitHub runners under attacker-defined names. These rogue runners were then able to execute build tasks as trusted participants in the CI/CD process.
This is especially dangerous because self-hosted runners are often granted broad access to repositories, secrets, and deployment workflows. Once a malicious runner is registered, the attacker gains persistent, authorized access inside the development pipeline without needing to repeatedly exploit vulnerabilities.
The campaign also used malicious workflow triggers to ensure persistence. Certain workflows were designed to execute code when a user posted a comment in a repository discussion, turning routine collaboration features into execution mechanisms. Attackers no longer hijack the builds, opting instead to embed themselves into the development lifecycle in modern CI/CD compromise tactics.
Dependency Poisoning Evolves
While build infrastructure attacks surged, dependency poisoning remained a critical vector in 2025. Attackers published malicious versions of popular build packages that executed reconnaissance scripts during installation. These scripts harvested tokens, inspected environments, and in some cases targeted locally hosted AI systems.
In parallel, attackers used phishing to compromise trusted maintainer accounts, allowing them to append malicious code to legitimate package updates. As the updates originated from verified accounts and trusted repositories, they passed through normal review channels undetected.
Malicious code inherits the trust of the source that delivers it is now one of the defining characteristics of modern supply chain compromise. When dependencies, runners, and build jobs are all trusted by default, attackers only need to compromise one link in the chain to gain access to the entire pipeline.
Why Traditional Detection Falls Short
The core difficulty in defending CI/CD infrastructure is that standard build activity inherently resembles malicious behavior. Compiling binaries, downloading packages, invoking scripts, opening network connections, and moving artifacts are normal actions in a build environment. These same actions are also hallmarks of compromise. That overlap creates a blind spot. If a malicious job executes under a valid service account on a trusted runner, the behavior may appear legitimate unless the account performs actions that clearly deviate from its role.
This means traditional detection models based on signatures or isolated indicators are insufficient. Defenders need visibility into context – who created the job, what changed, where the runner was registered, what secrets were accessed, and whether the workflow deviates from expected patterns. The challenge is no longer identifying malware alone. It is verifying the integrity of every automated action across the pipeline.
Moving From Trust to Continuous Verification
The solution to CI/CD subversion is removing implicit trust from the automation process. Every build runner, dependency, script, and service identity should be continuously verified. Security teams need to know when new runners are registered, when build configurations change unexpectedly, when secrets are introduced into workflows, and when jobs exhibit suspicious runtime behavior.
This starts with strong dependency integrity controls such as Software Bills of Materials (SBOMs) to detect unauthorized package changes. It extends to secrets hygiene practices that identify exposed credentials in repositories and pipeline configurations.
Build runners should be treated as high-value systems, monitored for suspicious child processes, credential access attempts, reverse tunnels, and persistence mechanisms. Unauthorized registrations or unusual runner names should trigger immediate investigation.
Equally important is behavioral monitoring for build jobs themselves. New or modified pipelines created by service accounts, jobs interacting with unfamiliar repositories, or workflows that establish network tunnels should all be treated as potential indicators of compromise. The objective is to ensure that trust is earned continuously, not granted automatically.
Conclusion | The Future of Pipeline Defense
CI/CD pipelines have become one of the most strategically valuable targets in enterprise environments. They sit at the intersection of source code, secrets, automation, and deployment. A compromise at this layer gives attackers privileged access to the entire software delivery chain. The attacks that continue to make news headlines show that adversaries understand this well. They are exploiting build infrastructure, abusing automation workflows, hijacking developer trust, and embedding themselves directly into the software lifecycle.
For defenders, this means the security model must evolve. Protecting the pipeline requires treating automation infrastructure as critical security infrastructure, applying runtime protection to build agents, verifying the integrity of dependencies, and continuously monitoring every workflow for signs of abuse. The era of implicit trust in CI/CD is over. The organizations that adapt will be the ones that recognize a fundamental truth: In modern software delivery, the pipeline is part of the perimeter – and attackers are already inside it.
Third-Party Trademark Disclaimer:
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
SentinelOne's Annual Threat Report
A defender’s guide to the real-world tactics adversaries are using today to abuse identity, exploit infrastructure gaps, and weaponize automation.
OpenAI has disclosed details of its response to the recent TanStack npm supply chain attack, confirming that two employee devices were affected during the broader malware campaign known as Mini Shai-Hulud. The company said it found no evidence that customer data, production systems, or intellectual property were compromised during the incident.
The disclosure comes as software supply chain attacks continue to target widely used open-source dependencies and developer tooling. OpenAI stated that the attack involved a compromised version of the popular open-source library TanStack npm, which was used in parts of its internal environment.
According to the company, the incident was identified on May 11, 2026 UTC. OpenAI said it quickly launched an investigation, isolated affected systems, revoked sessions, rotated credentials, and temporarily restricted parts of its code deployment workflows as part of its containment efforts.
TanStack npm Supply Chain Attack Hit Two Employee Devices
OpenAI said the malware activity was limited to two employee devices within its corporate environment. During the investigation, the company observed behavior consistent with publicly reported details of the Mini Shai-Hulud malware campaign, including credential theft and unauthorized access attempts involving a limited number of internal source code repositories.
The company clarified that only a small amount of credential material was successfully exfiltrated and that no customer information or application code was affected.
OpenAI also engaged a third-party digital forensics and incident response firm to support the investigation and remediation process.
The impacted repositories included code-signing certificates used for OpenAI products across macOS, Windows, iOS, and Android platforms. As a precaution, the company is rotating those certificates and re-signing its applications with updated credentials.
macOS Users Required to Update OpenAI Apps
As part of the response to the TanStack npm supply chain attack, OpenAI is requiring all macOS users to update their applications before June 12, 2026.
The company warned that older macOS versions signed with previous certificates may stop functioning after that date because Apple’s security protections will block applications signed with the outdated credentials once the certificates are fully revoked.
Affected macOS applications include:
ChatGPT Desktop
Codex App
Codex CLI
Atlas
OpenAI said users can safely update through built-in application update mechanisms or official download pages. The company also warned users not to install apps from links shared through emails, messages, advertisements, or third-party download websites.
The company emphasized that it has not detected any malicious software signed using OpenAI certificates. It also confirmed that existing software installations were reviewed and no unauthorized modifications were identified.
No Impact to Customer Passwords or API Keys
In its FAQ, OpenAI stated that customer passwords, API keys, and user data were not exposed during the incident. The company also said it found no evidence that attackers used compromised credentials for follow-on access or further malicious activity.
Windows and iOS users are not required to take immediate action, though OpenAI noted that all applications are being re-signed with new certificates as part of the broader remediation effort.
The company explained that it delayed full certificate revocation until June 12 to avoid disrupting legitimate users. OpenAI said it has already worked with platform providers to block any new notarization attempts using the impacted certificates, reducing the likelihood of fake applications being distributed as legitimate OpenAI software.
OpenAI Highlights Growing Risk of Software Supply Chain Attacks
The company said the TanStack npm supply chain attack reflects the growing cybersecurity risks tied to modern software ecosystems, where organizations rely heavily on shared open-source libraries, package managers, and CI/CD infrastructure.
OpenAI noted that it had already been deploying additional security controls before the incident, including stricter package management protections, enhanced validation of third-party components, and stronger safeguards around sensitive CI/CD credentials.
However, the company acknowledged that the two affected employee devices had not yet received the updated security configurations that could have prevented the malicious package from being downloaded.
The incident adds to increasing industry concerns around software supply chain security, especially as threat actors continue targeting trusted development tools and widely used open-source packages to gain access to enterprise environments.
Entrar
