What does the @lazyutil/dater malware do?

@lazyutil/dater (malicious versions 0.8.1, 0.9.2, 0.9.3, and 0.9.4, published by lazyutil-78muyg@wshu.net) is a trojanized npm package belonging to the wshu.net credential-stealer campaign. The campaign published trojanized look-alike utility packages across 12+ scopes whose publisher accounts all follow the pattern - @wshu.net, with every scope created on June 4, 2026 in a ~40-minute burst. This package masquerades as a date library and ships real, working utility code so it passes a glance, while bundling a much larger malicious payload (lib/tzinit.js in the earliest variant, dist/lib/tzinit.cjs thereafter). package.json declares a postinstall hook (e.g. "node ./dist/

Which versions of @lazyutil/dater are malicious?

The following npm versions of @lazyutil/dater are flagged malicious: 0.8.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5. Treat any of these as compromised.

How do I remediate @lazyutil/dater if I installed it?

@lazyutil/dater is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.

I already installed @lazyutil/dater — how do I know if it already compromised me?

If @lazyutil/dater was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.

Is @lazyutil/dater part of a known attack campaign?

Yes — @lazyutil/dater is associated with the IN-MAL-2026-007295, IN-MAL-2026-007298, IN-MAL-2026-007293, IN-MAL-2026-007294, IN-MAL-2026-007297 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find @lazyutil/dater across my projects, lockfiles, and CI pipelines?

Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @lazyutil/dater (5 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @lazyutil/dater across your stack and pipelines.

Malicious package

@lazyutil/daternpm

Malicious code in @lazyutil/dater (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-6308

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

npm uninstall @lazyutil/dater

What this malware does

@lazyutil/dater (malicious versions 0.8.1, 0.9.2, 0.9.3, and 0.9.4, published by [email protected]) is a trojanized npm package belonging to the wshu.net credential-stealer campaign. The campaign published trojanized look-alike utility packages across 12+ scopes whose publisher accounts all follow the pattern <scope>-<6 random chars>@wshu.net, with every scope created on June 4, 2026 in a ~40-minute burst. This package masquerades as a date library and ships real, working utility code so it passes a glance, while bundling a much larger malicious payload (lib/tzinit.js in the earliest variant, dist/lib/tzinit.cjs thereafter). package.json declares a postinstall hook (e.g. "node ./dist/lib/tzinit.cjs") that runs the payload automatically on npm install. The payload is heavily obfuscated with javascript-obfuscator (hex-named identifiers, a while (!![]) array-rotation IIFE, base64+RC4 string decoding, control-flow flattening, and runtime-decrypted module resolution to stay out of the static module graph). At runtime it is a Chromium browser credential stealer: it reads Chromium Cookies and Login Data and decrypts saved passwords protected by AES-256-GCM (the v10/v11 app-bound key schemes), then exfiltrates them over HTTPS using a spoofed Mozilla/5.0 user agent. Consistent with the campaign, the dangerous versions sit in mid-ranges while the latest tag (0.9.5) points to a scrubbed release with an empty scripts block. The 0.9.4 payload blob is byte-identical to @glitchpad/[email protected] from the same campaign. Malicious payload dist/lib/tzinit.cjs (0.9.4) SHA-256: 68b4fe54a4c05cd0115535ebd4aa8d3cccb03ea5a685f440314814ba1b89e875.

@lazyutil/dater is a trojanized repackage of the legitimate timezonecomplete library. Its package.json declares postinstall: node./dist/lib/tzinit.cjs, which runs automatically on npm install. tzinit.cjs is a 263 KB obfuscator.io-protected file (string-array RC4/XOR + control-flow flattening) that uses AES-256-GCM with a hardcoded key/IV/AAD to decrypt an embedded URL and host, then performs an HTTP GET to fetch a binary, writes it to disk, chmods it executable, and spawns it via process.execPath or sh -c. The dropper is platform-gated for win32/darwin/linux, retries with backoff, and re-execs the package's process. None of this is required for a date/timezone library and the legitimate upstream has neither a postinstall nor a tzinit.cjs. Trojanization signals: package description is copied verbatim from timezonecomplete, the repository field still points at the upstream author's git URL (github.com/rogierschouten/timezonecomplete), homepage points at a placeholder github.com/lazyutil, and author is a fresh ProtonMail identity unrelated to the original maintainer. Installing this package gives an attacker arbitrary code execution on the installer's machine.

Malicious versions

5 flagged

0.8.10.9.20.9.30.9.40.9.5

Indicators of compromise (SHA-256)

1e60ea16a2304b00c24feeb56b14387e7b137e4e832eebeef61536bbdc30ee64

3085d5883cb7184bb57024ffe4bb1c5760ea3b120ce4b4dee03c874b3cbc62d4

362ed214c96b3a091355472cb7d03ca7dcb1c3b1c36daede92d4e7a04027cb8a

af4babebb1ad40ecc1260f2036da3052003e645d7edfdcc5d03bd6105748659d

c55953491fa63e65d06f8db1855ea4ae815244b2c0b7590f609ca0b460928181

Detection & response playbook

Credential / info stealer

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @lazyutil/dater (5 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @lazyutil/dater across your stack and pipelines.
If you installed it — respond
@lazyutil/dater is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.
Did it already run?
If @lazyutil/dater was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks @lazyutil/dater before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.

Frequently asked questions

No. @lazyutil/dater on npm has been identified as a malicious package (versions 0.8.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-007295IN-MAL-2026-007298IN-MAL-2026-007293IN-MAL-2026-007294IN-MAL-2026-007297

References

Credits

Amazon Inspector · finder
SafeDep · finder

Detect & block this

O3 blocks @lazyutil/dater-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.

Malware detection Runtime egress monitoring