In this article 1. Attack chain overview 2. Threat actor attribution 3. Mitigation and protection guidance 4. Indicators of Compromise (IOC) 5. References 6. Learn more Microsoft Threat Intelligence has uncovered an active supply chain attack involving malicious npm packages registered under organizational scopes that mirror real internal corporate namespaces, employing dependency confusion technique to deploy an obfuscated reconnaissance payload. On May 28 and May 29, 2026, a threat actor operating under three maintainer aliases mr.4nd3r50n (_mr.4nd3r50n@yandex[.]ru_), ce-rwb (_ogvanta@yandex[.]ru_), and t-in-one (_t-in-one@yandex[.]ru_) published malicious packages across two publishing bursts. The packages impersonate internal corporate packages across nine different organizational scopes using a dependency confusion technique, and several spoof internal enterprise infrastructure URLs (GitHub Enterprise, Jira, documentation portals) in their _package.json_ to appear legitimate. Once installed, the packages download and execute an obfuscated reconnaissance payload from an attacker-controlled command-and-control (C2) server. All packages in the cluster ship the same heavily obfuscated _postinstall_ stager and connect to the same C2 endpoint, a ~17 KB JavaScript dropper used for for environment fingerprinting and credential reconnaissance. The payload runs silently during _npm install_ and operates in "reconnaissance-only" mode, collecting system information, hostnames, environment variables, and developer context. The architecture includes a _RECON_ONLY_ flag that can be toggled server-side for full exploitation in follow-on attacks. Based on our investigation and feedback to the npm team these repos and users were taken down. Key capabilities observed in the campaign include automatic execution through npm lifecycle hooks, obfuscator.io-style anti-analysis techniques, platform-specific payload delivery (Windows, macOS, Linux), continuous integration and continuous delivery (CI/CD) environment detection and bypass, cache-based deduplication to evade repeated-execution monitoring, and a two-phase attack design (reconnaissance now, exploitation later). ## Attack chain overview The campaign spans dozens of scoped packages published under three npm maintainer accounts that our forensic analysis attributes to a single operator (detailed in the Attribution section below). The attack proceeds through: * Publication of dependency confusion packages under three actor identities across nine organizational scopes * Automatic payload execution through a _postinstall_ hook during _npm install_ * Execution chain: _npm install_ → _postinstall_ → _scripts/postinstall.js_ (obfuscated) → HTTPS GET to C2 → write payload to _tmpdir_ → _spawn_ detached process * Environment reconnaissance with credentials and context exfiltration using environment variables passed to the spawned payload ![](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/05/image-180.webp)Figure 1. Dependency confusion attack flow. ### The lure: Dependency confusion and spoofed internal metadata The actor adopted three social-engineering techniques designed to drive installs through misconfigured package managers or developer trust transference: ### **Namespace squatting** The ** ** attacker registered packages under organizational scopes that mirror real internal corporate namespaces: _@cloudplatform-single-spa_ , _@wb-track_ , _@data-science_ , _@ce-rwb_ , _@payments-widget_ , _@travel-autotests_ , _@t-in-one_ , _@capibar.chat_ , and _@sber-ecom-core_. Package names like svp-baas, enterprise, monitoring, ssh-keys, shared-front, payments-widget-sdk, add_application_service_token, ui-kit, and sberpay-widget target specific internal services — the last of which directly impersonates Sberbank's SberPay payment widget. ### **Spoofed enterprise metadata** Every package sets its _package.json_ homepage, repository, bugs, and author fields to fabricated but realistic-looking internal infrastructure URLs. For example: * Repository: _git+https://github[.]cloudplatform-single-spa[.]io/platform/svp-baas.git_ * Homepage: _https://docs[.]cloudplatform-single-spa[.]io/platform/svp-baas_ * Bugs: _https://jira[.]cloudplatform-single-spa[.]io/projects/PLATFORM_ * Author: _Cloudplatform-Single-Spa Platform Engineering _ These URLs follow the pattern of enterprise GitHub, Jira, and documentation portals, lending an air of legitimacy designed to evade casual inspection during code review. ### **Inflated version numbers** ** ** mr.4nd3r50n uses version 100.100.100, an absurdly high version number designed to win npm's server resolution against any real internal package version. ce-rwb uses a more realistic 3.5.22 to blend in with legitimate release histories. t-in-one mixes both tactics: the ten @t-in-one packages ship at 5.7.1, while @capibar.chat/ui-kit (99.5.7) and @sber-ecom-core/sberpay-widget (99.5.8) use inflated numbers — and both of the latter scopes were pre-staged with 99.0.7 releases on 2026-05-04, weeks before the main bursts. ![](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/05/image-181.webp)Figure 2. The malicious package.json. The postinstall hook gains code execution on every `npm install`. Version 100.100.100 ensures the malicious package wins dependency resolution over any real internal version. ### Execution: npm lifecycle hook abuse Every package in the cluster declares an automatic install-time hook in _package.json_ : "scripts": { "build": "tsc --noEmit || true", "test": "node test/index.test.js", "postinstall": "node scripts/postinstall.js", "prepublishOnly": "echo 'Building...'" } The malicious code executes the moment a victim runs _npm install_ ; no _require()_ from victim code is needed. The _build_ and _test_ scripts are cosmetic, designed to make the package appear to have a legitimate development workflow. ### Stager: Obfuscated JavaScript dropper _scripts/postinstall.js_ is approximately 7 KB of heavily obfuscated JavaScript using **obfuscator.io-style** techniques: * **String array encoding** : All meaningful strings (URLs, function names, environment variable keys) are stored in a rotated array and decoded at runtime through a custom Base64 variant * **Control flow flattening** : Logic branches are obscured through computed dispatch tables * **Dead code injection** : Anti-analysis noise makes manual review prohibitively time-consuming * **Self-defending code** : Anti-tampering checks detect modifications to the obfuscated code ![](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/05/image-182.webp)Figure 3. Obfuscated postinstall.js. After deobfuscation, the payload reveals the C2 URL, platform detection logic, and file-drop/spawn execution pattern. ### Execution flow: from _npm install_ to detached payload The deobfuscated execution flow proceeds through eight distinct stages: 1. **CI detection bypass** : The stager checks for the _CI_ environment variable (or scope-specific equivalents like _CLOUDPLATFORM_SINGLE_SPA_NO_TELEMETRY_). If detected, execution silently aborts. This avoids triggering alerts in monitored CI/CD pipelines where security tooling is more likely to detect anomalous behavior. 2. **Node.js version validation** : The stager verifies _process.versions.node_ >= 16.0. Older Node.js versions are skipped, likely because the payload depends on modern APIs. 3. **Cache deduplication** : A cache directory is created at _~/.cache/ _init/_ (for example, _~/.cache/._cloudplatform-single-spa_init/_). The stager generates a hash key from the package name, version, and project root path. If a cache entry exists and hasn't expired, the stager exits. This prevents the payload from re-running on every _npm install_ in the same project, reducing the chance of detection through repeated network connections. 4. **Project root detection** : The stager walks up the directory tree from _process.cwd()_ looking for _package.json_ , _yarn.lock_ , or _.git_ to identify the project root. This context is incorporated into the cache key and passed to the payload. 5. **Platform detection** : _os.platform()_ determines the target OS variant (_win32_ → _win_ , _darwin_ → _mac_ , _default_ → _linux_). 6. **Payload download** : An HTTPS GET request is made to the C2 server at _https://oob.moika[.]tech/payload/ _ with a 30-second timeout. The response is a binary payload. 7. **Payload drop** : The downloaded binary is written to _os.tmpdir()_ as a _.js_ file (for example, _/tmp/._cloudplatform-single-spa_init.js_). 8. **Detached execution** : Payload spawned as an independent background process with .unref() to outlive npm install. ![](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/05/image-184.webp)Figure 4. Detailed execution chain from npm install trigger through CI detection, caching, C2 download, to detached background process spawn. ### Reconnaissance mode and two-phase design The environment variables passed to the spawned payload reveal a deliberate two-phase attack architecture: **Variable**| **Purpose** ---|--- *_RECON_ONLY| Set to "1" by default; limits payload to reconnaissance *_PKG| Identifies which internal package triggered the execution *_VER| Package version for campaign tracking *_SECRET| Hard-coded authentication token for C2 communication The _RECON_ONLY_ flag is hard-coded to "1" in the current campaign, indicating the attacker is in** Reconnaissance** — collecting environment information, hostnames, installed packages, and developer context. The architecture supports a** Full exploitation** mode where the flag can be toggled server-side to enable data exfiltration, credential theft, or backdoor installation on previously fingerprinted targets. This two-phase design is sophisticated: it minimizes the risk of detection during initial deployment while building a target inventory for selective, high-value exploitation later. ## Threat actor attribution Forensic analysis of npm registry metadata across every package in the cluster provides high-confidence evidence that the three accounts (mr.4nd3r50n, ce-rwb, and t-in-one) are operated by the same individual. The single strongest piece of evidence is a shared hardcoded authentication value, l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1, sent as the X-Secret HTTP header on every outbound C2 request from every package in all three accounts. ![](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/05/image-185.webp)_Figure 5. Side-by-side forensic comparison of the two actor accounts. Every measurable property matches or is nearly identical, providing high-confidence single-operator attribution._ ### **Identical C2 infrastructure** Both accounts' payloads connect to the exact same C2 server: _https://oob.moika[.]tech/payload_. Sharing offensive infrastructure across "separate" personas is the strongest single indicator of a single operator. Maintaining separate C2 servers would be trivial, so using the same one indicates the shared infrastructure supports our assessment that the activity is associated with a single operator. ### **Same publishing toolchain** mr.4nd3r50n's early versions (v99.99.99) were published with Node.js 20.20.1 / npm 10.8.2. ce-rwb's packages were published with Node.js 20.20.0 / npm 10.8.2. t-in-one's @t-in-one packages were published with Node.js 20.20.1 / npm 10.8.2 — matching mr.4nd3r50n exactly. The minor variance across the three accounts suggests the same machine at slightly different patch levels, or a small set of machines configured from the same provisioning script. ### **Identical package template generator** Both actors use the exact same templating system for generating fake package metadata: * Author: _" Platform Engineering" .io>_ * Repository: _git+https://github. .io/platform/.git_ * Documentation: _https://docs. .io/platform/_ * Issue tracker: _https://jira. .io/projects/PLATFORM_ * README: Identical structure including a fake "Telemetry" disclaimer and the same changelog entries ("Added ARM64 support", "Improved error handling", "Updated TypeScript types") This level of template consistency, down to identical changelog entries across every package, including the @t-in-one README that points developers at a fabricated internal registry at npm.t-in-one[.]io with matching docs.t-in-one[.]io and jira.t-in-one[.]io references — indicates a single automated package generator. ### **Temporal correlation: 12-minute gap** mr.4nd3r50n published 26 packages between 18:47–18:51 UTC on May 28. ce-rwb published 7 packages between 19:02–19:03 UTC on May 28 — a 12-minute gap consistent with one person completing one publishing batch, switching npm accounts, and starting the next. t-in-one returned the following day, publishing 10 @t-in-one packages between 09:01:56 and 09:02:39 UTC on May 29 (a 43-second automated burst), with the @capibar.chat and @sber-ecom-core republishes following minutes later. The ~14-hour overnight gap between ce-rwb and t-in-one, paired with the unchanged C2 host and identical X-Secret, indicates the same operator returning to expand the campaign rather than a separate group. ### **Bug bounty to malware pipeline** The _@cloudplatform-single-spa/logaas_ package reveals a critical piece of the actor's history: ![](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2026/05/image-186.webp)Figure 7. The actor's evolution from bug bounty researcher (April 2024) to hosting malware (May 2026), with a ~2 year gap between phases. * **v0.0.0** (April 10, 2024): Published with keywords ["Bugbounty", "mr4nd3r50n"] and description "BugBounty testing by mr4nd3r50n" using Node.js 21.7.1 / npm 10.5.0 * **v99.99.99** (June 5, 2024): Same bug bounty markers, same toolchain * **v99.99.100** (May 28, 2026, 18:47 UTC): First appearance of the malicious obfuscated payload, upgraded to Node.js 24.8.0 / npm 11.6.0 * **v100.100.100** (May 28, 2026, 18:50 UTC): Final malicious version This timeline shows mr.4nd3r50n began as a bug bounty researcher probing npm dependency confusion in April 2024 followed by the malicious packages observed in this campaign.y approximately two years later. The ce-rwb account has no prior publishing history, suggesting it was created specifically for the May 2026 campaign as a secondary persona to broaden the attack surface across additional organizational scopes. ### Affected packages #### mr.4nd3r50n — 26 packages (all version 100.100.100) All packages use the scope @cloudplatform-single-spa: **Package**| **Description** ---|--- svp-baas| Database/Backend-as-a-Service enterprise| Enterprise platform vpn| VPN service monitoring| Monitoring platform dataplatform-trino| Trino data platform marketplace-gigachat| GigaChat marketplace support| Support tools svp-s3-storage| S3 storage service ml-ai-agents-agent| ML/AI agents ssh-keys| SSH key management security-groups| Security groups employees| Employee directory cp-api-gw| API gateway base-static-page| Static page framework administration| Administration panel ml-ai-agents-agent-system| AI agent system arenadata-db| ArenaData database business-solutions| Business solutions dataplatform-metastore| Data metastore cloud-dns| Cloud DNS dataplatform| Data platform datagrid| Data grid floating-ips| Floating IP management cnapp-ui| CNAPP security UI svp-interfaces| SVP interfaces logaas| Logging-as-a-Service #### ce-rwb — 7 packages (all version 3.5.22) **Package**| **Scope Targeted** ---|--- @wb-track/shared-front| WB-Track (warehouse/logistics tracking) @data-science/llm| Data Science / LLM platform @ce-rwb/ce-tools-editor-admin| CE-RWB internal editor tools @ce-rwb/ce-tools-editor-render| CE-RWB internal editor tools @ce-rwb/ce-tools-editor-core| CE-RWB internal editor tools @payments-widget/payments-widget-sdk| Payments processing SDK @travel-autotests/npm-proto| Travel platform test protobuf #### t-in-one — 12 packages (May 29 wave) t-in-one returned on May 29 with a third npm account, t-in-one (t-in-one@yandex[.]ru), and expanded the campaign across three previously unused scopes. The ten @t-in-one package names are deliberately credential- and token-themed so they read as internal auth modules; @capibar.chat/ui-kit is a textbook dependency confusion artifact against an internal UI kit; and @sber-ecom-core/sberpay-widget directly impersonates Sberbank's SberPay payment widget — making the campaign's financial-sector targeting explicit. Unlike the May 28 wave, the May 29 stager ships a three-layer-obfuscated postinstall (~13 KB) and adds a functional T_IN_ONE_NO_TELEMETRY kill switch and a run-once marker directory at ~/.cache/._t-in-one_init/. The C2 host, payload endpoints, and hardcoded X-Secret value are identical to the May 28 wave. **Package**| **Scope Targeted** ---|--- @t-in-one/add_application| T-in-one — credential/auth module @t-in-one/add_app_middleware_token| T-in-one — credential/auth module @t-in-one/get_application_hid| T-in-one — credential/auth module @t-in-one/form_product_token| T-in-one — credential/auth module @t-in-one/application_id_storage_key_token| T-in-one — credential/auth module @t-in-one/only_difference_payload| T-in-one — credential/auth module @t-in-one/prefill_credit_data_token| T-in-one — credential/auth module @t-in-one/prefill_bundle_data_token| T-in-one — credential/auth module @t-in-one/add_application_tid| T-in-one — credential/auth module @t-in-one/add_application_service_token| T-in-one — credential/auth module @capibar.chat/ui-kit| Capibar Chat — internal UI kit @sber-ecom-core/sberpay-widget| Sberbank — impersonation of SberPay payment widget ## Mitigation and protection guidance Microsoft recommends the following mitigations to reduce the impact of this threat: * Review dependency trees for direct or transitive usage of any of the nine affected scoped packages (@cloudplatform-single-spa, @wb-track, @data-science, @ce-rwb, @payments-widget, @travel-autotests, @t-in-one, @capibar.chat, @sber-ecom-core). * Identify systems that installed or built any of the affected package versions on or after May 28, 2026, including the pre-staged @capibar.chat/ui-kit 99.0.7 and @sber-ecom-core/sberpay-widget 99.0.7 releases from 2026-05-04. * Pin known-good package versions where possible and avoid automatic dependency upgrades for the affected scopes until validation is complete. * Disable pre- and post-installation script execution by ensuring you run npm install with -ignore-scripts (or by setting npm config set ignore-scripts true globally). * Rotate credentials, tokens, npm access tokens, CI/CD secrets, and cloud credentials that might have been exposed on affected developer workstations or CI/CD runners. * Scope-lock internal npm registries by configuring .npmrc so that all nine targeted scopes resolve exclusively to your private registry and never fall back to the public npm registry. * Block egress to oob.moika[.]tech and the lure domains npm.t-in-one[.]io, docs.t-in-one[.]io, and jira.t-in-one[.]io at proxy, firewall, and DNS layers. * Audit CI/CD logs for unexpected outbound network connections, script execution, or suspicious package lifecycle activity tied to the affected scopes. * Review npm package lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml), build logs, and artifact provenance for evidence of compromised package versions. * Audit ~/.cache/ directories and os.tmpdir() for dropped .js payloads matching the pattern .__init.js (e.g., ._cloudplatform-single-spa_init.js, ._wb-track_init.js, ._t-in-one_init.js) and the run-once marker directory ~/.cache/._t-in-one_init/. * Hunt for outbound HTTP requests carrying the header value X-Secret: l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1 — its presence is a high-fidelity indicator of compromise across all three operator accounts. * Enable cloud-delivered protection in Microsoft Defender Antivirus or equivalent antivirus protection. * Use Microsoft Defender XDR to investigate suspicious activity across endpoints, identities, cloud apps, and developer environments. * Use Microsoft Defender Vulnerability Management to search for affected scoped packages across your estate. ### How Microsoft Defender helps Microsoft Defender Antivirus detects and blocks the obfuscated postinstall stager and the detached recon payload on access. During reproduction in our analysis environment, the dropped .__init.js stager was automatically quarantined the moment the package tarball was extracted to disk, preventing the C2 beacon to oob.moika[.]tech and blocking the platform-specific second-stage download. Microsoft Defender for Endpoint provides additional behavior-based coverage for the npm lifecycle script-abuse and detached child-process patterns observed in this campaign. ### Microsoft Defender XDR Detections 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. 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** ---|---|--- Execution| Suspicious script execution during npm install or package lifecycle activity tied to the affected scopes| **Microsoft Defender Antivirus** – Trojan:JS/ObfusNpmJs.SA **Microsoft Defender for Endpoint** – Suspicious Node.js process behavior – Suspicious detached child process spawned with windowsHide=true – Suspicious file creation in temporary directory by Node.js binary Defense Evasion| Three-layer-obfuscated postinstall.js (obfuscator.io + custom base64 + integer-shuffle string table) and install-time kill switch (T_IN_ONE_NO_TELEMETRY)| **Microsoft Defender Antivirus** – Trojan:JS/ObfusNpmJs **Microsoft Defender for Endpoint** – Suspicious obfuscated JavaScript execution – Anomalous environment variable usage in npm lifecycle script Credential Access| Reconnaissance and potential harvesting of environment variables, tokens, and developer secrets via the detached payload| **Microsoft Defender for Endpoint** – Credential access attempt – Suspicious cloud credential access by npm-spawned process – Environment variable enumeration indicative of credential access **Microsoft Defender for Cloud** – Possible command injection to exfiltrate credentials from a build pipeline Command and Control| Outbound HTTPS connections from build systems or developer machines to oob.moika[.]tech carrying the hardcoded X-Secret header| **Microsoft Defender for Endpoint** – Connection to a custom network indicator – Suspicious outbound connection from Node.js process to low-reputation domain Persistence| Run-once marker directory at ~/.cache/._t-in-one_init/ and .__init.js payloads dropped in os.tmpdir() and launched with detached: true| **Microsoft Defender for Endpoint** – Suspicious persistence file creation in user cache directory – Detached Node.js process surviving parent npm install exit ### Microsoft Security Copilot Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports. Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently: * Threat Intelligence Briefing agent * Phishing Triage agent * Threat Hunting agent * Dynamic Threat Detection agent Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs. ### Microsoft Defender XDR Threat analytics Microsoft Defender XDR customers can reference the Threat analytics report for this campaign in the Microsoft Defender portal at https://security.microsoft.com/threatanalytics3 for the latest indicators, recommended actions, and mitigation status across their estate. ### Advanced hunting The following sample queries let you search for a week's worth of events. To explore up to 30 days of raw data, go to the Advanced Hunting page > Query tab, and update the time range to Last 30 days. **Hunt for suspicious npm lifecycle script execution involving the affected scopes.** Searches for Node.js and npm activity involving install lifecycle behavior and references to the nine affected scoped packages. DeviceProcessEvents | where FileName in~ ("node.exe", "npm.cmd", "npm.exe", "npx.cmd", "npx.exe") | where ProcessCommandLine has_any ("preinstall", "postinstall", "install") | where ProcessCommandLine has_any ( "@cloudplatform-single-spa", "@wb-track", "@data-science", "@ce-rwb", "@payments-widget", "@travel-autotests", "@t-in-one", "@capibar.chat", "@sber-ecom-core") | project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName **Hunt for affected package versions in software inventory.** Searches device software inventory for any installed packages from the affected scopes. DeviceTvmSoftwareInventory | where SoftwareName has_any ( "cloudplatform-single-spa", "wb-track", "data-science", "ce-rwb", "payments-widget", "travel-autotests", "t-in-one", "capibar.chat", "sber-ecom-core") | project DeviceName, OSPlatform, SoftwareVendor, SoftwareName, SoftwareVersion **Hunt for outbound C2 activity to oob.moika[.]tech.** Searches for any device network connection to the campaign C2 host. DeviceNetworkEvents | where Timestamp > ago(7d) | where RemoteUrl has "oob.moika.tech" or RemoteUrl has_any ("npm.t-in-one.io", "docs.t-in-one.io", "jira.t-in-one.io") | project Timestamp, DeviceName, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName **Hunt for suspicious outbound activity from Node.js processes.** Searches for network connections initiated by Node.js or npm processes referencing the affected scopes or node_modules paths. DeviceNetworkEvents | where InitiatingProcessFileName in~ ("node.exe", "npm.exe", "npx.exe") | where InitiatingProcessCommandLine has_any ( "@cloudplatform-single-spa", "@wb-track", "@data-science", "@ce-rwb", "@payments-widget", "@travel-autotests", "@t-in-one", "@capibar.chat", "@sber-ecom-core", "node_modules") | project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName **Hunt for dropped stager payloads in temp and cache directories.** Searches device file events for the .__init.js payload pattern and the May 29 run-once marker directory. DeviceFileEvents | where Timestamp > ago(7d) | where FileName matches regex @"^\._.*_init\.js$" or FolderPath has_any ( ".cache/._cloudplatform-single-spa_init", ".cache/._wb-track_init", ".cache/._t-in-one_init") | project Timestamp, DeviceName, FolderPath, FileName, ActionType, InitiatingProcessFileName, InitiatingProcessCommandLine **Hunt for the campaign-wide X-Secret header in outbound HTTP traffic.** Searches for outbound web traffic carrying the hardcoded X-Secret value used by all three operator accounts (requires TLS decryption or proxy logging that captures request headers or bodies). DeviceNetworkEvents | where Timestamp > ago(7d) | where AdditionalFields has "l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1" or RemoteUrl has "oob.moika.tech" | project Timestamp, DeviceName, RemoteUrl, RemoteIP, AdditionalFields, InitiatingProcessFileName, InitiatingProcessCommandLine **Hunt for affected dependency references in developer directories.** Searches for package manifest or lockfile activity referencing the affected scoped packages. DeviceFileEvents | where FileName in~ ("package.json", "package-lock.json", "yarn.lock", "pnpm-lock.yaml", ".npmrc") | where FolderPath has_any ("node_modules", "src", "repo", "workspace") | where AdditionalFields has_any ( "@cloudplatform-single-spa", "@wb-track", "@data-science", "@ce-rwb", "@payments-widget", "@travel-autotests", "@t-in-one", "@capibar.chat", "@sber-ecom-core") | project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine ## Indicators of Compromise (IOC) ### Actor and network IOCs **Indicator**| **Type**| **Description** ---|---|--- mr.4nd3r50n| npm maintainer| Threat actor (mr.4nd3r50n) — 26 packages, May 28 wave ce-rwb| npm maintainer| Threat actor (ce-rwb) — 7 packages, May 28 wave mr.4nd3r50n@yandex[.]ru| Email| mr.4nd3r50n contact email ogvanta@yandex[.]ru| Email| ce-rwb contact email t-in-one| npm maintainer| Threat actor (t-in-one) — 12 packages across @t-in-one, @capibar.chat, @sber-ecom-core, May 29 wave t-in-one@yandex[.]ru| Email| t-in-one contact email l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1| Shared secret| Hardcoded X-Secret HTTP header value sent on every outbound C2 request from all three accounts — single-operator attribution marker npm.t-in-one[.]io| Lure domain| Fabricated internal-registry hostname referenced in @t-in-one README to lend legitimacy docs.t-in-one[.]io / jira.t-in-one[.]io| Lure domain| Fabricated documentation and issue-tracker hostnames in @t-in-one package metadata `oob.moika[.]tech`| Domain| C2 server for payload delivery `https://oob.moika[.]tech/payload/win`| URL| Windows payload endpoint `https://oob.moika[.]tech/payload/mac`| URL| macOS payload endpoint `https://oob.moika[.]tech/payload/linux`| URL| Linux payload endpoint ### File and environment IOCs **Indicator**| **Type**| **Description** ---|---|--- `scripts/postinstall.js`| Filename| Obfuscated stager (~7 KB) `._cloudplatform-single-spa_init.js`| Filename| Dropped payload in tmpdir `._wb-track_init.js`| Filename| Dropped payload (ce-rwb variant) `~/.cache/._cloudplatform-single-spa_init/`| Directory| Cache/dedup directory `~/.cache/._wb-track_init/`| Directory| Cache/dedup directory (ce-rwb) `*_RECON_ONLY=1`| Env var| Reconnaissance mode flag `*_PKG`| Env var| Package name identifier `*_VER`| Env var| Package version identifier `*_SECRET`| Env var| C2 authentication token ._t-in-one_init.js| Filename| Dropped payload in tmpdir — t-in-one (May 29 wave) ~/.cache/._t-in-one_init/| Directory| Run-once marker directory used by the May 29 stager for per-host deduplication T_IN_ONE_NO_TELEMETRY| Env var| Functional install-time kill switch honored by the May 29 obfuscated stager (the May 28 *_NO_TELEMETRY variables are README fiction only) X-Secret: l95HdDaz3kQx1Zsg3WxH6HvKANf51RY1| HTTP header| Hardcoded authentication header sent on every outbound C2 request from all three accounts ## References * https://www.npmjs.com/~mr.4nd3r50n — npm maintainer profile (26 packages) * https://www.npmjs.com/~ce-rwb — npm maintainer profile (7 packages) * https://www.npmjs.com/~t-in-one — npm maintainer profile (12 packages across @t-in-one, @capibar.chat, @sber-ecom-core) ## Learn more For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog. To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky. 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. * Microsoft 365 Copilot AI security documentation * How Microsoft discovers and mitigates evolving attacks against AI guardrails * Learn more about securing Copilot Studio agents with Microsoft Defender * Evaluate your AI readiness with our latest Zero Trust for AI workshop. * Learn more about Protect your agents in real-time during runtime (Preview) * Explore how to build and customize agents with Copilot Studio Agent Builder The post Malicious npm packages abuse dependency confusion to profile developer environments appeared first on Microsoft Security Blog.

Query Builder