OmniStealer: an npm supply-chain investigation

OmniStealer: An npm Supply-Chain Campaign Linked to DPRK

Disclosure: This report documents analysis of a supply-chain malware incident, drawing on static and dynamic malware analysis, network interception, OSINT correlation of threat-actor infrastructure and identities, and direct interaction with the actor’s command-and-control channels. No victim-identifying information has been included.

Summary

In August 2026, a third-party researcher, QUIX, flagged a malicious npm package, tailwind-animationpack, distributed via a fake GitLab repository built to look like a legitimate web3/full-stack project. The package concealed an obfuscated eval stager behind an otherwise unremarkable dependency, which unpacked into a multi-stage downloader chain and ultimately deployed a Python-based information stealer we’ve named OmniStealer.

The investigation, tracked as Lazarus-Group-Omni, traced the campaign back through a chain of compromised and threat-actor-controlled accounts across GitLab, GitHub, and npm – including a real developer’s compromised GitHub account used to host a malicious pull request, and a GitLab commit identity (PolinRider) matching an alias independently documented as belonging to a DPRK-affiliated threat actor. Combined with the stager’s resemblance to known BeaverTail/InvisibleFerret tooling associated with DPRK operations, the behaviour of the campaign heavily ties into the known TTP of the Lazarus Group.

The malicious package and a related, older sibling package have both since been removed following takedown reports to npm, with removal confirmed by GitHub Trust & Safety / npm Security. The actor’s command-and-control infrastructure went quiet following the takedown and subsequent interference with its Telegram exfiltration channel.

Incident Overview

Initial Infection

The lure here wasn’t a phishing email or a cracked tool, it was a dependency. tailwind-animationpack presented itself as an ordinary front-end animation utility, but a single line in src/index.js (line 15) called out to an obfuscated eval stager. Any project pulling in the package as a dependency would silently execute it.

The package’s supply chain traced back to a GitLab repository, jacky870120/full-stack-test, styled to resemble a legitimate developer’s project. Commit history in a related, since-archived repository tied the account to at least two further identities: yugin0120 and a Polin9912 account using the email PolinRider@outlook.com, both contributing under the same operator.

Separately, a compromised GitHub account belonging to a real developer was found hosting a suspicious pull request, indicating the operator was also willing to piggyback on trusted, previously legitimate accounts to lend credibility to their tooling – a pattern consistent with known social-engineering approaches used to target web3 developers with convincing, seemingly-legitimate repositories.

Payload Chain

Execution of the stager followed a layered path: /ls -> /boot -> a second-stage JavaScript payload -> the final Python stealer, fetched from a path we’re calling /$/1 on the C2 server. Each stage was encrypted, initially with per-endpoint XOR keys and subsequently identified as RC4 once later stages were reached, with an additional layer of JavaScript obfuscation on top. The /boot stage also reused Express.js server code the operator had apparently employed in an earlier campaign.

Two lightweight check-in endpoints, /verify-human/{channel} and /u/e, gate the later stages – the former appearing to function as a server-side bail-out check, and the latter as a telemetry beacon fired immediately before the stealer packages and ships collected data.

Information Stealing Capabilities

Once fully unpacked, the Python payload – OmniStealer – proved to be a broad-spectrum credential and financial-data stealer.

Credential and session data

• Browser saved passwords, login details, and cookies
• Password-manager vault credentials
• Git and GitHub credentials
• Windows credentials, both local and domain

Financial and payment data

• Credit card and banking information
• Cryptocurrency wallet data via browser extensions

System and OS-level data

• Keychains
• Installed browsers, browser settings, and browser extensions
• Local users, groups, and policies

The breadth of collection – spanning banking data, domain credentials, and developer tooling credentials in the same run – points to an operator interested in more than a single monetization path and instead built to support both direct cryptocurrency theft and follow-on access to compromised development environments and organizational systems.

A test execution in a controlled environment confirmed the stealer’s packaging and exfiltration behavior end-to-end: it collects target files, compresses them with LZMA, and uploads the resulting archive over HTTP, with Telegram available as a secondary exfiltration path.

Command and Control / Exfiltration

OmniStealer shipped stolen data to a dedicated C2 server over HTTP, and separately supported exfiltration via a Telegram bot – a common technique for stealers looking to blend a secondary channel into ordinary, hard-to-block application traffic. In this case the Telegram channel proved useful defensively as well as offensively: gaining interaction with the bot allowed us to probe its behavior directly, and in the process the operator’s server was inadvertently knocked offline.

