Supply chain · npm · High

Malicious npm package @dransay/logger performs reconnaissance via dependency confusion

Threat Engine Auto-Feed · data current as of 2026-10-08

The npm package `@dransay/logger` version `99.0.0` contains malicious code that executes a preinstall hook. This hook performs a DNS lookup and HTTPS GET to an external host, disclosing installer information. This activity is consistent with the reconnaissance phase of a dependency confusion attack.

  • Package: npm / @dransay/logger
  • Affected versions: = 99.0.0
  • Severity: critical
  • Reach: unknown
  • Exposure: 65/100 (High)

What happened — Malicious package

The npm package `@dransay/logger` version `99.0.0` includes a preinstall hook that executes `node beacon.js` upon installation. This script initiates a DNS lookup and an HTTPS GET request to a third-party collaborator host, `db3klhbi6i9hark1kegg174t38h33b6wt.oast.site`. The package name is encoded within the subdomain/path of this request.

How the attack works

This is a dependency confusion attack, where a public package with an unusually high version number (99.0.0) is published to win semver resolution against a potentially private internal package with a similar name. The preinstall hook acts as a reconnaissance stage, confirming successful installation of the public malicious package by transmitting the installer's source IP, DNS resolver, and timestamp to an attacker-controlled endpoint. While no further payload is executed in this specific version, this initial callback confirms the viability of the dependency confusion tactic.

Who's exposed

Profiles most at risk

  • Development teams using npm
  • Organizations with private npm registries or scoped packages that might conflict with public names
  • CI/CD pipelines that resolve npm dependencies

Conditions that increase exposure

  • Unpinned dependencies that allow resolution to the latest version
  • Lack of package lockfiles (e.g., `package-lock.json`)
  • Internal package mirrors that do not strictly enforce private package resolution over public registries
  • Environments configured to resolve public npm packages before private ones for scoped names (e.g., `@dransay/*`)

Blast-radius scenarios

  • If installed, the package discloses the installer's source IP, DNS resolver, and timestamp to an attacker-controlled host, confirming the environment's susceptibility to dependency confusion. This reconnaissance could precede further, more impactful attacks.

What to do (defensive)

Detect

  • Monitor network traffic for outbound connections to `db3klhbi6i9hark1kegg174t38h33b6wt.oast.site` or other suspicious domains from build environments.
  • Review `npm install` logs for execution of preinstall hooks in unexpected packages.
  • Scan `package.json` and `package-lock.json` files for the presence of `@dransay/logger@99.0.0`.

Contain

  • Block network access to `db3klhbi6i9hark1kegg174t38h33b6wt.oast.site` from all build and development environments.
  • Remove `@dransay/logger@99.0.0` from any `package.json` or `package-lock.json` files.
  • Quarantine any systems where this package was installed and investigate for further compromise, despite no additional payload being noted for this version.

Remediate

  • Ensure all npm dependencies are pinned to specific, trusted versions using `package-lock.json` or `yarn.lock`.
  • Implement strict controls for private package resolution, prioritizing internal registries over public ones for scoped packages.
  • Regularly audit dependencies for suspicious package names, high version numbers without release history, or unexpected preinstall/postinstall scripts.
  • Educate development teams on dependency confusion risks and secure package management practices.

Frontier verdict — High

Prioritize investigation and remediation for `@dransay/logger@99.0.0` due to its critical severity and role in dependency confusion reconnaissance.

Sources

For detection-engineering and awareness only · point-in-time · not security advice · sourced from the GitHub Advisory Database.