The C2 server itself briefly went down separately during the investigation, appearing to be routine maintenance on the operator’s end rather than a response to our activity, and came back within hours.

The Ethereum address associated with the campaign exhibited a distinct “heartbeat” pattern – small, near-zero-value transactions sent at a regular roughly-3h20m interval to a second address. Initially it was best explained as a liveness check the operator uses to confirm their infrastructure or wallet pipeline is reachable, rather than as active theft in itself; actual proceeds would be expected to move through separate, less conspicuous transactions. In reality, Lazarus had actually moved to using Etherium chains as a way to encode and retrieve their C2s when the hard-coded IPs had failed. When scanning the controller address, we were able to idenitfy an excess of 400 transactions containing seven unique IP addresses – most of which were dead, and could conclude the encoding pattern as follows:

• Interpret the first eight bytes of an Ethereum address as:
• • tx.to bytes 0-3 -> primary IPv4
• • tx.to bytes 4-7 -> secondary IPv4

Attribution

Attribution work centered on the operator’s own OPSEC failures rather than any single conclusive artifact. The GitLab commit identity PolinRider matches an alias independently catalogued in an open-source threat-actor dossier as belonging to a DPRK-affiliated actor – the strongest single data point tying this campaign to DPRK. That’s reinforced by:

• Reuse of a compromised, previously trusted developer account to lend legitimacy to malicious code
• A stager showing design lineage consistent with BeaverTail, a JavaScript loader associated with DPRK campaigns
• A social-engineering approach – fake or hijacked repositories targeting web3 developers – consistent with previously documented DPRK tradecraft
• A consistent C2 Framework, that follows the exact behaviour, setup, and pathing as prior Lazarus stealer C2s

None of these are individually conclusive, and the possibility of financially motivated actors deliberately mimicking DPRK tradecraft was raised and not fully ruled out during analysis. We’re presenting this as a high-confidence assessment rather than a settled conclusion.

Detection Opportunities

Network

• Connections to the identified C2 IP and its associated URI paths
• Outbound Telegram Bot API traffic from unexpected or non-automation processes
• Unusual periodic, low-value cryptocurrency transfers between a fixed wallet pair (potential C2 liveness beaconing)

Endpoint

• eval()-based obfuscated code blocks in third-party npm dependencies, especially in packages with no functional need for network or credential-store access
• Access to browser credential stores, password managers, or cryptocurrency wallet extension data by unrelated build/animation-style packages
• Access to Windows credential stores (local or domain) by Node.js/npm-spawned processes

Supply chain

• Recurrence of the same obfuscated stager pattern in other npm packages or public repositories
• New packages published by, or repositories linked to, the accounts and aliases identified in this campaign
• Git commit authorship anomalies inconsistent with an account’s established history – a strong signal of account compromise, as seen here

Indicators of Compromise (IOCs)

Given the volume of indicators, the full IOC list and YARA detection rules for this campaign have been published separately to AlienVault OTX: otx.alienvault.com/pulse/6a897a2fc8718f44080429e2

Defensive Recommendations

For developers

• Audit new or low-adoption npm dependencies before installing, particularly for packages with no clear reason to reach the network or touch the filesystem outside their stated purpose.
• Treat unsolicited or too-convenient “helpful” repositories and pull requests from unfamiliar or newly active contributors with suspicion, even when they appear to come from a known account.
• Verify unexpected code contributions or dependency changes through a communication channel separate from the one the request arrived on.

For incident responders

Where OmniStealer or similar activity is suspected:

1. Isolate the affected endpoint.
2. Rotate all browser-stored, password-manager, Git/GitHub, and Windows domain credentials from a known-clean device.
3. Invalidate active sessions and cookies.
4. Review cryptocurrency wallet exposure and transaction history for unauthorized activity.
5. Preserve the malicious package, stager files, and network telemetry for further analysis.
6. Report the malicious package to the relevant package registry.

Conclusion

OmniStealer is a capable, actively maintained credential and cryptocurrency stealer distributed through a deliberately unglamorous vector – a routine-looking npm dependency – rather than an obvious phishing lure. The malicious package has been removed following takedown reporting, and the operator’s infrastructure appears to have gone dark in the aftermath. Given the suspected DPRK nexus and the campaign’s specific targeting of web3 developers, teams in that space should treat unfamiliar or newly published dependencies with real scrutiny, and should use the published IOCs and YARA rules to check for prior exposure.